Dennis Chen [Mon, 5 Sep 2016 11:38:20 +0000 (19:38 +0800)]
ArmPkg ArmPlatformPkg ArmVirtPkg: ARM GICv2/v3 Base Address width fix-up
According to the ACPI 6.0/6.1 spec, the physical base address of GICC,
GICD, GICR and GIC ITS is 64-bit. So change the type of the various GIC
base address PCDs to 64-bit, and fix up all users.
OvmfPkg/QemuBootOrderLib: drop too strict "/HD(" suffix from vblk prefix
Translating QEMU's virtio-block OpenFirmware device path to a UEFI device
path prefix was one of the earliest case handled in QemuBootOrderLib. At
that time, I terminated the translation output (the UEFI devpath prefix)
with a "/HD(" suffix.
The intent was for the translation to prefix-match only boot options with
HD() device path nodes in them, that is, no auto-generated "device level"
boot options. This was motivated by prioritizing specific boot options
created by OS installers over auto-generated "device level" options.
However, practice has shown that:
- OS installers place their installed boot options first in the boot order
anyway,
- other device types (SATA disks, virtio-scsi disks), where "/HD(" is not
appended, work just fine,
- requiring "/HD(" actually causes problems: after the OS-installed
specific boot option has been lost (or purposely removed), the
auto-generated "device level" boot option does the right thing (see the
Default Boot Behavior under
<http://blog.uncooperative.org/blog/2014/02/06/the-efi-system-partition/>).
The "/HD(" requirement causes such boot options to be dropped, which
prevents "fallback.efi" from running.
Relax the matching by removing the "/HD(" suffix from the translated
prefix.
ArmPkg/DefaultExceptionHandlerLib AARCH64: add minimal backtrace to crash dump
When dumping the CPU state after an unhandled fault, walk the stack
frames and decode the return addresses so we can show a minimal
backtrace. Unfortunately, we do not have sufficient information to
show the function names, but at least we can see the modules and the
return addresses inside the modules.
The default PcdPeiIchEhciControllerMemoryBaseAddress value 0xFD000000
conflict with the default TXE SECUMA MMIO address.
So we update to 0xFC000000 to avoid conflict.
Cc: David Wei <david.wei@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: David Wei <david.wei@intel.com>
NetworkPkg/DnsDxe: Handle CNAME type responded from the name server
v2:
* Code refine.
* For DnsCache, the minimum value of TTL is selected between CNAME and A/AAAA record.
According RFC 1034 - 3.6.2, if the query name is an alias, the name server
will include the CNAME record in the response and restart the query at the
domain name specified in the data field of the CNAME record. RFC also provides
one example server action when A query received:
Suppose a name server was processing a query with for USCISIC.ARPA, asking for
type A information, and had the following resource records:
USC-ISIC.ARPA IN CNAME C.ISI.EDU
C.ISI.EDU IN A 10.0.0.52
Both of these RRs would be returned in the response to the type A query.
Currently, DnsDxe driver doesn't handle the CNAME type response, which will cause
any exception result. The driver need continue the packet parsing while CNAME type
record parsed. So, this patch is used to handle it correctly.
Cc: Hegde Nagaraj P <nagaraj-p.hegde@hpe.com> Cc: Fu Siyuan <siyuan.fu@intel.com> Cc: Ye Ting <ting.ye@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com> Reviewed-by: Fu Siyuan <siyuan.fu@intel.com> Tested-by: Hegde Nagaraj P <nagaraj-p.hegde@hpe.com>
Now that the PCI root bridge driver and various host controller drivers
have been fixed, remove the 4 GB limit on PCI DMA allocation for QEMU's
ECAM PCI host bridge.
MdeModulePkg/PciHostBridgeDxe: restrict 64-bit DMA to devices that support it
Currently, the EFI_PCI_ATTRIBUTE_DUAL_ADDRESS_CYCLE attribute is completely
ignored by the PCI host bridge driver, which means that, on an implementation
that supports DMA above 4 GB, allocations above 4 GB may be provided to
devices that have not expressed support for it.
So in addition to checking 'RootBridge->DmaAbove4G' to establish whether the
root bridge itself supports DMA above 4 GB, we must also take into account
the operation type (EfiPciOperationBusMaster{Read|Write|CommonBuffer}64),
and the EFI_PCI_ATTRIBUTE_DUAL_ADDRESS_CYCLE attribute, when mapping and
allocating DMA memory, respectively.
Jiaxin Wu [Thu, 18 Aug 2016 05:31:07 +0000 (13:31 +0800)]
MdeModulePkg: Support classless IP for DHCPv4 TransmitReceive()
The IP address should not be treated as classful one if DHCP options
contain a classless IP with its true subnet mask. Otherwise, DHCPv4
TransmitReceive() will failed. This real subnet mask will be parsed
and recorded in DhcpSb->Netmask. So, we need check it before get the
IP's corresponding subnet mask.
Cc: Santhapur Naveen <naveens@amiindia.co.in> Cc: Ye Ting <ting.ye@intel.com> Cc: Fu Siyuan <siyuan.fu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com> Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
Hao Wu [Tue, 30 Aug 2016 11:57:44 +0000 (19:57 +0800)]
MdeModulePkg NvmExpressDxe: Set the non-blocking I/O feature support bit
Since current codes in NvmExpressDxe already support the non-blocking I/O
feature for EFI_NVM_EXPRESS_PASS_THRU_PROTOCOL interface, the relative bit
in the 'Attributes' field of EFI_NVM_EXPRESS_PASS_THRU_MODE should be set
to reflect this.
MdeModulePkg NvmExpressDxe: Fix 'Event' won't be signaled for Admin cmds
This commit fixes the issue that the caller event passed to
EFI_NVM_EXPRESS_PASS_THRU_PROTOCOL.PassThru() will not be signaled for
NVME Admin commands.
Hao Wu [Tue, 30 Aug 2016 08:34:09 +0000 (16:34 +0800)]
MdeModulePkg NvmExpressDxe: Add NamespaceId validity check in PassThru
According to the UEFI spec, EFI_NVM_EXPRESS_PASS_THRU_PROTOCOL.PassThru()
should return EFI_INVALID_PARAMETER if the input 'NamespaceId' is invalid
for the NVM Express controller. This commit adds check in PassThru() to
follow this rule.
Hao Wu [Mon, 29 Aug 2016 02:12:42 +0000 (10:12 +0800)]
MdeModulePkg NvmExpressDxe: Add check for command packet in PassThru
This commit adds serveral checks for the 'Packet' parameter passed to the
EFI_NVM_EXPRESS_PASS_THRU_PROTOCOL.PassThru() API:
The check for the 'TransferLength' field in
EFI_NVM_EXPRESS_PASS_THRU_COMMAND_PACKET to make sure the value will not
exceed the maximum data transfer size allowed by a controller.
The check for the 'TransferBuffer' and 'TransferLength' fields in
EFI_NVM_EXPRESS_PASS_THRU_COMMAND_PACKET when the Opcode of an NVME
command indicates a data transfer between controller and host.
The check for the 'MetadataLength' field in
EFI_NVM_EXPRESS_PASS_THRU_COMMAND_PACKET to make sure the value is not 0
when the corresponding 'MetadataBuffer' field has a non-NULL value.
Hao Wu [Mon, 22 Aug 2016 06:11:23 +0000 (14:11 +0800)]
MdeModulePkg NvmExpressDxe: Add check on the attributes of NVME controller
According to UEFI spec, an EFI_NVM_EXPRESS_PASS_THRU_PROTOCOL with neither
EFI_NVM_EXPRESS_PASS_THRU_ATTRIBUTES_LOGICAL nor
EFI_NVM_EXPRESS_PASS_THRU_ATTRIBUTES_PHYSICAL set in the Attributes field
is an illegal configuration.
This commit adds this check in the PassThru API to follow the spec.
Hao Wu [Mon, 22 Aug 2016 05:55:52 +0000 (13:55 +0800)]
MdeModulePkg NvmExpressDxe: Add buffer alignment check in PassThru API
According to the UEFI spec, the 'TransferBuffer' and 'MetadataBuffer' used
in a data transfer should be aligned on the boundary specified by the
IoAlign field in the EFI_NVM_EXPRESS_PASS_THRU_MODE structure.
Hao Wu [Mon, 29 Aug 2016 01:01:26 +0000 (09:01 +0800)]
MdeModulePkg NvmExpressDxe: Refine GetNextNamespace API to follow spec
According to the UEFI spec,
EFI_NVM_EXPRESS_PASS_THRU_PROTOCOL.GetNextNamespace() should return
EFI_NOT_FOUND when the value pointed to by NamespaceId is the namespace ID
of the last namespace on the NVM Express controller. This commit modifies
the check for NamespaceId to follow this rule.
Hao Wu [Fri, 19 Aug 2016 03:18:42 +0000 (11:18 +0800)]
MdeModulePkg NvmExpressDxe: Refine GetNameSpace API to follow spec
According to the UEFI spec,
EFI_NVM_EXPRESS_PASS_THRU_PROTOCOL.GetNamespace() should return
EFI_NOT_FOUND when the input DevicePath is a device path node type that
the NVM Express Pass Thru driver supports, but there is not a valid
translation from DevicePath to a namespace ID. Current code will return
EFI_SUCCESS. This commit adds additional check in the GetNameSpace API to
make sure correct status is returned.
Hao Wu [Fri, 19 Aug 2016 03:08:04 +0000 (11:08 +0800)]
MdeModulePkg NvmExpressDxe: Refine BuildDevicePath API to follow spec
According to the UEFI spec,
EFI_NVM_EXPRESS_PASS_THRU_PROTOCOL.BuildDevicePath() should return
EFI_NOT_FOUND when the input NamespaceId is not valid. However, current
code returns EFI_DEVICE_ERROR instead. This commit modifies the check for
input NamespaceId to return the correct status.
Hao Wu [Fri, 26 Aug 2016 06:39:37 +0000 (14:39 +0800)]
MdeModulePkg NvmExpressDxe: Avoid crashing 'Mode' during OpenProtocol
The gBS->OpenProtocol() calls to open EFI_NVM_EXPRESS_PASS_THRU_PROTOCOL
in NvmExpress.c will crash the data in 'Mode' field of
'Private->Passthru'.
The third parameter of gBS->OpenProtocol() is an output parameter that
stores the address where a pointer to the corresponding Protocol
Interface. The current code mistakenly pass '&Private->Passthru' (a
pointer of the EFI_NVM_EXPRESS_PASS_THRU_PROTOCOL) as the third
parameter. This will crash the data in 'Mode' filed.
ArmPkg/CompilerIntrinsicsLib ARM: make memset() weak again
After the recent update of CompilerIntrinsicsLib, our memset() is no
longer emitted as a weak symbol. On ARM, this may cause problems when
combining this library with another library that supplies memset() [e.g.,
CryptoPkg/IntrinsicLib], due to the fact that the object also supplies
the __aeabi_memXXX entry points, which can only be satisfied by this
object. So make our memset() weak again, to let the other implementation
take precedence.
ArmVirtPkg/FdtPciPcdProducerLib: zero init local var to please GCC 4.8
GCC 4.8 in RELEASE mode complains about GetPciIoTranslation () potentially
not assigning IoTranslation, but does not notice that it returns failure in
this case, which means IoTranslation is never referenced *unless* it has
been assigned. So simply set IoTranslation to zero to help the compiler.
Star Zeng [Mon, 8 Aug 2016 10:20:58 +0000 (18:20 +0800)]
MdeModulePkg PiDxeS3BootScriptLib: Support multiple PCI segment
Support multiple PCI segment for PCI_CONFIG2 opcodes.
PiDxeS3BootScriptLib needs to be updated to consume PciSegmentLib
instead of PciLib. That means platforms need to add PciSegmentLib
declaration like below in platform dsc if the PciSegmentLib was
not declared in platform dsc before.
For platforms only have one segment,
MdePkg/Library/BasePciSegmentLibPci/BasePciSegmentLibPci.inf is recommended
to be used and declared in platform dsc for PiDxeS3BootScriptLib to have
equivalent functionality with before.
Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Amy Chan <amy.chan@intel.com> Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Michael Kinney <michael.d.kinney@intel.com> Tested-by: Laszlo Ersek <lersek@redhat.com>
PiDxeS3BootScriptLib will be updated to consume PciSegmentLib
instead of PciLib to support multiple PCI segment.
Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Amy Chan <amy.chan@intel.com> Cc: Kelly Steele <kelly.steele@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
Star Zeng [Fri, 19 Aug 2016 07:05:48 +0000 (15:05 +0800)]
QuarkPlatformPkg: Declare PciSegmentLib in platform dsc
PiDxeS3BootScriptLib will be updated to consume PciSegmentLib
instead of PciLib to support multiple PCI segment.
That means platforms need to add PciSegmentLib
declaration in platform dsc if the PciSegmentLib was
not declared in platform dsc before.
For platforms only have one segment,
MdePkg/Library/BasePciSegmentLibPci/BasePciSegmentLibPci.inf is recommended
to be used and declared in platform dsc for PiDxeS3BootScriptLib to have
equivalent functionality with before.
Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Amy Chan <amy.chan@intel.com> Cc: Kelly Steele <kelly.steele@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
Star Zeng [Fri, 19 Aug 2016 07:01:12 +0000 (15:01 +0800)]
Vlv2TbltDevicePkg: Declare PciSegmentLib in platform dsc
PiDxeS3BootScriptLib will be updated to consume PciSegmentLib
instead of PciLib to support multiple PCI segment.
That means platforms need to add PciSegmentLib
declaration in platform dsc if the PciSegmentLib was
not declared in platform dsc before.
For platforms only have one segment,
MdePkg/Library/BasePciSegmentLibPci/BasePciSegmentLibPci.inf is recommended
to be used and declared in platform dsc for PiDxeS3BootScriptLib to have
equivalent functionality with before.
Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Amy Chan <amy.chan@intel.com> Cc: David Wei <david.wei@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: David Wei <david.wei@intel.com> Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
Ard Biesheuvel [Sun, 21 Aug 2016 16:51:04 +0000 (18:51 +0200)]
ArmVirtPkg/FdtPciHostBridgeLib: add MMIO64 support
If the pci-host-ecam-generic DT node describes a 64-bit MMIO region,
account for it in the PCI_ROOT_BRIDGE description that we return to
the generic PciHostBridgeDxe implementation, which will be able to
allocate BARs from it without any further changes.
Ard Biesheuvel [Sun, 21 Aug 2016 16:53:34 +0000 (18:53 +0200)]
ArmVirtPkg/ArmVirtQemu: switch to generic PciHostBridgeDxe
Wire up the FdtPciHostBridgeLib introduced in the previous patch
to the generic PciHostBridgeDxe implementation, and drop the special
ArmVirtPkg version. The former's dependency on gEfiCpuIo2ProtocolGuid
is satisfied by adding ArmPciCpuIo2Dxe.inf as well, and adding the PCD
gArmTokenSpaceGuid.PcdPciIoTranslation as a dynamic PCD.
In terms of functionality, no changes are intended.
Ard Biesheuvel [Sun, 21 Aug 2016 15:34:19 +0000 (17:34 +0200)]
ArmVirtPkg: implement FdtPciHostBridgeLib
Implement PciHostBridgeLib for DT platforms that expose a PCI root bridge
via a pci-host-ecam-generic DT node. The DT parsing logic is copied from
the PciHostBridgeDxe implementation in ArmVirtPkg, with the one notable
difference that we don't set some of the legacy PCI attributes for IDE
and VGA I/O ranges.
Ard Biesheuvel [Wed, 24 Aug 2016 17:03:00 +0000 (19:03 +0200)]
ArmVirtPkg/FdtPciPcdProducerLib: add handling of PcdPciIoTranslation
Add handling of the PcdPciIoTranslation PCD, so that modules that include
this library via NULL resolution are guaranteed that it will be set before
they reference it.
Ard Biesheuvel [Sun, 21 Aug 2016 15:33:36 +0000 (17:33 +0200)]
ArmVirtPkg/PciHostBridgeDxe: don't set linux,pci-probe-only DT property
Setting the linux,pci-probe-only was intended to align OSes booting via
DT with OSes booting via ACPI in the way they honor the PCI configuration
performed by the firmware. However, ACPI on arm64 does not currently honor
the firmware's PCI configuration, and the linux,pci-probe-only completely
prevents any PCI reconfiguration from occurring under the OS, including
what is needed to support PCI hotplug.
Since the primary use case was OS access to the GOP framebuffer (which
breaks when the framebuffer BAR is moved when the OS reconfigures the
PCI), we can undo this change now that ArmVirtQemu has moved to a GOP
implementation that does not expose a raw framebuffer in the first place.
This effectively reverts commit 8b816c624dd4 ("ArmVirtPkg/VirtFdtDxe: set
/chosen/linux,pci-probe-only to 1 in DTB")
Ard Biesheuvel [Wed, 17 Aug 2016 14:36:42 +0000 (16:36 +0200)]
MdeModulePkg/EbcDxe AARCH64: simplify interpreter entry point thunks
The prototypes of EbcInterpret() and ExecuteEbcImageEntryPoint() are
private to the AARCH64 implementation of EbcDxe, so we can shuffle
the arguments around a bit and make the assembler thunking glue a lot
simpler.
For ExecuteEbcImageEntryPoint(), this involves passing the EntryPoint
argument as the third parameter, rather than the first, which allows
us to do a tail call. For EbcInterpret(), instead of copying each
argument beyond #8 from one native stack frame to the next (before
another copy is made into the VM stack), pass a pointer to the
argument stack.
Ard Biesheuvel [Wed, 17 Aug 2016 14:29:09 +0000 (16:29 +0200)]
MdeModulePkg/EbcDxe AARCH64: use tail call for EBC to native thunk
Instead of pessimistically copying at least 64 bytes from the VM stack
to the native stack, and popping off the register arguments again
before doing the native call, try to avoid touching the stack completely
if the VM stack frame is <= 64 bytes. Also, if the stack frame does exceed
64 bytes, there is no need to copy the first 64 bytes, since we are passing
those in registers anyway.
Ard Biesheuvel [Wed, 17 Aug 2016 14:24:52 +0000 (16:24 +0200)]
MdeModulePkg/EbcDxe AARCH64: use a fixed size thunk structure
The thunk generation is needlessly complex, given that it attempts to
deal with variable length instructions, which don't exist on AArch64.
So replace it with a simple template coded in assembler, with a matching
struct definition in C. That way, we can create and manipulate the thunks
easily without looping over the instructions looking for 'magic' numbers.
Also, use x16 rather than x9, since it is the architectural register to
use for thunks/veneers.
Ard Biesheuvel [Wed, 17 Aug 2016 14:08:21 +0000 (16:08 +0200)]
MdeModulePkg/EbcDxe AARCH64: clean up comment style in ASM file
Change to consistent // style comments. Also, remove bogus global
definitions for external functions, and move the real exports to
the top of the file.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Cc: Kelly Steele <kelly.steele@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Maurice Ma <maurice.ma@intel.com> Cc: Prince Agyeman <prince.agyeman@intel.com>
Laszlo Ersek [Thu, 18 Aug 2016 09:51:33 +0000 (11:51 +0200)]
ArmVirtPkg: remove PcdKludgeMapPciMmioAsCached
In ARM/AARCH64 guests that run on KVM, we can now use virtio-gpu-pci, so
PcdKludgeMapPciMmioAsCached is no longer necessary. Standard VGA continues
to work on TCG without the kludge.
In this patch we replace our "dummy" Graphics Output Protocol interface
with the real one. We exploit that EFI_GRAPHICS_OUTPUT_BLT_PIXEL and
VirtioGpuFormatB8G8R8X8Unorm have identical representations; this lets us
forego any pixel format conversions in the guest. For messaging the VirtIo
GPU device, we use the primitives introduced in the previous patch.
Laszlo Ersek [Thu, 18 Aug 2016 15:00:03 +0000 (17:00 +0200)]
OvmfPkg/VirtioGpuDxe: provide functions for sending VirtIo GPU commands
In this patch we add a "workhorse" function called VirtioGpuSendCommand(),
and implement seven simple RPCs atop, for the command types listed in
"OvmfPkg/Include/IndustryStandard/VirtioGpu.h".
These functions will be called by our EFI_GRAPHICS_OUTPUT_PROTOCOL
implementation.
Laszlo Ersek [Wed, 17 Aug 2016 23:31:27 +0000 (01:31 +0200)]
OvmfPkg/VirtioGpuDxe: initialize and tear down VirtIo GPU device
This patch implements the steps listed in section "3.1.1 Driver
Requirements: Device Initialization" of the Virtio V1.0 Committee Spec 04.
The VirtIo GPU is brought up in VirtioGpuDriverBindingStart(), and down in
VirtioGpuDriverBindingStop().
We also add an ExitBootServices() callback that resets the device. This
ensures that the device model abandons any guest memory areas when we
transfer control to the guest OS.
Laszlo Ersek [Mon, 15 Aug 2016 13:34:32 +0000 (15:34 +0200)]
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.
Laszlo Ersek [Mon, 15 Aug 2016 14:26:29 +0000 (16:26 +0200)]
OvmfPkg/IndustryStandard: add type definitions for the virtio GPU device
The GPU additions to VirtIo 1.0 are a work in progress. Mark the relevant
URLs in the source code. Incorporate the absolute minimum from the WIP
spec that is necessary for implementing a GOP driver.
Add the VIRTIO_SUBSYSTEM_GPU_DEVICE macro to
"IndustryStandard/Virtio10.h", since all other such macros (dating back to
VirtIo 0.9.5) are part of "IndustryStandard/Virtio095.h".
Laszlo Ersek [Thu, 18 Aug 2016 09:33:39 +0000 (11:33 +0200)]
OvmfPkg/PlatformBootManagerLib: relax device class requirement for ConOut
This will add virtio-gpu-pci devices to ConOut automatically.
For further benefit, the change also allows OVMF to use the legacy-free /
secondary VGA adapter (added in QEMU commit 63e3e24d, "vga: add secondary
stdvga variant") as console.
ArmVirtPkg's PlatformBootManagerLib already filters with IS_PCI_DISPLAY();
see IsPciDisplay().