Hey Nadav,
On 03.10.22 19:34, Nadav Amit wrote:
On Oct 3, 2022, at 8:03 AM, Vitaly Kuznetsov <vkuznets@xxxxxxxxxx> wrote:
Not my but rather PCI maintainer's call but IMHO dropping 'const' is
better, introducing a new global var is our 'last resort' and should be
avoided whenever possible. Alternatively, you can add a
raw_pci_ext_ops_preferred() function checking somethin within 'struct
hypervisor_x86' but I'm unsure if it's better.
Also, please check Alex' question/suggestion.
Here is my take (and Ajay knows probably more than me):
Looking briefly on MCFG, I do not see a clean way of using the ACPI table.
The two options are either to use a reserved field (which who knows, might
be used one day) or some OEM ID. I am also not familiar with
PCI_COMMAND.MEMORY=0, so Ajay can hopefully give some answer about that.
Anyhow, I understand (although not relate) to the objection for a new global
variable. How about explicitly calling this hardware bug a “bug” and using
the proper infrastructure? Calling it explicitly a bug may even push whoever
can to resolve it.
I am a lot more concerned with how we propagate it externally than
within Linux. If we hard code that all Linux kernels 6.2+ that are
running in VMware prefer ECAM over PIO, we lock ourselves into that
stance for better or worse, which means:
* All past and future versions of any VMware hypervisor product have to
always allow ECAM access for any PCIe config space write
* No other hypervisor benefits from any of this without upstream code change
* No real hardware platform benefits from this without upstream code change
By moving it into MCFG, we can create a path for the outside environment
to tell the OS whether it's safe to use ECAM always. This obviously
doesn't work with MCFG as it stands today, we'd have to propose an MCFG
spec change to the PCI SIG's "PCI Firmware Specification" to add the
respective field. Future VMware versions could then always expose the
flag - and if you find it broken, remove it again.
Putting all of the logic on which system potentially prefers ECAM over
PIO config space access into Linux is just a big hack that we should
avoid as much as possible.
Alex
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879
