On 19 May 2016 at 12:04, Laszlo Ersek <[email protected]> wrote: > On 05/19/16 10:52, Ni, Ruiyu wrote: >> >> >> Regards, >> Ray >> >>>-----Original Message----- >>>From: edk2-devel [mailto:[email protected]] On Behalf Of >>>Laszlo Ersek >>>Sent: Thursday, May 19, 2016 4:08 PM >>>To: Ni, Ruiyu <[email protected]>; [email protected] >>>Cc: Gao, Liming <[email protected]> >>>Subject: Re: [edk2] [Patch] MdeModulePkg/PciHostBridgeDxe: Add CpuArch >>>protocol dependency >>> >>>On 05/19/16 09:17, Ruiyu Ni wrote: >>>> The driver entry point calls gDS->SetMemorySpaceAttributes(). >>>> This interface may return EFI_NOT_AVAILABLE_YET when CPU Arch >>>> protocol is not available. >>>> So we need to list CpuArch protocol in its INF dependency section. >>>> >>>> Contributed-under: TianoCore Contribution Agreement 1.0 >>>> Signed-off-by: Ruiyu Ni <[email protected]> >>>> Cc: Liming Gao <[email protected]> >>>> --- >>>> MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf | 3 ++- >>>> 1 file changed, 2 insertions(+), 1 deletion(-) >>>> >>>> diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf >>>b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf >>>> index ab5d87e..d8b0439 100644 >>>> --- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf >>>> +++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf >>>> @@ -52,4 +52,5 @@ [Protocols] >>>> >>>> [Depex] >>>> gEfiCpuIo2ProtocolGuid AND >>>> - gEfiMetronomeArchProtocolGuid >>>> + gEfiMetronomeArchProtocolGuid AND >>>> + gEfiCpuArchProtocolGuid >>>> >>> >>>This reminds me of commit f9a8be423cdd5: >>> >>>> Because gDS->SetMemorySpaceAttributes() is ultimately implemented by >>>> EFI_CPU_ARCH_PROTOCOL.SetMemoryAttributes() -- see >>>> "MdeModulePkg/Core/Dxe/Gcd/Gcd.c" and "ArmPkg/Drivers/CpuDxe/" -- we >>>> add the CPU architectural protocol to the module's DepEx. >> >> >> >> I saw the ArmVirtPkg/PciHostBridge driver set the MMIO to WB when >> >> PcdKludgeMapPciMmioAsCache is TRUE. >> >> So ArmVirtQemu platform cannot use the MdeModulePkg/PciHostBridge. >> >> Is my understanding right? > > Yes, your understanding is right; that's our main blocker. > > Please see: <https://github.com/tianocore/edk2/issues/84>. > >> Do you have any solution? > > Not yet. > > Ard's recent argument was that it should be considered a KVM bug > actually. I don't object to that idea at all, but it's not something I > can fix. So if it's a KVM bug indeed, it remains a blocker for me > nonetheless. >
The reasoning is that the current KVM behavior is justified as the expected result of cache coherent DMA, while I think that is incorrect. MMIO windows exposed by PCI are disjoint from RAM, and writes into such a window can only be observed by the device if they ultimately reach this window, so it *never* makes sense to use cacheable mappings here. The problem is that KVM on ARM uses host RAM to emulate these virtual device regions, which means that the emulated device uses cached mappings for memory that the guest may have mapped as uncached. So the correct fix is for either KVM or QEMU to perform explicit cache maintenance on the regions it exposes to the guest as framebuffers or other MMIO regions with memory semantics. > The longer-term idea is a driver for QEMU's virtio-gpu device. The > specification of that QEMU device is under review for the official > virtio spec. Once it is accepted, I plan to implement a virtio-gpu > driver for OvmfPkg and ArmVirtPkg. With that device and driver, we can > (hopefully!) drop support for the legacy VGA device in ArmVirtPkg. > /me puts some beer in the fridge for the day Laszlo completes this task > With VGA gone, we won't have any write-combining device where KVM backs > a PCI MMIO BAR with cacheable host memory. This will side-step the > caching issue, and we should be able to migrate to the core > PciHostBridgeDxe. > > On the other hand... the virtio-gpu device would require a GOP that is > Blt()-only. That is, no direct framebuffer access. I very much hope this > is not a problem for the edk2 code. I don't know if bootloaders like > grub2 will be able to deal with it. (But, at least grub2 can be patched. > Not sure about Windows-on-aarch64.) For runtime OSes (on aarch64), we > expect that they ship a native virtio-gpu driver by default. > I suppose this blt-only issue goes away as well once we fix the KVM host cached mappings issue? > This situation is really annoying. :( I have zero clue why the ARMv8 > architecture decided to combine guest and host caching attributes like > this (i.e., why the strictest of the two takes effect, rather than the > laxest). > Good question. I heard a reasonably convincing sounding explanation from Peter at some point, but my memory fails me _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
