On Wed, Feb 10, 2021 at 02:37:31PM +0100,
Igor Mammedov <imamm...@redhat.com> wrote:
> On Tue, 9 Feb 2021 12:02:58 -0800
> Isaku Yamahata <yamahata.qemu...@gmail.com> wrote:
>
> > On Tue, Feb 09, 2021 at 04:52:41PM +0100,
> > Igor Mammedov <imamm...@redhat.com> wrote:
> >
> > > On Mon, 8 Feb 2021 13:57:25 -0800
> > > isaku.yamah...@gmail.com wrote:
> > >
> > > > From: Isaku Yamahata <isaku.yamah...@intel.com>
> > > >
> > > > Declare PNP0C01 device to reserve MMCONFIG region to conform to the
> > > > spec better and play nice with guest BIOSes/OSes.
> > > >
> > > > According to PCI Firmware Specification, MMCONFIG region must be
> > > > reserved by declaring a motherboard resource.
> > > could you point to concrete spec version/chapter where it stated.
> > > (should be part of commit message)
> >
> > PCI Firmware specification Revision 3.2
> > 4.1.2 MCFG Table Description
> > table 4-2 NOTE 2
> > If the operating system does not natively comprehend reserving the MMCFG
> > region, The MMCFG region must e reserved by firmware. ...
> > For most systems, the mortheroard resource would appear at the root of
> > the ACPI namespace (under \_SB)...
> > The resource can optionally be returned in Int15 E820h or EFIGetMemoryMap
> > as reserved memory but must always be reported through ACPI as a
> > motherboard
> > resource
> >
> > Will include it in next respin.
> >
> > >
> > > > It's optional to reserve
> > > > the region in memory map by Int 15 E820h or EFIGetMemoryMap.
> > >
> > > > If guest BIOS doesn't reserve the region in memory map without the
> > > > reservation by mother board resource, guest linux abandons to use
> > > > MMCFG.
> > > can parse this, can you rephrase and avoid double negation, please?
> >
> > How about this?
> > Guest Linux checks if the MMCFG region is reserved by bios memory map or
> > ACPI resource.
>
> > It failed, it falls back to legacy PCI configuraiton access.
> clarify what/how failed, pls.
It should be "If it's not reserved".
> > > > + * When the method of _CRS is called to determine MMCONFIG region,
> > > > + * only port io is allowed to access PCI configuration space.
> > > > + * It means qword access isn't allowed.
> > > > + *
> > > > + * Device(DRAC)
> > > > + * {
> > > > + * Name(_HID, EisaId("PNP0C01"))
> > > > + * OperationRegion(DRR0, PCI_Config, 0x0000000000000060, 0x8)
> > > > + * Field(DRR0, DWordAcc, Lock, Preserve)
> > > > + * {
> > > > + * PEBL, 4,
> > > > + * PEBH, 4
> > > > + * }
> > >
> > > why are you trying to fetch it dynamically?
> > > what prevents you from getting MMCONFIG address in QEMU when building
> > > ACPI tables and encode _CRS statically at that time?
> >
> > My motivation is to prepare for TDX where ACPI tables will be part of
> > measurement. I wanted ACPI tables to remain same irrelevant of chipset
> > configuration which guest can change.
> ACPI tables are supposed to be read from QEMU after firmware configured
> PCI subsystem, including MMCONFIG.
> If configuration is changed after that MCFG table won't be correct anymore.
> Given MCFG is statically generated, I see no reason to fetch the same info
> dynamically from DSDT.
Ok, given that other part of ACPI table generation code,
I'll switch to use MMCONFIG address in qemu.
> PS:
> goal of having fixed ACPI tables is hard to achieve in QEMU,
> it might be possible within single QEMU version for a concrete CLI
> configuration,
> but any deviation from that may trigger ACPI tables change.
>
> > Thanks,
>
Thanks,
--
Isaku Yamahata <isaku.yamah...@gmail.com>
