Virtualization - Sep 2014 - [PATCH v5 2/3] virtio_pci: Use the DMA API for virtqueues when possible

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.

Cheers,
Ben.

On Sat, Sep 20, 2014 at 10:05 PM, Benjamin Herrenschmidt
<benh at kernel.crashing.org> 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.
>
I'm all for doing this as some kind of bus property, if needed,
although David Woodhouse may be right that the best solution is to
*always* have the IOMMU there and to just ask it for an identity map
if desired.
> 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.
>
If I'm understanding you correctly, this won't work for Xen on QEMU.
QEMU's virtio-pci device doesn't have a real IOMMU, but it is still
behind Xen's translation layer, and QEMU doesn't even know that Xen is
there.

--Andy
> Cheers,
> Ben.
>
>


-- 
Andy Lutomirski
AMA Capital Management, LLC

On Sat, 2014-09-20 at 22:48 -0700, Andy Lutomirski
wrote:
> 
> I'm all for doing this as some kind of bus property, if needed,
> although David Woodhouse may be right that the best solution is to
> *always* have the IOMMU there and to just ask it for an identity map
> if desired.
That's the right solution for x86, certainly. For POWER it's a little
less clear-cut because I don't think the IOMMU normally supports
identity mapping there. You could still do an identity mapping (hell, we
do at the moment) but it'd be a very special case.

-- 
dwmw2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL:
<http://lists.linuxfoundation.org/pipermail/virtualization/attachments/20140920/0cfa038b/attachment.bin>

On Sat, Sep 20, 2014 at 10:05 PM, Benjamin Herrenschmidt
<benh at kernel.crashing.org> 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

On Wed, 2014-09-24 at 14:41 -0700, Andy Lutomirski
wrote:
> On Sat, Sep 20, 2014 at 10:05 PM, Benjamin Herrenschmidt
> <benh at kernel.crashing.org> 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?
The DT props for PCI devices are created by the FW inside the guest from
standard PCI probing, so it would have to get the info from qemu via
config or register space.

Cheers,
Ben.