> -----Original Message-----
> From: Ian Jackson <ian.jack...@citrix.com>
> Sent: 02 January 2020 17:27
> To: Durrant, Paul <pdurr...@amazon.com>
> Cc: xen-devel@lists.xenproject.org; Wei Liu <w...@xen.org>; Anthony Perard
> <anthony.per...@citrix.com>
> Subject: Re: [PATCH 5/6] libxl: allow creation of domains with specified
> or random domid
>
> Paul Durrant writes ("[PATCH 5/6] libxl: allow creation of domains with
> specified or random domid"):
> > This patch modifies do_domain_create() to use the value of domid that is
> > passed in. A new 'special value' - RANDOM_DOMID - is added into the API
> > and this, INVALID_DOMID or any valid domid is passed unmodified to
> > libxl__domain_make(). Any other invalid domid value will cause an error.
> >
> > If RANDOM_DOMID is passed in then libxl__domain_make() will use
> > libxl__random_bytes() to choose a domid. If the chosen value is not a
> > valid domid then this step will be repeated. Once a valid value is
> chosen
> > it will be passed to xc_domain_create() but if this fails with an errno
> > value of EEXIST, a new random value will be chosen and the operation
> will
> > be retried.
>
> What is the use case for this ?
>
The use-case is trying to make sure that, across a pool of hosts, the
likelihood of creating two domains with the same domid is small. Because a
transparent migration requires that domid is persisted, migrations are more
likely to fail (due to a domid already being in use) if a sequential scheme is
used.
> I think using this is hazardous if you ever destroy domains, because
> it will lead to reuse of domids in circumstances[1] where right now
> that can't happen.
>
> [1] Fewer than ~2^16 creations per Xen boot.
Agreed, but is that actually a problem? A domain must be fully destroyed (i.e.
all page refs dropped) before its id will become available for re-use. What are
we actually trying to avoid by not immediately recycling? I'd certainly be open
to adding some sort of retirement list for domids that would prevent re-use
within a specified time, if that would help.
Paul
>
> Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
