Re: [PATCH v2 6/9] hw/i386: declare ACPI mother board resource for MMCONFIG region

[Igor Mammedov]

On Tue, 9 Feb 2021 12:02:58 -0800
Isaku Yamahata <yamahata.qemudev@gmail.com> wrote:

> On Tue, Feb 09, 2021 at 04:52:41PM +0100,
> Igor Mammedov <imammedo@redhat.com> wrote:
> 
> > On Mon,  8 Feb 2021 13:57:25 -0800
> > isaku.yamahata@gmail.com wrote:
> >   
> > > From: Isaku Yamahata <isaku.yamahata@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.

 
> > > +     * 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.

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,