64F5B107-317A-4857-9D71-5C4165493076
Regards, Ray >-----Original Message----- >From: Laszlo Ersek [mailto:[email protected]] >Sent: Tuesday, May 17, 2016 8:23 PM >To: Ni, Ruiyu <[email protected]> >Cc: [email protected] >Subject: Re: [edk2] [Patch 0/4] MdeModulePkg/PciBus Do not improperly degrade >resource > >On 05/17/16 04:03, Ruiyu Ni wrote: >> The patch serials refined the PciBus code and adds a new feature following >> PI spec 1.4a to not improperly degrade resource. >> >> Ruiyu Ni (4): >> MdeModulePkg/PciBus: use better name for local variables. >> MdeModulePkg/PciBus: Remove unused fields in PCI_BAR >> MdeModulePkg/PciBus: Use shorter global variable name >> MdeModulePkg/PciBus: do not improperly degrade resource >> >> MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c | 6 +-- >> MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h | 5 +- >> .../Bus/Pci/PciBusDxe/PciEnumeratorSupport.c | 58 >> +++++++++++++++++----- >> .../Bus/Pci/PciBusDxe/PciResourceSupport.c | 26 ++++++---- >> 4 files changed, 65 insertions(+), 30 deletions(-) >> > >* Please add the following reference to patch #4: > >https://mantis.uefi.org/mantis/view.php?id=1529 I think it might not be proper to include the member only web page in the commit message. > >* I'm interested in this work primarily due to GPU assignment to >QEMU/KVM virtual machines. So I built OVMF applied with these patches, >and checked if they made a difference for the PCI resource map, with an >Nvidia GTX750 assigned to the guest. > >There's no difference; the 256MB BAR is still allocated under 4GB. > >* Apparently, EFI_INCOMPATIBLE_PCI_DEVICE_SUPPORT_PROTOCOL must be a >singleton protocol; it should come from the platform firmware, not from >the option ROM. In that case, how could OVMF implement this protocol, so >that such a GPU BAR would be allocated high? Option ROM depends on the PCI resource assignment so it's like a chicken-egg problem if we let option rom produce such protocol. Singleton is enough I think. > >Looking at the CheckDevice() spec, I guess we could hard-code some PCI >vendor and device IDs, and set AddrSpaceGranularity to 64. However, >that's the only thing we should do; I don't think we should do the rest >of the PCI BAR probing. PCI BAR probing is still needed. We do not change the granularity for 32bit BAR. > >... The only thing I'd like to say to the resource allocator is, > > If CSM is disabled, then please don't degrade the MMIO64 BARs of this > device, just because it has an oprom. > >(In fact, the device is not an incompatible PCI device.) I agree. But another rule is MdeModulePkg cannot depend on IntelFrameworkPkg. PciBusDxe is in MdeModulePkg; LegacyBios protocol is defined in IntelFrameworkPkg. > >* By following the links in Mantis #1529 (recursively), I arrived at a >message that points to the following driver: > > MdeModulePkg/Bus/Pci/IncompatiblePciDeviceSupportDxe > >OVMF does not include this driver at the moment. It is a small driver >and I guess we could fork it for OvmfPkg, but how should we fill in the >"mIncompatiblePciDeviceList" array? > Try to use below value to disable all MMIO degrade. Not tested. GLOBAL_REMOVE_IF_UNREFERENCED UINT64 mIncompatiblePciDeviceList[] = { // // DEVICE_INF_TAG, // PCI_DEVICE_ID (VendorID, DeviceID, Revision, SubVendorId, SubDeviceId), // DEVICE_RES_TAG, // ResType, GFlag , SFlag, Granularity, RangeMin, // RangeMax, Offset, AddrLen // DEVICE_INF_TAG, PCI_DEVICE_ID(DEVICE_ID_NOCARE, DEVICE_ID_NOCARE, DEVICE_ID_NOCARE, DEVICE_ID_NOCARE, DEVICE_ID_NOCARE), DEVICE_RES_TAG, PCI_BAR_TYPE_MEM, PCI_ACPI_UNUSED, PCI_ACPI_UNUSED, 64, PCI_ACPI_UNUSED, PCI_BAR_OLD_ALIGN, PCI_BAR_ALL, PCI_BAR_NOCHANGE, >Thanks >Laszlo _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
