summaryrefslogtreecommitdiffstats
path: root/OvmfPkg/VirtioGpuDxe
Commit message (Collapse)AuthorAgeFilesLines
* OvmfPkg: replace old EFI_D_ debug levels with new DEBUG_ onesRebecca Cran2020-04-303-9/+9
| | | | | | | | | | | | | Generated mechanically with: find OvmfPkg -type f -exec sed -i -e 's/EFI_D_/DEBUG_/g' {} \; Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Cc: Philippe Mathieu-Daude <philmd@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200429215327.606467-1-rebecca@bsdio.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Replace BSD License with BSD+Patent LicenseMichael D Kinney2019-04-095-35/+5
| | | | | | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=1373 Replace BSD 2-Clause License with BSD+Patent License. This change is based on the following emails: https://lists.01.org/pipermail/edk2-devel/2019-February/036260.html https://lists.01.org/pipermail/edk2-devel/2018-October/030385.html RFCs with detailed process for the license change: V3: https://lists.01.org/pipermail/edk2-devel/2019-March/038116.html V2: https://lists.01.org/pipermail/edk2-devel/2019-March/037669.html V1: https://lists.01.org/pipermail/edk2-devel/2019-March/037500.html Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/VirtioGpuDxe: don't unmap VRING & BackingStore at ExitBootServicesLaszlo Ersek2017-09-081-22/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | In one of the following patches, we'll change OvmfPkg/IoMmuDxe so that it unmaps all existent bus master operations (CommonBuffer, Read, Write) at ExitBootServices(), strictly after the individual device drivers abort pending DMA on the devices they manage, in their own ExitBootServices() notification functions. In preparation, remove the explicit VIRTIO_DEVICE_PROTOCOL.UnmapSharedBuffer() calls from VirtioGpuExitBoot(), originally added in commit 9bc5026c19a5 ("OvmfPkg/VirtioGpuDxe: map VRING for bus master common buffer operation", 2017-08-26) and commit f10ae923665f ("OvmfPkg/VirtioGpuDxe: map backing store to bus master device address", 2017-08-26). Add a DEBUG message so we can observe the ordering between VirtioGpuExitBoot() and the upcoming cleanup of mappings in OvmfPkg/IoMmuDxe. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg/VirtioGpuDxe: negotiate VIRTIO_F_IOMMU_PLATFORMLaszlo Ersek2017-09-011-1/+1
| | | | | | | | | | | | | | | VirtioGpuDxe is now IOMMU-clean; it translates system memory addresses to bus master device addresses. Negotiate VIRTIO_F_IOMMU_PLATFORM in parallel with VIRTIO_F_VERSION_1. (Note: the VirtIo GPU device, and this driver, are virtio-1.0 only (a.k.a. "modern-only").) 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>
* OvmfPkg/VirtioGpuDxe: map backing store to bus master device addressLaszlo Ersek2017-09-013-20/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* OvmfPkg/VirtioGpuDxe: helpers for backing store (de)allocation+(un)mappingLaszlo Ersek2017-09-014-2/+188
| | | | | | | | | | | | | | | | | | | | Introduce the VirtioGpuAllocateZeroAndMapBackingStore() and VirtioGpuUnmapAndFreeBackingStore() helper functions. These functions tie together the allocation, zeroing and mapping, and unmapping and deallocation, respectively, of memory that the virtio GPU will permanently reference after receiving the RESOURCE_ATTACH_BACKING command. With these functions we can keep the next patch simpler -- the GOP implementation in "Gop.c" retains its error handling structure, and remains oblivious to VIRTIO_DEVICE_PROTOCOL and VirtioLib. 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>
* OvmfPkg/VirtioGpuDxe: take EFI_PHYSICAL_ADDRESS in ResourceAttachBacking()Laszlo Ersek2017-09-013-13/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The RESOURCE_ATTACH_BACKING virtio GPU command assigns guest-side backing pages to a host-side resource that was created earlier with the RESOURCE_CREATE_2D command. We compose the RESOURCE_ATTACH_BACKING command in the VirtioGpuResourceAttachBacking() function. Currently this function takes the parameter IN VOID *FirstBackingPage This is only appropriate as long as we pass a (guest-phys) system memory address to the device. In preparation for a mapped bus master device address, change the above parameter to IN EFI_PHYSICAL_ADDRESS BackingStoreDeviceAddress In order to keep the current call site functional, move the (VOID*) to (UINTN) conversion out of the function, to the call site. The "Request.Entry.Addr" field already has type UINT64. This patch is similar to commit 4b725858de68 ("OvmfPkg/VirtioLib: change the parameter of VirtioAppendDesc() to UINT64", 2017-08-23). 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>
* OvmfPkg/VirtioGpuDxe: map virtio GPU command objects to device addressesLaszlo Ersek2017-09-011-8/+75
| | | | | | | | | | | | | | | | | | | | | | | | Every virtio GPU command used by VirtioGpuDxe is synchronous and formatted as a two-descriptor chain: request, response. The internal workhorse function that all the command-specific functions call for such messaging is VirtioGpuSendCommand(). In VirtioGpuSendCommand(), map the request from system memory to bus master device address for BusMasterRead operation, and map the response from system memory to bus master device address for BusMasterWrite operation. Pass the bus master device addresses to VirtioAppendDesc(). (See also commit 4b725858de68, "OvmfPkg/VirtioLib: change the parameter of VirtioAppendDesc() to UINT64", 2017-08-23.) 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>
* OvmfPkg/VirtioGpuDxe: map VRING for bus master common buffer operationLaszlo Ersek2017-09-012-3/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* OvmfPkg/Virtio: take RingBaseShift in SetQueueAddress()Brijesh Singh2017-08-251-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | For the case when an IOMMU is used for translating system physical addresses to DMA bus master addresses, the transport-independent virtio device drivers will be required to map their VRING areas to bus addresses with VIRTIO_DEVICE_PROTOCOL.MapSharedBuffer() calls. - MMIO and legacy virtio transport do not support IOMMU to translate the addresses hence RingBaseShift will always be set to zero. - modern virtio transport supports IOMMU to translate the address, in next patch we will update the Virtio10Dxe to use RingBaseShift offset. Suggested-by: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> [lersek@redhat.com: remove commit msg paragraph with VirtioLib reference] [lersek@redhat.com: fix typo in VIRTIO_SET_QUEUE_ADDRESS comment block] Reviewed-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/VirtioLib: take VirtIo instance in VirtioRingInit/VirtioRingUninitBrijesh Singh2017-08-251-3/+4
| | | | | | | | | | | | | | Passing the VirtIo protocol instance will allow the vring to use VIRTIO_DEVICE_PROTOCOL.AllocateSharedPages () to allocate vring buffer. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Make more use of ARRAY_SIZE()Gary Lin2016-10-271-4/+3
| | | | | | | | | | | | Convert the remaining pieces to make the code shorter and more readable. Cc: Justen Jordan <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gary Lin <glin@suse.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: tweak subject line] Signed-off-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/VirtioGpuDxe: Fix VS toolchain build failureDandan Bi2016-09-221-1/+2
| | | | | | | | | | | | | V2: add the assert codes. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Liming Gao <liming.gao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: fix up subject line] Signed-off-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/VirtioGpuDxe: implement EFI_GRAPHICS_OUTPUT_PROTOCOLLaszlo Ersek2016-09-014-23/+719
| | | | | | | | | | | | | | | 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. 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>
* OvmfPkg/VirtioGpuDxe: provide functions for sending VirtIo GPU commandsLaszlo Ersek2016-09-012-1/+439
| | | | | | | | | | | | | | | | 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. 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>
* OvmfPkg/VirtioGpuDxe: initialize and tear down VirtIo GPU deviceLaszlo Ersek2016-09-014-1/+311
| | | | | | | | | | | | | | | | | | 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. 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>
* OvmfPkg/VirtioGpuDxe: introduce with Component Name 2 and Driver BindingLaszlo Ersek2016-09-013-0/+984
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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-18 16:44:15 +0000