Linux Virtualization - Sep 2014 - [PATCH v4 0/4] virtio: Clean up scatterlists and use the DMA API

On Sep 3, 2014 5:11 AM, "Paolo Bonzini" <pbonzini at redhat.com>
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.
On the other hand, maybe this gets complicated when hotplug is
involved.

--Andy
>
> Paolo

Il 03/09/2014 17:07, Andy Lutomirski ha scritto:
>> > 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.
Yes.
> 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.
> On the other hand, maybe this gets complicated when hotplug is
> involved.
That could be possible.  For hot-plug, you can simply forbid hotplugging
with direct-ram-access=on.  If you want hotplug, then we should add the
direct-ram-access property to PCI bridges too (with the same limitation
on hotplug).  All devices under such a bridge would be outside the
IOMMU, including virtio devices with direct-ram-access=off.

Paolo

On Wed, Sep 03, 2014 at 08:07:15AM -0700, Andy Lutomirski
wrote:
> On Sep 3, 2014 5:11 AM, "Paolo Bonzini" <pbonzini at
redhat.com> 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?
> On the other hand, maybe this gets complicated when hotplug is
> involved.
> 
> --Andy
> 
> >
> > Paolo

On Wed, Sep 3, 2014 at 9:39 AM, Michael S. Tsirkin <mst at redhat.com>
wrote:
> On Wed, Sep 03, 2014 at 08:07:15AM -0700, Andy Lutomirski wrote:
>> On Sep 3, 2014 5:11 AM, "Paolo Bonzini" <pbonzini at
redhat.com> 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