All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Jackson <ian.jackson@citrix.com>
To: "Durrant, Paul" <pdurrant@amazon.co.uk>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>, Wei Liu <wl@xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Jason Andryuk <jandryuk@gmail.com>,
	George Dunlap <George.Dunlap@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Anthony Perard <anthony.perard@citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH v5 5/7] libxl: allow creation of domains with a specified or random domid
Date: Tue, 18 Feb 2020 11:17:08 +0000	[thread overview]
Message-ID: <24139.51124.66017.255351@mariner.uk.xensource.com> (raw)
In-Reply-To: <78ccdd687a344eaf92ed8c978dc04f3c@EX13D32EUC003.ant.amazon.com>

Durrant, Paul writes ("RE: [PATCH v5 5/7] libxl: allow creation of domains with a specified or random domid"):
> No, the domain will not be leaked. The existing failure handling in libxl will clean up if *domid != INVALID_DOMID.

Sorry if I was confused; I will read this again.

> > > diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
> > > index d2198dffad..75b1619d0d 100644
> > > --- a/xen/include/public/xen.h
> > > +++ b/xen/include/public/xen.h
> > > @@ -614,6 +614,9 @@ DEFINE_XEN_GUEST_HANDLE(mmuext_op_t);
> > >  /* Idle domain. */
> > >  #define DOMID_IDLE           xen_mk_uint(0x7FFF)
> > >
> > > +/* Mask for valid domain id values */
> > > +#define DOMID_MASK           xen_mk_uint(0x7FFF)
> > 
> > This needs a hypervisor maintainer ack.
> > 
> > Please split it into its own patch, with a rationale, etc.
> 
> Ok, but it has no rationale without the rest of this patch; I can only assert that it 'will be needed by a subsequent patch'.

What do the Xen maintainers, and my tools co-maintainers think ?

I was hoping for a rationale along the lines of:

  This is useful for programs which need to [explanation],
  including for example, libxl, which is going to want to
  randomly generate domids.

Maybe it needs some explanation of why this belongs in the Xen public
headers rather than in some header available to libxc, libxl and other
tools stuff ?

Ian.

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

  reply	other threads:[~2020-02-18 11:17 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-31 15:01 [Xen-devel] [PATCH v5 0/7] xl/libxl: domid allocation/preservation changes Paul Durrant
2020-01-31 15:01 ` [Xen-devel] [PATCH v5 1/7] libxl: add definition of INVALID_DOMID to the API Paul Durrant
2020-01-31 15:01 ` [Xen-devel] [PATCH v5 2/7] libxl_create: make 'soft reset' explicit Paul Durrant
2020-01-31 15:01 ` [Xen-devel] [PATCH v5 3/7] libxl: generalise libxl__domain_userdata_lock() Paul Durrant
2020-01-31 15:01 ` [Xen-devel] [PATCH v5 4/7] libxl: add infrastructure to track and query 'recent' domids Paul Durrant
2020-02-17 17:42   ` Ian Jackson
2020-02-18  9:24     ` Durrant, Paul
2020-02-18 11:38       ` Ian Jackson
2020-01-31 15:01 ` [Xen-devel] [PATCH v5 5/7] libxl: allow creation of domains with a specified or random domid Paul Durrant
2020-01-31 17:22   ` Jason Andryuk
2020-02-03  7:50     ` Durrant, Paul
2020-02-17 17:51   ` Ian Jackson
2020-02-18  9:31     ` Durrant, Paul
2020-02-18 11:17       ` Ian Jackson [this message]
2020-02-18 11:25         ` Durrant, Paul
2020-02-18 11:47           ` Ian Jackson
2020-02-18 11:57             ` Durrant, Paul
2020-01-31 15:01 ` [Xen-devel] [PATCH v5 6/7] xl.conf: introduce 'domid_policy' Paul Durrant
2020-01-31 15:01 ` [Xen-devel] [PATCH v5 7/7] xl: allow domid to be preserved on save/restore or migrate Paul Durrant
2020-02-17 17:55   ` Ian Jackson
2020-02-17 14:21 ` [Xen-devel] [PATCH v5 0/7] xl/libxl: domid allocation/preservation changes Durrant, Paul

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=24139.51124.66017.255351@mariner.uk.xensource.com \
    --to=ian.jackson@citrix.com \
    --cc=Andrew.Cooper3@citrix.com \
    --cc=George.Dunlap@citrix.com \
    --cc=anthony.perard@citrix.com \
    --cc=jandryuk@gmail.com \
    --cc=jbeulich@suse.com \
    --cc=julien@xen.org \
    --cc=konrad.wilk@oracle.com \
    --cc=pdurrant@amazon.co.uk \
    --cc=sstabellini@kernel.org \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.