Hi Eric, On Tue, Mar 03, 2020 at 11:19:20AM +0100, Auger Eric wrote: > Michael has pushed this solution (putting the "configuration in the PCI > config space"), I think for those main reasons: > - ACPI may not be supported on some archs/hyps But on those there is device-tree, right? > - the virtio-iommu is a PCIe device so binding should not need ACPI > description The other x86 IOMMUs are PCI devices too and they definitly need a ACPI table to be configured. > Another issue with ACPI integration is we have different flavours of > tables that exist: IORT, DMAR, IVRS An integration with IORT might be the best, but if it is not possible ther can be a new table-type for Virtio-iommu. That would still follow platform best practices. > x86 ACPI integration was suggested with IORT. But it seems ARM is > reluctant to extend IORT to support para-virtualized IOMMU. So the VIOT > was proposed as a different atternative in "[RFC 00/13] virtio-iommu on > non-devicetree platforms" > (https://patchwork.kernel.org/cover/11257727/). Proposing a table that > may be used by different vendors seems to be a challenging issue here. Yeah, if I am reading that right this proposes a one-fits-all solution. That is not needed as the other x86 IOMMUs already have their tables defined and implemented. There is no need to change anything there. > So even if the above solution does not look perfect, it looked a > sensible compromise given the above arguments. Please could you explain > what are the most compelling arguments against it? It is a hack and should be avoided if at all possible. And defining an own ACPI table type seems very much possible. Regards, Joerg
