On Wed, Sep 3, 2014 at 9:39 AM, Michael S. Tsirkin <mst@xxxxxxxxxx> wrote: > On Wed, Sep 03, 2014 at 08:07:15AM -0700, Andy Lutomirski wrote: >> On Sep 3, 2014 5:11 AM, "Paolo Bonzini" <pbonzini@xxxxxxxxxx> wrote: >> > >> > Il 03/09/2014 10:05, Benjamin Herrenschmidt ha scritto: >> > > On Wed, 2014-09-03 at 09:47 +0200, Paolo Bonzini wrote: >> > >> >> > >> IOMMU support for x86 is going to go in this week. >> > > >> > > But won't that break virtio on x86 ? Or will virtio continue bypassing >> > > it ? IE, the guest side virtio doesn't expect an IOMMU and doesn't call >> > > the dma mappings ops. >> > > >> > >> However, it is and likely will remain niche enough that I don't really >> > >> care about performance loss from IOMMU support. If you enable it, you >> > >> want it. >> > >> >> > >> So from the QEMU point of view we can simply add the direct-ram-access >> > >> property, and have the pseries machine turn it on by default (while >> > >> other machines can leave it off by default---they have no IOMMU and >> > >> thus no performance cost). >> > > >> > > Well, it's only for virtio and should be on by default on x86 as well if >> > > an iommu is installed no ? >> > >> > Yes, only for virtio---but for x86 I think it should be off by default, >> > even if that means virtio+IOMMU requires a new kernel. >> >> Just to clarify: is "it" the direct-ram-access property? If so, I >> think I might agree. >> >> Alternatively, could QEMU easily teach the IOMMU code to generate the >> ACPI tables such that virtio-pci devices aren't advertised as living >> behind the IOMMU? This would work both with and without my patches. > > How exactly does this look in ACPI? I think that all you need is a PCI device or segment that isn't included in the scope of any DRHD. I could be wrong. --Andy _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
