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

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Fri, Apr 27, 2018 at 05:27:29PM +0000, Jason Cooper wrote:
> Hi Wei Liu,
> 
> On Fri, Apr 27, 2018 at 05:58:17PM +0100, Wei Liu wrote:
> > On Fri, Apr 27, 2018 at 04:14:16PM +0000, Jason Cooper wrote:
> > > On Fri, Apr 27, 2018 at 04:52:57PM +0100, Andrew Cooper wrote:
> ...
> > > > xc_domain_create() takes a domid value by pointer.  Passing a value
> > > > other than zero will cause Xen to use that domid, rather than by
> > > > searching for the next free domid.
> > > > 
> > > > diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> > > > index b5e27a7..7866092 100644
> > > > --- a/tools/libxl/libxl_create.c
> > > > +++ b/tools/libxl/libxl_create.c
> > > > @@ -583,6 +583,7 @@ int libxl__domain_make(libxl__gc *gc,
> > > > libxl_domain_config *d_config,
> > > >              goto out;
> > > >          }
> > > >  
> > > > +        *domid = atoi(getenv("OVERRIDE_DOMID") ?: "0");
> > > >          ret = xc_domain_create(ctx->xch, info->ssidref, handle, flags, 
> > > > domid,
> > > >                                 &xc_config);
> > > >          if (ret < 0) {
> > > > 
> > > > This gross hack may get you somewhere (Entirely untested).
> > > 
> > > Gah!  Yep, that's just what I needed, thanks!  I don't suppose a patch
> > > series adding a 'domid' field to the domain config file would be
> > > rejected outright?  That would allow callers of xl to use key=value for
> > > reboot scripts like mine, and also allow for a static domid setup of the
> > > driver domains if folks want that.
> > 
> > Seems a bit  hacky to me. You also need to reserve a set of domids
> > before hand?
> 
> My thought of creating a domid config file variable was to do just as
> you say, reserve specific domids for specific guests.  I could even
> trigger an error if domid is set when driver_domain isn't.
> 
> Actually, I could slightly overload driver_domain, changing from a bool
> to a 'static domid'.  0 = not a driver domain, >0 is it's static domid
> assignment.
> 
> For backwards compatibility, 1 = next domid available, and >1 would be
> the static domid.  I'm not sure if I like that though.
> 
> The racey part is when a driver domain is shut down, how does a create
> thread know that that domid is reserved?

If a driver domain shuts down and another domain gets allocated that
domain id, your whole system is hosed.

It is even worse if you consider the security implication: some
potentially malicious guest can impersonate driver domain and sees what
other guests' data.

> 
> third option, tri-state:
> 
> driver_domain = 0   # not a driver domain
> driver_domain = 1   # is a driver domain, use next avail domid
> driver_domain = 2   # is a driver domain, re-use domid
> 

Let's shelve this UI discussion for now. I will have a look at the other
subthread.

Wei.

> Honestly, I'm not really liking any of these.  Perhaps 'xl
> network-detach ...' should be doing a better job of cleaning up?  Or,
> 'xl network-attach ...' should do a better job of re-attaching?
> 
> thx,
> 
> Jason.

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