Re: [Xen-devel] reboot driver domain, vifX.Y = NO-CARRIER?

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Mon, Apr 30, 2018 at 06:14:15PM +0000, Jason Cooper wrote:
> On Mon, Apr 30, 2018 at 05:26:38PM +0100, Ian Jackson wrote:
> > Jason Cooper writes ("Re: [Xen-devel] reboot driver domain, vifX.Y = 
> > NO-CARRIER?"):
> > > On Mon, Apr 30, 2018 at 04:22:30PM +0100, Ian Jackson wrote:
> ...
> > > Ok, so I'm new to the guts of Xen.  The bug, at a high level, is that
> > > "When a driver domain is rebooted (domid changed), previously connected
> > > client domUs can't gain network connectivity to/through the driver
> > > domain via 'xl network-attach client_domu mac=... bridge=...
> > > backend=drv_dom'"
> > > 
> > > This is due to the fact that the frontend net driver doesn't / can't
> > > follow the backend driver to the new domid in xenstore.
> > 
> > Yes.
> > 
> > > > I'm a bit surprised that this doesn't already work.
> > > 
> > > I'm currently running Xen 4.9.1 as patched in the standard Gentoo
> > > ebuild.  I've been putting off upgrading to 4.9.2, now marked stable in
> > > portage, until I nail this down.  I'm happy to move to 4.10 if needed.
> > > 
> > > Do you think this is something that is definitely fixed in a more recent
> > > version of Xen?  I'm happy to test if so.  Is there a commit id I can
> > > look for?
> > 
> > I think that in my view (which others may disagree with) this is not a
> > bug in Xen but in the Linux kernel frontend.  So changing the Xen
> > version won't help.
> 
> I'm running vanilla v4.16.4 based on allnoconfig in all of these
> mini-domu's.  It doesn't look there's been any pertinent recent changes
> in drivers/net/xen-netfront.c since v4.16.
> 
> Based on an initial scan of the code, it looks like xen-netback watches
> for hotplug events on the frontend (xen-netback/xenbus.c:1041-1046 in
> connect()).  xen-netfront.c:1995-2036, netback_changed(), is the
> registered callback for netfront.
> 
> Is the xenbus netback/netfront state machine documented anywhere?
> include/xen/interface/io/netif.h has a great description of tx/rx queue
> setup and teardown, but doesn't seem to have anything specific to the
> high-level signalling that 'xl network-attach' would cause.
> 

Netback state machine is in
drivers/net/xen-netback/xenbus.c:set_backend_state.

But honestly I don't think that solves the general issue. It is a bit
unfortunately that Xen drivers don't have a unified state machine.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel