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_
|
|
|
|
|
2016-08-18 17:00:03 +02:00
|
|
|
#include <IndustryStandard/VirtioGpu.h>
|
2017-08-26 22:15:46 +02:00
|
|
|
#include <Library/BaseMemoryLib.h>
|
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
|
|
|
#include <Library/DebugLib.h>
|
|
|
|
#include <Library/UefiLib.h>
|
2016-08-17 22:45:02 +02:00
|
|
|
#include <Protocol/GraphicsOutput.h>
|
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
|
|
|
#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;
|
|
|
|
|
OvmfPkg/VirtioGpuDxe: map VRING for bus master common buffer operation
VirtioGpuDxe uses one virtio ring, for VIRTIO_GPU_CONTROL_QUEUE.
Map it for bus master common buffer operation with VirtioRingMap(), so
that it can be accessed equally by both guest and hypervisor even if an
IOMMU is used. (VirtioRingInit() already allocates the ring suitably for
this, see commit b0338c53297c, "OvmfPkg/VirtioLib: alloc VRING buffer with
AllocateSharedPages()", 2017-08-23).
Pass the resultant translation offset ("RingBaseShift"), from system
memory address to bus master device address, to VIRTIO_SET_QUEUE_ADDRESS.
Unmap the ring in all contexts where the ring becomes unused (these
contexts are mutually exclusive):
- in VirtioGpuInit(): the ring has been mapped, but we cannot complete the
virtio initialization for another reason,
- in VirtioGpuUninit(): the virtio initialization has succeeded, but
VirtioGpuDriverBindingStart() fails for another reason, or
VirtioGpuDriverBindingStop() unbinds the device after use,
- in VirtioGpuExitBoot(): ExitBootServices() is called after
VirtioGpuDriverBindingStart() has successfully bound the device.
(Unmapping the ring does not change the UEFI memory map.)
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
2017-08-26 16:00:30 +02:00
|
|
|
//
|
|
|
|
// Token associated with Ring's mapping for bus master common buffer
|
|
|
|
// operation, from VirtioRingMap().
|
|
|
|
//
|
|
|
|
VOID *RingMap;
|
|
|
|
|
2016-08-18 01:31:27 +02:00
|
|
|
//
|
|
|
|
// Event to be signaled at ExitBootServices().
|
|
|
|
//
|
|
|
|
EFI_EVENT ExitBoot;
|
|
|
|
|
2016-08-18 17:00:03 +02:00
|
|
|
//
|
|
|
|
// Common running counter for all VirtIo GPU requests that ask for fencing.
|
|
|
|
//
|
|
|
|
UINT64 FenceId;
|
|
|
|
|
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.
|
|
|
|
//
|
2016-08-17 22:45:02 +02:00
|
|
|
EFI_GRAPHICS_OUTPUT_PROTOCOL Gop;
|
|
|
|
|
|
|
|
//
|
|
|
|
// Referenced by Gop.Mode, GopMode provides a summary about the supported
|
|
|
|
// graphics modes, and the current mode.
|
|
|
|
//
|
|
|
|
EFI_GRAPHICS_OUTPUT_PROTOCOL_MODE GopMode;
|
|
|
|
|
|
|
|
//
|
|
|
|
// Referenced by GopMode.Info, GopModeInfo provides detailed information
|
|
|
|
// about the current mode.
|
|
|
|
//
|
|
|
|
EFI_GRAPHICS_OUTPUT_MODE_INFORMATION GopModeInfo;
|
|
|
|
|
|
|
|
//
|
|
|
|
// Identifier of the 2D host resource that is in use by this head (scanout)
|
|
|
|
// of the VirtIo GPU device. Zero until the first successful -- internal --
|
|
|
|
// Gop.SetMode() call, never zero afterwards.
|
|
|
|
//
|
|
|
|
UINT32 ResourceId;
|
|
|
|
|
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
|
|
|
//
|
2016-08-17 22:45:02 +02:00
|
|
|
// A number of whole pages providing the backing store for the 2D host
|
|
|
|
// resource identified by ResourceId above. NULL until the first successful
|
|
|
|
// -- internal -- Gop.SetMode() call, never NULL afterwards.
|
|
|
|
//
|
|
|
|
UINT32 *BackingStore;
|
|
|
|
UINTN NumberOfPages;
|
OvmfPkg/VirtioGpuDxe: map backing store to bus master device address
VirtioGpuDxe is a UEFI Bus driver (not a Device driver). This is because a
UEFI graphics driver is expected to produce its GraphicsOutput protocol
instance(s) on new child handle(s) of the video controller handle, one
child handle (plus GOP) per video output (or, one child handle plus GOP
per combination of multiple video outputs).
In VirtioGpuDxe, we support a single VirtIo GPU head (scanout), namely
head#0. This means that, with regard to a specific VirtIo GPU device, the
driver may be in one of three states, at any time:
[1] VirtioGpuDxe has not bound the device at all,
[2] VirtioGpuDxe has bound the device, but not produced the sole child
handle for head#0,
[3] VirtioGpuDxe has bound the device, and produced the sole child handle
for head#0, with a GOP instance on the child handle.
(Which state the driver is in wrt. a given VirtIo GPU device depends on
the VirtioGpuDriverBindingStart() / VirtioGpuDriverBindingStop()
invocations issued by the ConnectController() / DisconnectController()
boot services. In turn those come from BDS or e.g. the UEFI shell.)
The concept of "current video mode" is technically tied to the GOP (i.e.,
the child handle, state [3] only), not the VirtIo GPU controller handle.
This is why we manage the storage that backs the current video mode in our
EFI_GRAPHICS_OUTPUT_PROTOCOL.SetMode() member implementation.
GopSetMode() is first called *internally*, when we enter state [3] (that
is, when we produce the child handle + GOP on it):
VirtioGpuDriverBindingStart() [DriverBinding.c]
InitVgpuGop() [DriverBinding.c]
VgpuGop->Gop.SetMode() [Gop.c]
When this happens, we allocate the backing store *without* having a
preexistent backing store (due to no preexistent video mode and GOP).
Skipping VirtIo GPU details not relevant for this patch, we just note that
the backing store is exposed *permanently* to the VirtIo GPU device, with
the RESOURCE_ATTACH_BACKING command.
When external clients call the EFI_GRAPHICS_OUTPUT_PROTOCOL.Blt() member
function -- called GopBlt() in this driver --, in state [3], the function
operates on the backing store, and sends only small messages to the VirtIo
GPU device.
When external clients call GopSetMode() for switching between video modes
-- in state [3] --, then
- a new backing store is allocated and exposed to the device (attached to
a new host-side VirtIo GPU resource),
- head#0 is flipped to the new backing store,
- on success, the ReleaseGopResources() function both detaches the
previous backing store from the VirtIo GPU device, an releases it. The
new backing store address and size are saved in our GOP object. (In
other words, we "commit" to the new video mode.)
When the DisconnectController() boot service asks us to leave state [3] --
we can leave it directly only for state [2] --, then the
ReleaseGopResources() function is called on a different path:
VirtioGpuDriverBindingStop() [DriverBinding.c]
UninitVgpuGop() [DriverBinding.c]
ReleaseGopResources() [Gop.c]
In this case, the backing store being released is still in use (we're not
leaving it for a new mode -- head#0 has not been flipped "away" from it),
so in ReleaseGopResources() we disable head#0 first.
(The ReleaseGopResources() function is called the same way on the error
path in InitVgpuGop(), if the first -- internal -- VgpuGop->Gop.SetMode()
call succeeds, but the rest of InitVgpuGop() fails.)
Based on the above, for IOMMU-compatibility,
- in GopSetMode(), don't just allocate, but also map the backing store of
the nascent video mode to a device address, for bus master common buffer
operation,
- (the VirtioGpuAllocateZeroAndMapBackingStore() helper function
introduced in the last patch takes care of zeroing internally,)
- pass the device address to the VirtIo GPU device in the
RESOURCE_ATTACH_BACKING command,
- if GopSetMode() succeeds, save the mapping token,
- if GopSetMode() fails, don't just free but also unmap the still-born
backing store,
- in ReleaseGopResources(), don't just free but also unmap the backing
store -- which is the previous backing store if we're mode-switching,
and the current backing store if we're leaving state [3].
Finally, ExitBootServices() may be called when the driver is in either
state [1], [2] or [3], wrt. a given VirtIo GPU device. (Of course we are
only notified in states [2] and [3].) If we get the notification in state
[3], then the current video mode's backing store has to be unmapped, but
not released. (We must not change the UEFI memory map.)
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
2017-08-26 18:12:15 +02:00
|
|
|
|
|
|
|
//
|
|
|
|
// Token associated with BackingStore's mapping for bus master common
|
|
|
|
// buffer operation. BackingStoreMap is valid if, and only if,
|
|
|
|
// BackingStore is non-NULL.
|
|
|
|
//
|
|
|
|
VOID *BackingStoreMap;
|
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
|
|
|
};
|
|
|
|
|
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
|
|
|
|
);
|
|
|
|
|
2017-08-26 22:15:46 +02:00
|
|
|
/**
|
|
|
|
Allocate, zero and map memory, for bus master common buffer operation, to be
|
|
|
|
attached as backing store to a host-side VirtIo GPU resource.
|
|
|
|
|
|
|
|
@param[in] VgpuDev The VGPU_DEV object that represents the VirtIo GPU
|
|
|
|
device.
|
|
|
|
|
|
|
|
@param[in] NumberOfPages The number of whole pages to allocate and map.
|
|
|
|
|
|
|
|
@param[out] HostAddress The system memory address of the allocated area.
|
|
|
|
|
|
|
|
@param[out] DeviceAddress The bus master device address of the allocated
|
|
|
|
area. The VirtIo GPU device may be programmed to
|
|
|
|
access the allocated area through DeviceAddress;
|
|
|
|
DeviceAddress is to be passed to the
|
|
|
|
VirtioGpuResourceAttachBacking() function, as the
|
|
|
|
BackingStoreDeviceAddress parameter.
|
|
|
|
|
|
|
|
@param[out] Mapping A resulting token to pass to
|
|
|
|
VirtioGpuUnmapAndFreeBackingStore().
|
|
|
|
|
|
|
|
@retval EFI_SUCCESS The requested number of pages has been allocated, zeroed
|
|
|
|
and mapped.
|
|
|
|
|
|
|
|
@return Status codes propagated from
|
|
|
|
VgpuDev->VirtIo->AllocateSharedPages() and
|
|
|
|
VirtioMapAllBytesInSharedBuffer().
|
|
|
|
**/
|
|
|
|
EFI_STATUS
|
|
|
|
VirtioGpuAllocateZeroAndMapBackingStore (
|
|
|
|
IN VGPU_DEV *VgpuDev,
|
|
|
|
IN UINTN NumberOfPages,
|
|
|
|
OUT VOID **HostAddress,
|
|
|
|
OUT EFI_PHYSICAL_ADDRESS *DeviceAddress,
|
|
|
|
OUT VOID **Mapping
|
|
|
|
);
|
|
|
|
|
|
|
|
/**
|
|
|
|
Unmap and free memory originally allocated and mapped with
|
|
|
|
VirtioGpuAllocateZeroAndMapBackingStore().
|
|
|
|
|
|
|
|
If the memory allocated and mapped with
|
|
|
|
VirtioGpuAllocateZeroAndMapBackingStore() was attached to a host-side VirtIo
|
|
|
|
GPU resource with VirtioGpuResourceAttachBacking(), then the caller is
|
|
|
|
responsible for detaching the backing store from the same resource, with
|
|
|
|
VirtioGpuResourceDetachBacking(), before calling this function.
|
|
|
|
|
|
|
|
@param[in] VgpuDev The VGPU_DEV object that represents the VirtIo GPU
|
|
|
|
device.
|
|
|
|
|
|
|
|
@param[in] NumberOfPages The NumberOfPages parameter originally passed to
|
|
|
|
VirtioGpuAllocateZeroAndMapBackingStore().
|
|
|
|
|
|
|
|
@param[in] HostAddress The HostAddress value originally output by
|
|
|
|
VirtioGpuAllocateZeroAndMapBackingStore().
|
|
|
|
|
|
|
|
@param[in] Mapping The token that was originally output by
|
|
|
|
VirtioGpuAllocateZeroAndMapBackingStore().
|
|
|
|
**/
|
|
|
|
VOID
|
|
|
|
VirtioGpuUnmapAndFreeBackingStore (
|
|
|
|
IN VGPU_DEV *VgpuDev,
|
|
|
|
IN UINTN NumberOfPages,
|
|
|
|
IN VOID *HostAddress,
|
|
|
|
IN VOID *Mapping
|
|
|
|
);
|
|
|
|
|
2016-08-18 01:31:27 +02:00
|
|
|
/**
|
|
|
|
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
|
|
|
|
);
|
|
|
|
|
2016-08-18 17:00:03 +02:00
|
|
|
/**
|
|
|
|
The following functions send requests to the VirtIo GPU device model, await
|
|
|
|
the answer from the host, and return a status. They share the following
|
|
|
|
interface details:
|
|
|
|
|
|
|
|
@param[in,out] VgpuDev The VGPU_DEV object that represents the VirtIo GPU
|
|
|
|
device. The caller is responsible to have
|
|
|
|
successfully invoked VirtioGpuInit() on VgpuDev
|
|
|
|
previously, while VirtioGpuUninit() must not have
|
|
|
|
been called on VgpuDev.
|
|
|
|
|
|
|
|
@retval EFI_INVALID_PARAMETER Invalid command-specific parameters were
|
|
|
|
detected by this driver.
|
|
|
|
|
|
|
|
@retval EFI_SUCCESS Operation successful.
|
|
|
|
|
|
|
|
@retval EFI_DEVICE_ERROR The host rejected the request. The host error
|
|
|
|
code has been logged on the EFI_D_ERROR level.
|
|
|
|
|
|
|
|
@return Codes for unexpected errors in VirtIo
|
|
|
|
messaging.
|
|
|
|
|
|
|
|
For the command-specific parameters, please consult the GPU Device section of
|
|
|
|
the VirtIo 1.0 specification (see references in
|
|
|
|
"OvmfPkg/Include/IndustryStandard/VirtioGpu.h").
|
|
|
|
**/
|
|
|
|
EFI_STATUS
|
|
|
|
VirtioGpuResourceCreate2d (
|
|
|
|
IN OUT VGPU_DEV *VgpuDev,
|
|
|
|
IN UINT32 ResourceId,
|
|
|
|
IN VIRTIO_GPU_FORMATS Format,
|
|
|
|
IN UINT32 Width,
|
|
|
|
IN UINT32 Height
|
|
|
|
);
|
|
|
|
|
|
|
|
EFI_STATUS
|
|
|
|
VirtioGpuResourceUnref (
|
|
|
|
IN OUT VGPU_DEV *VgpuDev,
|
|
|
|
IN UINT32 ResourceId
|
|
|
|
);
|
|
|
|
|
|
|
|
EFI_STATUS
|
|
|
|
VirtioGpuResourceAttachBacking (
|
2017-08-26 19:54:49 +02:00
|
|
|
IN OUT VGPU_DEV *VgpuDev,
|
|
|
|
IN UINT32 ResourceId,
|
|
|
|
IN EFI_PHYSICAL_ADDRESS BackingStoreDeviceAddress,
|
|
|
|
IN UINTN NumberOfPages
|
2016-08-18 17:00:03 +02:00
|
|
|
);
|
|
|
|
|
|
|
|
EFI_STATUS
|
|
|
|
VirtioGpuResourceDetachBacking (
|
|
|
|
IN OUT VGPU_DEV *VgpuDev,
|
|
|
|
IN UINT32 ResourceId
|
|
|
|
);
|
|
|
|
|
|
|
|
EFI_STATUS
|
|
|
|
VirtioGpuSetScanout (
|
|
|
|
IN OUT VGPU_DEV *VgpuDev,
|
|
|
|
IN UINT32 X,
|
|
|
|
IN UINT32 Y,
|
|
|
|
IN UINT32 Width,
|
|
|
|
IN UINT32 Height,
|
|
|
|
IN UINT32 ScanoutId,
|
|
|
|
IN UINT32 ResourceId
|
|
|
|
);
|
|
|
|
|
|
|
|
EFI_STATUS
|
|
|
|
VirtioGpuTransferToHost2d (
|
|
|
|
IN OUT VGPU_DEV *VgpuDev,
|
|
|
|
IN UINT32 X,
|
|
|
|
IN UINT32 Y,
|
|
|
|
IN UINT32 Width,
|
|
|
|
IN UINT32 Height,
|
|
|
|
IN UINT64 Offset,
|
|
|
|
IN UINT32 ResourceId
|
|
|
|
);
|
|
|
|
|
|
|
|
EFI_STATUS
|
|
|
|
VirtioGpuResourceFlush (
|
|
|
|
IN OUT VGPU_DEV *VgpuDev,
|
|
|
|
IN UINT32 X,
|
|
|
|
IN UINT32 Y,
|
|
|
|
IN UINT32 Width,
|
|
|
|
IN UINT32 Height,
|
|
|
|
IN UINT32 ResourceId
|
|
|
|
);
|
|
|
|
|
2016-08-17 22:45:02 +02:00
|
|
|
/**
|
|
|
|
Release guest-side and host-side resources that are related to an initialized
|
|
|
|
VGPU_GOP.Gop.
|
|
|
|
|
|
|
|
param[in,out] VgpuGop The VGPU_GOP object to release resources for.
|
|
|
|
|
|
|
|
On input, the caller is responsible for having called
|
|
|
|
VgpuGop->Gop.SetMode() at least once successfully.
|
|
|
|
(This is equivalent to the requirement that
|
|
|
|
VgpuGop->BackingStore be non-NULL. It is also
|
|
|
|
equivalent to the requirement that VgpuGop->ResourceId
|
|
|
|
be nonzero.)
|
|
|
|
|
|
|
|
On output, resources will be released, and
|
|
|
|
VgpuGop->BackingStore and VgpuGop->ResourceId will be
|
|
|
|
nulled.
|
|
|
|
|
|
|
|
param[in] DisableHead Whether this head (scanout) currently references the
|
|
|
|
resource identified by VgpuGop->ResourceId. Only pass
|
|
|
|
FALSE when VgpuGop->Gop.SetMode() calls this function
|
|
|
|
while switching between modes, and set it to TRUE
|
|
|
|
every other time.
|
|
|
|
**/
|
|
|
|
VOID
|
|
|
|
ReleaseGopResources (
|
|
|
|
IN OUT VGPU_GOP *VgpuGop,
|
|
|
|
IN BOOLEAN DisableHead
|
|
|
|
);
|
|
|
|
|
|
|
|
//
|
|
|
|
// Template for initializing VGPU_GOP.Gop.
|
|
|
|
//
|
|
|
|
extern CONST EFI_GRAPHICS_OUTPUT_PROTOCOL mGopTemplate;
|
|
|
|
|
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_
|