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

[Ian Jackson <ian.jackson@xxxxxxxxxx>]

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:
> > Wei Liu writes ("Re: [Xen-devel] reboot driver domain, vifX.Y = 
> > NO-CARRIER?"):
> > > To implement reuse_domid in a sane way, either the toolstack needs to
> > > manage all domids and always sets domid when creating domain or the
> > > hypervisor needs to cooperate -- to have interface to reserve /
> > > pre-allocate domids.
> > 
> > I think this is entirely the wrong approach.
> 
> Whew.  Glad I didn't start hacking yet...

Well, it might be that you end up having to use this fixed-domid thing
as a workaround :-/.

> > I think the right answer is that this is simply a bug in the
> > frontends.  frontends should cope if the backend path pointer in the
> > frontend directory is updated, and should start reading the new
> > backend instead.
> 
> 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.

Ian.

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