[ovs-dev] [PATCH 2/2] netdev-dpdk: add support for vhost IOMMU feature

Kavanagh, Mark B mark.b.kavanagh at intel.com
Fri Nov 24 16:45:15 UTC 2017


Sounds good guys - I'll get cracking on this on Monday.

Cheers,
Mark

>-----Original Message-----
>From: Jan Scheurich [mailto:jan.scheurich at ericsson.com]
>Sent: Friday, November 24, 2017 4:21 PM
>To: Kevin Traynor <ktraynor at redhat.com>; Kavanagh, Mark B
><mark.b.kavanagh at intel.com>; dev at openvswitch.org
>Cc: maxime.coquelin at redhat.com; Flavio Leitner <fbl at redhat.com>; Franck Baudin
><fbaudin at redhat.com>; Mooney, Sean K <sean.k.mooney at intel.com>; Ilya Maximets
><i.maximets at samsung.com>; Stokes, Ian <ian.stokes at intel.com>; Loftus, Ciara
><ciara.loftus at intel.com>; Darrell Ball <dball at vmware.com>; Aaron Conole
><aconole at redhat.com>
>Subject: RE: [ovs-dev] [PATCH 2/2] netdev-dpdk: add support for vhost IOMMU
>feature
>
>+1
>Jan
>
>> -----Original Message-----
>> From: Kevin Traynor [mailto:ktraynor at redhat.com]
>> Sent: Friday, 24 November, 2017 17:11
>> To: Mark Kavanagh <mark.b.kavanagh at intel.com>; dev at openvswitch.org
>> Cc: maxime.coquelin at redhat.com; Flavio Leitner <fbl at redhat.com>; Franck
>Baudin <fbaudin at redhat.com>; Mooney, Sean K
>> <sean.k.mooney at intel.com>; Ilya Maximets <i.maximets at samsung.com>; Ian
>Stokes <ian.stokes at intel.com>; Loftus, Ciara
>> <ciara.loftus at intel.com>; Darrell Ball <dball at vmware.com>; Aaron Conole
><aconole at redhat.com>; Jan Scheurich
>> <jan.scheurich at ericsson.com>
>> Subject: Re: [ovs-dev] [PATCH 2/2] netdev-dpdk: add support for vhost IOMMU
>feature
>>
>> On 11/16/2017 11:01 AM, Mark Kavanagh wrote:
>> > DPDK v17.11 introduces support for the vHost IOMMU feature.
>> > This is a security feature, that restricts the vhost memory
>> > that a virtio device may access.
>> >
>> > This feature also enables the vhost REPLY_ACK protocol, the
>> > implementation of which is known to work in newer versions of
>> > QEMU (i.e. v2.10.0), but is buggy in older versions (v2.7.0 -
>> > v2.9.0, inclusive). As such, the feature is disabled by default
>> > in (and should remain so, for the aforementioned older QEMU
>> > verions). Starting with QEMU v2.9.1, vhost-iommu-support can
>> > safely be enabled, even without having an IOMMU device, with
>> > no performance penalty.
>> >
>> > This patch adds a new vhost port option, vhost-iommu-support,
>> > to allow enablement of the vhost IOMMU feature:
>> >
>> >     $ ovs-vsctl add-port br0 vhost-client-1 \
>> >         -- set Interface vhost-client-1 type=dpdkvhostuserclient \
>> >              options:vhost-server-path=$VHOST_USER_SOCKET_PATH   \
>> >              options:vhost-iommu-support=true
>> >
>>
>> Hi Mark, All,
>>
>> I'm thinking about this and whether the current approach provides more
>> than what is actually needed by users at the cost of making the user
>> interface more complex.
>>
>> As an alternative, how about having a global other_config (to be set
>> like vhost-socket-dir can be) for this instead of having to set it for
>> each individual interface. It would mean that it would only have to be
>> set once, instead of having this (ugly?!) option every time a vhost port
>> is added, so it's a less intrusive change and I can't really think that
>> a user would require to do this per vhostclient interface??? It's pain
>> to have to add this at all for a bug in QEMU and I'm sure in 1/2/3 years
>> time someone will say that users could still be using QEMU < 2.9.1 and
>> we can't remove it, so it would be nice to keep it as discreet as
>> possible as we're going to be stuck with it for a while.
>>
>> I assume that a user would only use one version of QEMU at a time and
>> would either want or not want this feature. In the worst case, if that
>> proved completely wrong in the future, then a per interface override
>> could easily be added. Once there's a way to maintain backwards
>> compatibility (which there would be) I'd rather err on the side of
>> introducing just enough enough functionality over increasing complexity
>> for the user.
>>
>> What do you think?
>>
>> thanks,
>> Kevin.


More information about the dev mailing list