[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 6/9] hw/i386: declare ACPI mother board resource for MMCON
From: |
Isaku Yamahata |
Subject: |
Re: [PATCH v2 6/9] hw/i386: declare ACPI mother board resource for MMCONFIG region |
Date: |
Tue, 9 Feb 2021 12:02:58 -0800 |
User-agent: |
Mutt/1.10.1 (2018-07-13) |
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.
> > + * 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.
Thanks,
--
Isaku Yamahata <isaku.yamahata@gmail.com>
- Re: [PATCH v2 3/9] acpi/core: always set SCI_EN when SMM isn't supported, (continued)
[PATCH v2 1/9] checkpatch: don't emit warning on newly created acpi data files, isaku . yamahata, 2021/02/08
[PATCH v2 2/9] qtest: update tests/qtest/bios-tables-test-allowed-diff.h, isaku . yamahata, 2021/02/08
[PATCH v2 4/9] acpi: set fadt.smi_cmd to zero when SMM is not supported, isaku . yamahata, 2021/02/08
[PATCH v2 6/9] hw/i386: declare ACPI mother board resource for MMCONFIG region, isaku . yamahata, 2021/02/08
Re: [PATCH v2 6/9] hw/i386: declare ACPI mother board resource for MMCONFIG region, Michael S. Tsirkin, 2021/02/10
[PATCH v2 5/9] acpi: add test case for smm unsupported -machine smm=off, isaku . yamahata, 2021/02/08
[PATCH v2 9/9] qtest/acpi/bios-tables-test: update acpi tables, isaku . yamahata, 2021/02/08
[PATCH v2 7/9] i386: acpi: Don't build HPET ACPI entry if HPET is disabled, isaku . yamahata, 2021/02/08