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

Re: [Xen-devel] [PATCH 4/6] domctl: set XEN_DOMCTL_createdomain 'rover' if valid domid is specified



> -----Original Message-----
> From: Ian Jackson <ian.jackson@xxxxxxxxxx>
> Sent: 02 January 2020 17:25
> To: Durrant, Paul <pdurrant@xxxxxxxxxx>
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx; 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>; Wei Liu <wl@xxxxxxx>
> Subject: Re: [PATCH 4/6] domctl: set XEN_DOMCTL_createdomain 'rover' if
> valid domid is specified
> 
> Paul Durrant writes ("[PATCH 4/6] domctl: set XEN_DOMCTL_createdomain
> 'rover' if valid domid is specified"):
> > The value of 'rover' is the value at which Xen will start searching for
> an
> > unused domid if none is specified. Currently it is only updated when a
> > domid is automatically chosen, rather than specified by the caller,
> which
> > makes it very hard to describe Xen's rationale in choosing domids in an
> > environment where some domain creations have specified domids and some
> > don't.
> > This patch always updates 'rover' after a successful creation, even in
> the
> > case that domid is specified by the caller. This ensures that, if Xen
> > automatically chooses a domid for a subsequent domain creation it will
> > always be the next available value after the domid of the most recently
> > created domain.
> 
> I'm not yet convinced this behaviour is better, but I'm open to
> persuasion.
> 
> The existing allocation system falls down in any case if the domid
> gets near to wrapping round.  If it doesn't, then without this patch
> it is possible to have two ranges of domids: automatically allocated
> ones, and statically allocated high ones.
> 
> With this patch, statically allocating a domid resets rover and causes
> the remaining bits of static space to be polluted.
> 
> What am I missing ?  What are the use cases here ?

The problem I was tackling was trying to document how Xen chooses a domid. E.g. 
it is not correct to say that it chooses the lowest numbered available domid. 
The best I could come up with was 'the next available domid after the last one 
it thought of' which is pretty poor... and also becomes harder to explain if 
some domids are not actually chosen by Xen, because the toolstack specified 
them.

The end game which this series is working towards is transparent migration 
which, because of the 'design' of PV protocols and certain hypercalls in the 
guest ABI, requires that the domid is persisted on migration. This patch is 
simply trying to lay groundwork for the co-existence of domains with specified 
domids and those with automatically allocated domids. 

  Paul

> 
> Thanks,
> Ian.

_______________________________________________
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®.