On 05/19/16 10:52, Ni, Ruiyu wrote: > > > Regards, > Ray > >>-----Original Message----- >>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo >>Ersek >>Sent: Thursday, May 19, 2016 4:08 PM >>To: Ni, Ruiyu <ruiyu...@intel.com>; edk2-de...@ml01.01.org >>Cc: Gao, Liming <liming....@intel.com> >>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 <ruiyu...@intel.com> >>> Cc: Liming Gao <liming....@intel.com> >>> --- >>> 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 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. 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. 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). Thanks! Laszlo >>Reviewed-by: Laszlo Ersek <ler...@redhat.com> >>_______________________________________________ >>edk2-devel mailing list >>edk2-devel@lists.01.org >>https://lists.01.org/mailman/listinfo/edk2-devel > _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
