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. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
