On Sat, Oct 31, 2015 at 12:16:12AM +0900, Joerg Roedel wrote: > On Thu, Oct 29, 2015 at 11:01:41AM +0200, Michael S. Tsirkin wrote: > > Example: you have a mix of assigned devices and virtio devices. You > > don't trust your assigned device vendor not to corrupt your memory so > > you want to limit the damage your assigned device can do to your guest, > > so you use an IOMMU for that. Thus existing iommu=pt within guest is out. > > > > But you trust your hypervisor (you have no choice anyway), > > and you don't want the overhead of tweaking IOMMU > > on data path for virtio. Thus iommu=on is out too. > > IOMMUs on x86 usually come with an ACPI table that describes which > IOMMUs are in the system and which devices they translate. So you can > easily describe all devices there that are not behind an IOMMU. > > The ACPI table is built by the BIOS, and the platform intialization code > sets the device dma_ops accordingly. If the BIOS provides wrong > information in the ACPI table this is a platform bug.
It doesn't look like I managed to put the point across. My point is that IOMMU is required to do things like userspace drivers, what we need is a way to express "there is an IOMMU but it is part of device itself, use passthrough unless your driver is untrusted". > > I'm not sure what ACPI has to do with it. It's about a way for guest > > users to specify whether they want to bypass an IOMMU for a given > > device. > > We have no way yet to request passthrough-mode per-device from the IOMMU > drivers, but that can easily be added. But as I see it: > > > By the way, a bunch of code is missing on the QEMU side > > to make this useful: > > 1. virtio ignores the iommu > > 2. vhost user ignores the iommu > > 3. dataplane ignores the iommu > > 4. vhost-net ignores the iommu > > 5. VFIO ignores the iommu > > Qemu does not implement IOMMU translation for virtio devices anyway > (which is fine), so it just should tell the guest so in the ACPI table > built to describe the emulated IOMMU. > > > Joerg This is a short term limitation. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
