On Sat, Sep 20, 2014 at 10:05 PM, Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx> wrote: > On Sun, 2014-09-21 at 15:03 +1000, Benjamin Herrenschmidt wrote: > >> The exception I mentioned is that I would really like the virtio device >> to expose via whatever transport we chose to use (though capability >> exchange sounds like a reasonable one) whether the "server" >> implementation is bypassing IOMMUs or not instead on relying on client >> side heuristics. >> >> IE. Basically, we are trying to "guess" with an ifdef CONFIG_PPC, what >> is essentially an attribute of the server-side, ie, whether is bypasses >> the iommu for the PCI bus it resides on. > >> I believe all the arguments about whether this should be a bus property >> or whether the x86 case can be worked around via ACPI tables etc... are >> all moot. Today, qemu implementation can put virtio devices on busses >> with an iommu and bypass it, so at the very least for backward >> compatibility, we should expose that appropriately from the "server" >> side. > > And of course, since we are talking about backward compatibility with > existing qemus here, the capability should be the opposite, ie "honor > iommu", with the assumption that without it, the implementation bypasses > it, which reflects what the current qemu implementation does on any > architecture, whether you configure the bus to have an iommu emulated on > it or not. Can PPC do this using a new devicetree property? --Andy _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
