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

[Isaku Yamahata]

On Wed, Feb 10, 2021 at 02:37:31PM +0100,
Igor Mammedov <imammedo@redhat.com> wrote:

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

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.yamahata@gmail.com>