[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v3 4/6] libxl: allow creation of domains with a specified or random domid



> -----Original Message-----
> From: Ian Jackson <ian.jackson@xxxxxxxxxx>
> Sent: 17 January 2020 12:36
> To: Durrant, Paul <pdurrant@xxxxxxxxxxxx>
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx; Wei Liu <wl@xxxxxxx>; Anthony Perard
> <anthony.perard@xxxxxxxxxx>; Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>;
> George Dunlap <George.Dunlap@xxxxxxxxxx>; Jan Beulich <jbeulich@xxxxxxxx>;
> Julien Grall <julien@xxxxxxx>; Konrad Rzeszutek Wilk
> <konrad.wilk@xxxxxxxxxx>; Stefano Stabellini <sstabellini@xxxxxxxxxx>;
> jandryuk@xxxxxxxxx
> Subject: RE: [PATCH v3 4/6] libxl: allow creation of domains with a
> specified or random domid
> 
> Durrant, Paul writes ("RE: [PATCH v3 4/6] libxl: allow creation of domains
> with a specified or random domid"):
> > [Ian:]
> > > I think there are only two possible solutions:
> > >
> > >   - Check the domain's entry in the recent list *after* creating
> > >     the domain in Xen.  This involves accepting that we will
> > >     reuse the domid but only for a domain we are in the early
> > >     stages of constructing, so hopefully without bad consequence?
> > >
> > >   - Take the recent domid lock.
> > >
> >
> > Or take a global file lock in libxl around domain creation and
> destruction?
> 
> We want domain construction to be concurrent, when it can be.  So I
> think a lock around just xc_domain_create is OK but a lock around the
> whole operation is not.
> 
> > > Also, it seems to me that we should check the recent domid list if we
> > > let Xen choose the domid.  Maybe that can be in a subsequent patch...
> >
> > Well, we could solve all this, remove the need for a file and all the
> associated complexity by simply keeping history inside the hypervisor. I
> don't know how the Xen maintainers will feel about that though, as Xen
> itself shouldn't have a problem with eager domid re-use.
> 
> I think this doesn't need to be done in the hypervisor so I am
> inclined to say it shouldn't be.  Also, there is a lot of policy here...
> 

Ok, to cover all bases then it seems like checking the domid after creation and 
then destroying if it is too recent is the better option.

  Paul

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.