> On Wed, 22 Jun 2022 at 17:35, Ard Biesheuvel wrote:
> >
> > On Tue, 21 Jun 2022 at 23:28, Nicolas Ojeda Leon wrote:
> > >
> > > Increased control is provided in Ovmf platforms to define and
> > > configure the specifications of multiple PCI host bridges in the
> > > hypervisor. The host
Include HardwareInfoLib classes in the IntelTdxX64.dsc for this
platform to use it during build given that PciHostBridgeUtilityLib
depends on it.
Cc: Alexander Graf
Cc: Gerd Hoffmann
Cc: Ard Biesheuvel
Signed-off-by: Nicolas Ojeda Leon
---
OvmfPkg/IntelTdx/IntelTdxX64.dsc | 2 ++
1 file
Include DxeHardwareInfoLib class in the common ArmVirt.dsc.inc so that
ArmVirt* platforms use it during build given that PciHostBridgeUtilityLib
depends on it.
Cc: Alexander Graf
Cc: Gerd Hoffmann
Cc: Ard Biesheuvel
Signed-off-by: Nicolas Ojeda Leon
---
ArmVirtPkg/ArmVirt.dsc.inc | 1 +
In past days, a patch series to support multiple PCI host bridges in Ovmf
was merged which caused an error in ArmVirtQemuKernel.dsc build, part
of the CI pipeline.
These 2 commits aim at fixing this issue by adding the HardwareInfoLib
to all ArmVirt* platofrms as well as for IntelTdx which were
Consume the host-provided specification of PCI host bridges if
available. Using the DxeHardwareInfoLib, populate a list of
hardware descriptors based on the content of the "hardware-info"
fw-cfg file, if provided. In the affirmative case, use the
resources and attributes specified by the
Read the "hardware-info" item from fw-cfg to extract specifications
of PCI host bridges and analyze the 64-bit apertures of them to
find out the highest 64-bit MMIO address required which determines
the address space required by the guest, and, consequently, the
FirstNonAddress used to calculate
Define the HardwareInfoLib API and create the PeiHardwareInfoLib
which implements it, specifically for Pei usage, supporting
only static accesses to parse data directly from a fw-cfg file.
All list-like APIs are implemented as unsupported and only a
fw-cfg wrapper to read hardware info elements is
Increased control is provided in Ovmf platforms to define and configure
the specifications of multiple PCI host bridges in the hypervisor. The
host propagates this information to the guest, initially through fw-cfg
interface.
In some AWS EC2 platforms, we expose a PCI topology including several
Hi,
Following the discussion, could these patches already be merged?
Best regards,
Nicolas
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Hi Gerd,
> Is there some way to (a) figure ovmf runs on aws, and (b) figure what the
> physical address space is?
We do not have a straight way to do either at the moment without adding
something else which we would prefer to avoid.
> (keeping the series as-is is fine with me too).
If you
Consume the host-provided specification of PCI host bridges if
available. Using the DxeHardwareInfoLib, populate a list of
hardware descriptors based on the content of the "hardware-info"
fw-cfg file, if provided. In the affirmative case, use the
resources and attributes specified by the
Read the "hardware-info" item from fw-cfg to extract specifications
of PCI host bridges and analyze the 64-bit apertures of them to
find out the highest 64-bit MMIO address required which determines
the address space required by the guest, and, consequently, the
FirstNonAddress used to calculate
Define the HardwareInfoLib API and create the PeiHardwareInfoLib
which implements it, specifically for Pei usage, supporting
only static accesses to parse data directly from a fw-cfg file.
All list-like APIs are implemented as unsupported and only a
fw-cfg wrapper to read hardware info elements is
Increased control is provided in Ovmf platforms to define and configure
the specifications of multiple PCI host bridges in the hypervisor. The
host propagates this information to the guest, initially through fw-cfg
interface.
In some AWS EC2 platforms, we expose a PCI topology including several
>> > Hmm, so you are hiding the #define here to avoid updating
>> > Protocol/PciHostBridgeResourceAllocation.h ...
>> >
>> > I suspect if this can't be implemented in the pci enumerator alone there
>> > is just no way around actually extending uefi protocols. But it's also
>> > not fully clear
Hi Gerd,
> Hmm, so you are hiding the #define here to avoid updating
> Protocol/PciHostBridgeResourceAllocation.h ...
>
> I suspect if this can't be implemented in the pci enumerator alone there is
> just no way around actually extending uefi protocols. But it's also not
> fully clear to me
Hi Gerd,
> Also: Maybe split this series into two? One for the host-provided bridges,
> and another for the pre-populated bars? So the former can already be merged
> while the later is still sorted?
Is it already possible for someone to merge the first 5 patches or should I
submit a new
Extend the PCI BAR placement logic in order to consider pre-populated
resources first, if indicated by the Pcd token for such purpose.
The PCI_BAR type is augmented by one field for mapping the absolute
address of prepopulated BARs into a root bridge relative offset.
As part of the
Enhance the PCI Resource Allocation services to include a new state in
which only the base address of each root bridge is set. This new, partial
state is used in conjunction with GetProposedResources to retrieve the
Base Addresses of the resources before the allocation takes place, and
is reached
Create a new PCD boolean token in MdeModulePkg for global use.
We use this token to indicate if the configuration, parsed from
fw-cfg, requires pre-populated BARs to be preserved.
During creation of root bridges configurations, the flag is set
according to the "pre-populated-bars" item in fw-cfg.
Consume the host-provided specification of PCI host bridges if
available. Using the DxeHardwareInfoLib, populate a list of
hardware descriptors based on the content of the "hardware-info"
fw-cfg file, if provided. In the affirmative case, use the
resources and attributes specified by the
Read the "hardware-info" item from fw-cfg to extract specifications
of PCI host bridges and analyze the 64-bit apertures of them to
find out the highest 64-bit MMIO address required which determines
the address space required by the guest, and, consequently, the
FirstNonAddress used to calculate
Define the HardwareInfoLib API and create the PeiHardwareInfoLib
which implements it, specifically for Pei usage, supporting
only static accesses to parse data directly from a fw-cfg file.
All list-like APIs are implemented as unsupported and only a
fw-cfg wrapper to read hardware info elements is
Increased control is provided in Ovmf platforms to define and configure
the specifications of multiple PCI host bridges in the hypervisor. The
host propagates this information to the guest, initially through fw-cfg
interface.
In some AWS EC2 platforms, we expose a PCI topology including several
Extend the PCI BAR placement logic in order to consider pre-populated
resources first, if indicated by the Pcd token for such purpose.
The PCI_BAR type is augmented by one field for mapping the absolute
address of prepopulated BARs into a root bridge relative offset.
As part of the
Extend the PCI host bridge resource allocation protocol to include one
more service that retrieves the base addresses of all resources of a
given root bridge.
The service is defined to provide, on runtime, the possibility to fetch
the base addresses of a root bridge, replicating the address
Create a new PCD boolean token in MdeModulePkg for global use.
We use this token to indicate if the configuration, parsed from
fw-cfg, requires pre-populated BARs to be preserved.
During creation of root bridges configurations, the flag is set
according to the "pre-populated-bars" item in fw-cfg.
Consume the host-provided specification of PCI host bridges if
available. Using the DxeHardwareInfoLib, populate a list of
hardware descriptors based on the content of the "hardware-info"
fw-cfg file, if provided. In the affirmative case, use the
resources and attributes specified by the
Read the "hardware-info" item from fw-cfg to extract specifications
of PCI host bridges and analyze the 64-bit apertures of them to
find out the highest 64-bit MMIO address required which determines
the address space required by the guest, and, consequently, the
FirstNonAddress used to calculate
Define the HardwareInfoLib API and create the PeiHardwareInfoLib
which implements it, specifically for Pei usage, supporting
only static accesses to parse data directly from a fw-cfg file.
All list-like APIs are implemented as unsupported and only a
fw-cfg wrapper to read hardware info elements is
Increased control is provided in Ovmf platforms to define and configure
the specifications of multiple PCI host bridges in the hypervisor. The
host propagates this information to the guest, initially through fw-cfg
interface.
In some AWS EC2 platforms, we expose a PCI topology including several
> Why do you need the former? To figure the highest address used in PEI,
> whereas the DXE drivers use the other one?
Yes that's right.
> Usual naming convention for that case would be PeiHardwareInfoLib +
> DxeHardwareInfoLib ...
Understood, will change the naming to comply with the
Hi Gerd,
> Hmm, the QemuFwCfgHardwareInfoLib.inf file created by patch #2 has
> HardwareInfoPciHostBridgeLib.c + QemuFwCfgHardwareInfoLib.c too.
> I'm wondering why you add two inf files in the first place?
My idea was to provide 2 variations of the library:
- One offering no dynamic memory
Extend the PCI host bridge resource allocation protocol to include one
more service that retrieves the base addresses of all resources of a
given root bridge.
The service is defined to provide, on runtime, the possibility to fetch
the base addresses of a root bridge, replicating the address
Create a new PCD boolean token in MdeModulePkg for global use.
We use this token to indicate if the configuration, parsed from
fw-cfg, requires pre-populated BARs to be preserved.
During creation of root bridges configurations, the flag is set
according to the "pre-populated-bars" item in fw-cfg.
Consume the host-provided specification of PCI host bridges if
available. Using the Hardware Info library, populate a list of
hardware descriptors based on the content of the "hardware-info"
fw-cfg file, if provided. In the affirmative case, use the
resources and attributes specified by the
Extend the PCI BAR placement logic in order to consider pre-populated
resources first, if indicated by the Pcd token for such purpose.
The PCI_BAR type is augmented by one field for mapping the absolute
address of prepopulated BARs into a root bridge relative offset.
As part of the
Read the "hardware-info" item from fw-cfg to extract specifications
of PCI host bridges and analyze the 64-bit apertures of them to
find out if 64-bit PCI size needs to be increased in order to
allocate enough address space to fit all the host bridges in a
valid region.
Using the static Hardware
Increased control is provided in Ovmf platforms to define and configure
the specifications of multiple PCI host bridges in the hypervisor. The
host propagates this information to the guest, initially through fw-cfg
interface.
In some AWS EC2 platforms, we expose a PCI topology including several
Create QemuFwCfgHardwareInfoLib which extends the base HardwareInfoLib
and provide fw-cfg wrappers to read hardware info elements out of a
fw-cfg file.
The Hardware Info library is intended to describe non-discoverable
hardware information and share that from the host to the guest in Ovmf
40 matches
Mail list logo
