All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Wang, Wei W" <wei.w.wang@intel.com>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: "Marc-André Lureau" <marcandre.lureau@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"Yang, Zhiyong" <zhiyong.yang@intel.com>,
	"Maxime Coquelin" <maxime.coquelin@redhat.com>,
	"jasowang@redhat.com" <jasowang@redhat.com>
Subject: Re: [Qemu-devel] [RFC 0/2] virtio-vhost-user: add virtio-vhost-user device
Date: Tue, 6 Feb 2018 12:42:36 +0000	[thread overview]
Message-ID: <286AC319A985734F985F78AFA26841F73942C099@shsmsx102.ccr.corp.intel.com> (raw)
In-Reply-To: <20180206093158.GE4942@stefanha-x1.localdomain>

On Tuesday, February 6, 2018 5:32 PM, Stefan Hajnoczi wrote:
> On Tue, Feb 06, 2018 at 01:28:25AM +0000, Wang, Wei W wrote:
> > On Tuesday, February 6, 2018 12:26 AM, Stefan Hajnoczi wrote:
> > > On Fri, Feb 02, 2018 at 09:08:44PM +0800, Wei Wang wrote:
> > > > On 02/02/2018 01:08 AM, Michael S. Tsirkin wrote:
> > > > > On Tue, Jan 30, 2018 at 08:09:19PM +0800, Wei Wang wrote:
> > > > > > Issues:
> > > > > > Suppose we have both the vhost and virtio-net set up, and 
> > > > > > vhost pmd <-> virtio-net pmd communication works well. Now, 
> > > > > > vhost pmd exits (virtio-net pmd is still there). Some time 
> > > > > > later, we re-run vhost pmd, the vhost pmd doesn't know the 
> > > > > > virtqueue addresses of the virtio-net pmd, unless the 
> > > > > > virtio-net pmd reloads to start the 2nd phase of the 
> > > > > > vhost-user protocol. So the second run of the vhost
> > > pmd won't work.
> > > > > >
> > > > > > Any thoughts?
> > > > > >
> > > > > > Best,
> > > > > > Wei
> > > > > So vhost in qemu must resend all configuration on reconnect.
> > > > > Does this address the issues?
> > > > >
> > > >
> > > > Yes, but the issues are
> > > > 1) there is no reconnecting when a pmd exits (the socket 
> > > > connection seems still on at the device layer);
> > >
> > > This is how real hardware works too.  If the driver suddenly stops 
> > > running then the device remains operational.  When the driver is 
> > > started again it resets the device and initializes it.
> > >
> > > > 2) If we find a way to break the QEMU layer socket connection 
> > > > when pmd exits and get it reconnect, virtio-net device still 
> > > > won't send all the configure when reconnecting, because socket 
> > > > connecting only triggers phase 1 of vhost-user negotiation (i.e.
> > > > vhost_user_init). Phase 2 is triggered after the driver loads 
> > > > (i.e. vhost_net_start). If the virtio-net pmd doesn't reload, 
> > > > there are no phase 2 messages (like virtqueue addresses which 
> > > > are allocated by the pmd). I think we need to think more about 
> > > > this before
> moving forward.
> > >
> > > Marc-André: How does vhost-user reconnect work when the master 
> > > goes away and a new master comes online?  Wei found that the QEMU 
> > > slave implementation only does partial vhost-user initialization 
> > > upon reconnect, so the new master doesn't get the virtqueue 
> > > address and
> related information.
> > > Is this a QEMU bug?
> >
> > Actually we are discussing the slave (vhost is the slave, right?) going away.
> When a slave exits and some moment later a new slave runs, the master
> (virtio-net) won't send the virtqueue addresses to the new vhost slave.
> 
> Yes, apologies for the typo.  s/QEMU slave/QEMU master/
> 
> Yesterday I asked Marc-André for help on IRC and we found the code 
> path where the QEMU master performs phase 2 negotiation upon 
> reconnect.  It's not obvious but the qmp_set_link() calls in net_vhost_user_event() will do it.
> 
> I'm going to try to reproduce the issue you're seeing now.  Will let 
> you know what I find.
> 

OK. Thanks. I observed no messages after re-run virtio-vhost-user pmd, and found there is no re-connection event happening in the device side. 

I also tried to switch the role of client/server - virtio-net to run a server socket, and virtio-vhost-user to run the client, and it seems the current code fails to run that way. The reason is the virtio-net side vhost_user_get_features() doesn't return. On the vhost side, I don't see virtio_vhost_user_deliver_m2s being invoked to deliver the GET_FEATURES message. I'll come back to continue later.

Best,
Wei

  reply	other threads:[~2018-02-06 12:42 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-19 13:06 [Qemu-devel] [RFC 0/2] virtio-vhost-user: add virtio-vhost-user device Stefan Hajnoczi
2018-01-19 13:06 ` [Qemu-devel] [RFC 1/2] vhost-user: share the vhost-user protocol related structures Stefan Hajnoczi
2018-01-19 13:06 ` [Qemu-devel] [RFC 2/2] virtio-vhost-user: add virtio-vhost-user device Stefan Hajnoczi
2018-01-19 13:55 ` [Qemu-devel] [RFC 0/2] " Stefan Hajnoczi
2018-01-22  3:33 ` Jason Wang
2018-01-22 12:17   ` Stefan Hajnoczi
2018-01-22 20:04     ` Michael S. Tsirkin
2018-01-23 10:01       ` Jason Wang
2018-01-23 16:07         ` Michael S. Tsirkin
2018-01-25 14:07           ` Paolo Bonzini
2018-01-25 14:48             ` Michael S. Tsirkin
2018-01-26  3:49               ` Jason Wang
2018-01-23 10:09       ` Stefan Hajnoczi
2018-01-23 10:46     ` Wei Wang
2018-01-22 11:09 ` Wei Wang
2018-01-23 11:12   ` Stefan Hajnoczi
2018-01-23 13:06     ` Wei Wang
2018-01-24 11:40       ` Stefan Hajnoczi
2018-01-25 10:19         ` Wei Wang
2018-01-26 14:44           ` Stefan Hajnoczi
2018-01-30 12:09             ` Wei Wang
2018-02-01 17:08               ` Michael S. Tsirkin
2018-02-02 13:08                 ` Wei Wang
2018-02-05 16:25                   ` Stefan Hajnoczi
2018-02-06  1:28                     ` Wang, Wei W
2018-02-06  9:31                       ` Stefan Hajnoczi
2018-02-06 12:42                         ` Wang, Wei W [this message]
2018-02-06 14:13                           ` Stefan Hajnoczi
2018-02-02 15:25               ` Stefan Hajnoczi
2018-02-05  9:57                 ` Wang, Wei W
2018-02-05 15:57                   ` Stefan Hajnoczi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=286AC319A985734F985F78AFA26841F73942C099@shsmsx102.ccr.corp.intel.com \
    --to=wei.w.wang@intel.com \
    --cc=jasowang@redhat.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=maxime.coquelin@redhat.com \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    --cc=zhiyong.yang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.