On Tue, Mar 03, 2020 at 02:01:56PM +0100, Joerg Roedel wrote: > 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? Not necessarily. E.g. some power systems have neither. There are also systems looking to bypass ACPI e.g. for boot speed. > > - 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. That sentence doesn't really answer the question, does it? > And defining an > own ACPI table type seems very much possible. Frankly with platform specific interfaces like ACPI, virtio-iommu is much less compelling. Describing topology as part of the device in a way that is first, portable, and second, is a good fit for hypervisors, is to me one of the main reasons virtio-iommu makes sense at all. > > Regards, > > Joerg
