OvmfPkg/VirtioGpuDxe: introduce with Component Name 2 and Driver Binding
This patch adds the skeleton of the driver: it implements the Component
Name 2 Protocol and the Driver Binding Protocol, in accordance with the
generic and GOP-specific requirements set forth in the UEFI spec and the
Driver Writers' Guide.
The basic idea is that VGPU_DEV abstracts the virtio GPU device, while the
single VGPU_GOP that we intend to support at this point stands for "head"
(aka "scanout") #0.
For now, the Virtio Device Protocol is only used for driver binding; no
actual virtio operations are done yet. Similarly, we use a "dummy" GOP
GUID and protocol structure (a plain UINT8 object) for now, so that
GOP-consuming drivers don't look at what we produce just yet.
The driver is a bit different from the other virtio device drivers written
thus far:
- It implements the GetControllerName() member of the Component Name 2
Protocol. (Formatting helpful names is recommended by UEFI.) As a "best
effort", we format the PCI BDF into the name (a PCI backend is not
guaranteed by VIRTIO_DEVICE_PROTOCOL). It should provide a more friendly
experience in the shell and elsewhere.
- This driver seeks to support all RemainingDevicePath cases:
- NULL: produce all (= one) child handles (= VGPU_GOP heads) at once,
- End of Device Path Node: produce no child handles,
- specific ACPI ADR Node: check if it's supportable, and produce it
(only one specific child controller is supported).
This is one of the reasons for separating VGPU_GOP from VGPU_DEV.
The driver is a hybrid driver: it produces both child handles (one, to be
exact), but also installs a structure (VGPU_DEV) directly on the VirtIo
controller handle, using gEfiCallerIdGuid as protocol GUID. This is a
trick I've seen elsewhere in edk2 (for example, TerminalDxe), and it is
necessary for the following reason:
In EFI_COMPONENT_NAME2_PROTOCOL.GetControllerName(), we must be able to
"cast down" a VirtIo ControllerHandle to our own private data structure
(VGPU_DEV). That's only possible if we install the structure directly on
the VirtIo ControllerHandle (thereby rendering the driver a hybrid
driver), because a child controller with our GOP implementation on it may
not exist / be passed in there.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=66
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-08-15 15:34:32 +02:00
|
|
|
/** @file
|
|
|
|
|
|
|
|
Internal type and macro definitions for the Virtio GPU hybrid driver.
|
|
|
|
|
|
|
|
Copyright (C) 2016, Red Hat, Inc.
|
|
|
|
|
|
|
|
This program and the accompanying materials are licensed and made available
|
|
|
|
under the terms and conditions of the BSD License which accompanies this
|
|
|
|
distribution. The full text of the license may be found at
|
|
|
|
http://opensource.org/licenses/bsd-license.php
|
|
|
|
|
|
|
|
THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, WITHOUT
|
|
|
|
WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
|
|
|
|
|
|
|
|
**/
|
|
|
|
|
|
|
|
#ifndef _VIRTIO_GPU_DXE_H_
|
|
|
|
#define _VIRTIO_GPU_DXE_H_
|
|
|
|
|
|
|
|
#include <Library/DebugLib.h>
|
|
|
|
#include <Library/UefiLib.h>
|
|
|
|
#include <Protocol/VirtioDevice.h>
|
|
|
|
|
|
|
|
//
|
|
|
|
// Forward declaration of VGPU_GOP.
|
|
|
|
//
|
|
|
|
typedef struct VGPU_GOP_STRUCT VGPU_GOP;
|
|
|
|
|
|
|
|
//
|
|
|
|
// The abstraction that directly corresponds to a Virtio GPU device.
|
|
|
|
//
|
|
|
|
// This structure will be installed on the handle that has the VirtIo Device
|
|
|
|
// Protocol interface, with GUID gEfiCallerIdGuid. A similar trick is employed
|
|
|
|
// in TerminalDxe, and it is necessary so that we can look up VGPU_DEV just
|
|
|
|
// from the VirtIo Device Protocol handle in the Component Name 2 Protocol
|
|
|
|
// implementation.
|
|
|
|
//
|
|
|
|
typedef struct {
|
|
|
|
//
|
|
|
|
// VirtIo represents access to the Virtio GPU device. Never NULL.
|
|
|
|
//
|
|
|
|
VIRTIO_DEVICE_PROTOCOL *VirtIo;
|
|
|
|
|
|
|
|
//
|
|
|
|
// BusName carries a customized name for
|
|
|
|
// EFI_COMPONENT_NAME2_PROTOCOL.GetControllerName(). It is expressed in table
|
|
|
|
// form because it can theoretically support several languages. Never NULL.
|
|
|
|
//
|
|
|
|
EFI_UNICODE_STRING_TABLE *BusName;
|
|
|
|
|
2016-08-18 01:31:27 +02:00
|
|
|
//
|
|
|
|
// VirtIo ring used for VirtIo communication.
|
|
|
|
//
|
|
|
|
VRING Ring;
|
|
|
|
|
|
|
|
//
|
|
|
|
// Event to be signaled at ExitBootServices().
|
|
|
|
//
|
|
|
|
EFI_EVENT ExitBoot;
|
|
|
|
|
OvmfPkg/VirtioGpuDxe: introduce with Component Name 2 and Driver Binding
This patch adds the skeleton of the driver: it implements the Component
Name 2 Protocol and the Driver Binding Protocol, in accordance with the
generic and GOP-specific requirements set forth in the UEFI spec and the
Driver Writers' Guide.
The basic idea is that VGPU_DEV abstracts the virtio GPU device, while the
single VGPU_GOP that we intend to support at this point stands for "head"
(aka "scanout") #0.
For now, the Virtio Device Protocol is only used for driver binding; no
actual virtio operations are done yet. Similarly, we use a "dummy" GOP
GUID and protocol structure (a plain UINT8 object) for now, so that
GOP-consuming drivers don't look at what we produce just yet.
The driver is a bit different from the other virtio device drivers written
thus far:
- It implements the GetControllerName() member of the Component Name 2
Protocol. (Formatting helpful names is recommended by UEFI.) As a "best
effort", we format the PCI BDF into the name (a PCI backend is not
guaranteed by VIRTIO_DEVICE_PROTOCOL). It should provide a more friendly
experience in the shell and elsewhere.
- This driver seeks to support all RemainingDevicePath cases:
- NULL: produce all (= one) child handles (= VGPU_GOP heads) at once,
- End of Device Path Node: produce no child handles,
- specific ACPI ADR Node: check if it's supportable, and produce it
(only one specific child controller is supported).
This is one of the reasons for separating VGPU_GOP from VGPU_DEV.
The driver is a hybrid driver: it produces both child handles (one, to be
exact), but also installs a structure (VGPU_DEV) directly on the VirtIo
controller handle, using gEfiCallerIdGuid as protocol GUID. This is a
trick I've seen elsewhere in edk2 (for example, TerminalDxe), and it is
necessary for the following reason:
In EFI_COMPONENT_NAME2_PROTOCOL.GetControllerName(), we must be able to
"cast down" a VirtIo ControllerHandle to our own private data structure
(VGPU_DEV). That's only possible if we install the structure directly on
the VirtIo ControllerHandle (thereby rendering the driver a hybrid
driver), because a child controller with our GOP implementation on it may
not exist / be passed in there.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=66
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-08-15 15:34:32 +02:00
|
|
|
//
|
|
|
|
// The Child field references the GOP wrapper structure. If this pointer is
|
|
|
|
// NULL, then the hybrid driver has bound (i.e., started) the
|
|
|
|
// VIRTIO_DEVICE_PROTOCOL controller without producing the child GOP
|
|
|
|
// controller (that is, after Start() was called with RemainingDevicePath
|
|
|
|
// pointing to and End of Device Path node). Child can be created and
|
|
|
|
// destroyed, even repeatedly, independently of VGPU_DEV.
|
|
|
|
//
|
|
|
|
// In practice, this field represents the single head (scanout) that we
|
|
|
|
// support.
|
|
|
|
//
|
|
|
|
VGPU_GOP *Child;
|
|
|
|
} VGPU_DEV;
|
|
|
|
|
|
|
|
//
|
|
|
|
// The Graphics Output Protocol wrapper structure.
|
|
|
|
//
|
|
|
|
#define VGPU_GOP_SIG SIGNATURE_64 ('V', 'G', 'P', 'U', '_', 'G', 'O', 'P')
|
|
|
|
|
|
|
|
struct VGPU_GOP_STRUCT {
|
|
|
|
UINT64 Signature;
|
|
|
|
|
|
|
|
//
|
|
|
|
// ParentBus points to the parent VGPU_DEV object. Never NULL.
|
|
|
|
//
|
|
|
|
VGPU_DEV *ParentBus;
|
|
|
|
|
|
|
|
//
|
|
|
|
// GopName carries a customized name for
|
|
|
|
// EFI_COMPONENT_NAME2_PROTOCOL.GetControllerName(). It is expressed in table
|
|
|
|
// form because it can theoretically support several languages. Never NULL.
|
|
|
|
//
|
|
|
|
EFI_UNICODE_STRING_TABLE *GopName;
|
|
|
|
|
|
|
|
//
|
|
|
|
// GopHandle is the UEFI child handle that carries the device path ending
|
|
|
|
// with the ACPI ADR node, and the Graphics Output Protocol. Never NULL.
|
|
|
|
//
|
|
|
|
EFI_HANDLE GopHandle;
|
|
|
|
|
|
|
|
//
|
|
|
|
// The GopDevicePath field is the device path installed on GopHandle,
|
|
|
|
// ending with an ACPI ADR node. Never NULL.
|
|
|
|
//
|
|
|
|
EFI_DEVICE_PATH_PROTOCOL *GopDevicePath;
|
|
|
|
|
|
|
|
//
|
|
|
|
// The Gop field is installed on the child handle as Graphics Output Protocol
|
|
|
|
// interface.
|
|
|
|
//
|
|
|
|
// For now it is just a placeholder.
|
|
|
|
//
|
|
|
|
UINT8 Gop;
|
|
|
|
};
|
|
|
|
|
2016-08-18 01:31:27 +02:00
|
|
|
//
|
|
|
|
// VirtIo GPU initialization, and commands (primitives) for the GPU device.
|
|
|
|
//
|
|
|
|
/**
|
|
|
|
Configure the VirtIo GPU device that underlies VgpuDev.
|
|
|
|
|
|
|
|
@param[in,out] VgpuDev The VGPU_DEV object to set up VirtIo messaging for.
|
|
|
|
On input, the caller is responsible for having
|
|
|
|
initialized VgpuDev->VirtIo. On output, VgpuDev->Ring
|
|
|
|
has been initialized, and synchronous VirtIo GPU
|
|
|
|
commands (primitives) can be submitted to the device.
|
|
|
|
|
|
|
|
@retval EFI_SUCCESS VirtIo GPU configuration successful.
|
|
|
|
|
|
|
|
@retval EFI_UNSUPPORTED The host-side configuration of the VirtIo GPU is not
|
|
|
|
supported by this driver.
|
|
|
|
|
|
|
|
@retval Error codes from underlying functions.
|
|
|
|
**/
|
|
|
|
EFI_STATUS
|
|
|
|
VirtioGpuInit (
|
|
|
|
IN OUT VGPU_DEV *VgpuDev
|
|
|
|
);
|
|
|
|
|
|
|
|
/**
|
|
|
|
De-configure the VirtIo GPU device that underlies VgpuDev.
|
|
|
|
|
|
|
|
@param[in,out] VgpuDev The VGPU_DEV object to tear down VirtIo messaging
|
|
|
|
for. On input, the caller is responsible for having
|
|
|
|
called VirtioGpuInit(). On output, VgpuDev->Ring has
|
|
|
|
been uninitialized; VirtIo GPU commands (primitives)
|
|
|
|
can no longer be submitted to the device.
|
|
|
|
**/
|
|
|
|
VOID
|
|
|
|
VirtioGpuUninit (
|
|
|
|
IN OUT VGPU_DEV *VgpuDev
|
|
|
|
);
|
|
|
|
|
|
|
|
/**
|
|
|
|
EFI_EVENT_NOTIFY function for the VGPU_DEV.ExitBoot event. It resets the
|
|
|
|
VirtIo device, causing it to release its resources and to forget its
|
|
|
|
configuration.
|
|
|
|
|
|
|
|
This function may only be called (that is, VGPU_DEV.ExitBoot may only be
|
|
|
|
signaled) after VirtioGpuInit() returns and before VirtioGpuUninit() is
|
|
|
|
called.
|
|
|
|
|
|
|
|
@param[in] Event Event whose notification function is being invoked.
|
|
|
|
|
|
|
|
@param[in] Context Pointer to the associated VGPU_DEV object.
|
|
|
|
**/
|
|
|
|
VOID
|
|
|
|
EFIAPI
|
|
|
|
VirtioGpuExitBoot (
|
|
|
|
IN EFI_EVENT Event,
|
|
|
|
IN VOID *Context
|
|
|
|
);
|
|
|
|
|
OvmfPkg/VirtioGpuDxe: introduce with Component Name 2 and Driver Binding
This patch adds the skeleton of the driver: it implements the Component
Name 2 Protocol and the Driver Binding Protocol, in accordance with the
generic and GOP-specific requirements set forth in the UEFI spec and the
Driver Writers' Guide.
The basic idea is that VGPU_DEV abstracts the virtio GPU device, while the
single VGPU_GOP that we intend to support at this point stands for "head"
(aka "scanout") #0.
For now, the Virtio Device Protocol is only used for driver binding; no
actual virtio operations are done yet. Similarly, we use a "dummy" GOP
GUID and protocol structure (a plain UINT8 object) for now, so that
GOP-consuming drivers don't look at what we produce just yet.
The driver is a bit different from the other virtio device drivers written
thus far:
- It implements the GetControllerName() member of the Component Name 2
Protocol. (Formatting helpful names is recommended by UEFI.) As a "best
effort", we format the PCI BDF into the name (a PCI backend is not
guaranteed by VIRTIO_DEVICE_PROTOCOL). It should provide a more friendly
experience in the shell and elsewhere.
- This driver seeks to support all RemainingDevicePath cases:
- NULL: produce all (= one) child handles (= VGPU_GOP heads) at once,
- End of Device Path Node: produce no child handles,
- specific ACPI ADR Node: check if it's supportable, and produce it
(only one specific child controller is supported).
This is one of the reasons for separating VGPU_GOP from VGPU_DEV.
The driver is a hybrid driver: it produces both child handles (one, to be
exact), but also installs a structure (VGPU_DEV) directly on the VirtIo
controller handle, using gEfiCallerIdGuid as protocol GUID. This is a
trick I've seen elsewhere in edk2 (for example, TerminalDxe), and it is
necessary for the following reason:
In EFI_COMPONENT_NAME2_PROTOCOL.GetControllerName(), we must be able to
"cast down" a VirtIo ControllerHandle to our own private data structure
(VGPU_DEV). That's only possible if we install the structure directly on
the VirtIo ControllerHandle (thereby rendering the driver a hybrid
driver), because a child controller with our GOP implementation on it may
not exist / be passed in there.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=66
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-08-15 15:34:32 +02:00
|
|
|
#endif // _VIRTIO_GPU_DXE_H_
|