[dpdk-dev] vhost-user technical isssues

Xie, Huawei huawei.xie at intel.com
Sat Nov 15 02:42:49 CET 2014



> -----Original Message-----
> From: Tetsuya Mukawa [mailto:mukawa at igel.co.jp]
> Sent: Thursday, November 13, 2014 7:53 PM
> To: Xie, Huawei; dev at dpdk.org
> Cc: Long, Thomas
> Subject: Re: vhost-user technical isssues
> 
> Hi Xie,
> 
> (2014/11/14 9:22), Xie, Huawei wrote:
> >> I think so. I guess we need to consider 2 types of restarting. One is
> >> virtio-net driver restarting, the other is vhost-user backend
> >> restarting. But, so far, it's nice to start to think about virtio-net
> >> driver restarting first. Probably we need to implement a way to let
> >> vhost-user backend know virtio-net driver is restarted. I am not sure
> >> what is good way to let vhost-user backend know it. But how about
> >> followings RFC?
> > I checked your code today, and didn't find the logic to deal with virtio
> reconfiguration.
> Yes.
> I guess the first implementation of librte_vhost may just replace
> vhost-example function.
> Probably vhost-example doesn't think about restarting.
> Because of this, I haven't implemented.
> 
> > My thought without new message support: When vhost-user receives
> > another configuration message since last time it is ready for
> > processing, then we could release it from data core, and process the
> > next reconfiguration message, and then re-add it to data core when it
> > is ready again(check new kick message as before). The candidate
> > message is set_mem_table. It is ok we keep the device on data core
> > until we receive the new reconfiguration message. Just waste vhost
> > some cycles checking the avail idx.
> 
> For example, let's assume DPDK app1 is started on guest with virtio-net
> device port.
> If DPDK app1 on guest is stopped, and other DPDK app2 on guest is
> started without virtio-net device port.
> Hugepages DPDK app1 used will be used by DPDK app2.
> It means the memory accessed by vhost-user backend might be changed by
> DPDK app2.
> And vhost-user backend will be crashed.
> So I guess we need some kinds of reset message.
> 

Virtio DPDK app crashes silently is an issue.
Let us check if there is possibility guest could crash vhost backend.
Even with kernel virtio, I think the basic principle is host shouldn't trust guest totally.
If vhost could be crashed by virtio guest corrupting the ring,  it is the design of our vhost backend. :). Hope I make me clear.
Let us check case by case later. I understand some security check might slow the performance.

I think the real problem is on the contrary, host could crash guest app or even kernel if guest is using the old memory that vhost is also using.

Btw, I checked qemu code, based on current qemu implementation, VHOST_USER_GET_VRING_BASE message is sent and only sent during vring stop. So this message could be used to remove virtio device from data core temporarily. However this sounds not reasonable from the name of this message.
I did an implementation based on this message, virtio PMD could run now. 
Previously we couldn't switch virtio from kernel driver to igb_uio. Now they could switch smoothly between those two.
Check the RFC patch.
Besides, as stated in the patch, I think we should only leave the most common operation in virtio layer, and move the control handling related to cuse/fuse layer. It is difficult to handle all the differences in message flow.

> Thanks,
> Tetsuya



More information about the dev mailing list