* [Xen-devel] [PATCH v4 1/7] libxl: add definition of INVALID_DOMID to the API
2020-01-22 14:44 [Xen-devel] [PATCH v4 0/7] xl/libxl: domid allocation/preservation changes Paul Durrant
@ 2020-01-22 14:44 ` Paul Durrant
2020-01-22 14:52 ` Roger Pau Monné
2020-01-30 17:31 ` Ian Jackson
2020-01-22 14:44 ` [Xen-devel] [PATCH v4 2/7] libxl_create: make 'soft reset' explicit Paul Durrant
` (5 subsequent siblings)
6 siblings, 2 replies; 29+ messages in thread
From: Paul Durrant @ 2020-01-22 14:44 UTC (permalink / raw)
To: xen-devel; +Cc: Anthony PERARD, Paul Durrant, Ian Jackson, Wei Liu
Currently both xl and libxl have internal definitions of INVALID_DOMID
which happen to be identical. However, for the purposes of describing the
behaviour of libxl_domain_create_new/restore() it is useful to have a
specified invalid value for a domain id.
This patch therefore moves the libxl definition from libxl_internal.h to
libxl.h and removes the internal definition from xl_utils.h. The hardcoded
'-1' passed back via domcreate_complete() is then updated to INVALID_DOMID
and comment above libxl_domain_create_new/restore() is accordingly
modified.
Signed-off-by: Paul Durrant <pdurrant@amazon.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
Cc: Wei Liu <wl@xen.org>
Cc: Anthony PERARD <anthony.perard@citrix.com>
---
tools/libxl/libxl.h | 4 +++-
tools/libxl/libxl_create.c | 2 +-
tools/libxl/libxl_internal.h | 1 -
tools/xl/xl_utils.h | 2 --
4 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 54abb9db1f..18c1a2d6bf 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -1527,9 +1527,11 @@ int libxl_ctx_free(libxl_ctx *ctx /* 0 is OK */);
/* domain related functions */
+#define INVALID_DOMID ~0
+
/* If the result is ERROR_ABORTED, the domain may or may not exist
* (in a half-created state). *domid will be valid and will be the
- * domain id, or -1, as appropriate */
+ * domain id, or INVALID_DOMID, as appropriate */
int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
uint32_t *domid,
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 69fceff061..8a1bff6cd3 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -1773,7 +1773,7 @@ static void domcreate_complete(libxl__egc *egc,
libxl__domain_destroy(egc, &dcs->dds);
return;
}
- dcs->guest_domid = -1;
+ dcs->guest_domid = INVALID_DOMID;
}
dcs->callback(egc, dcs, rc, dcs->guest_domid);
}
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index d919f91882..f2f753c72b 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -121,7 +121,6 @@
#define STUBDOM_SPECIAL_CONSOLES 3
#define TAP_DEVICE_SUFFIX "-emu"
#define DOMID_XS_PATH "domid"
-#define INVALID_DOMID ~0
#define PVSHIM_BASENAME "xen-shim"
#define PVSHIM_CMDLINE "pv-shim console=xen,pv"
diff --git a/tools/xl/xl_utils.h b/tools/xl/xl_utils.h
index 7b9ccca30a..d98b419f10 100644
--- a/tools/xl/xl_utils.h
+++ b/tools/xl/xl_utils.h
@@ -52,8 +52,6 @@
#define STR_SKIP_PREFIX( a, b ) \
( STR_HAS_PREFIX(a, b) ? ((a) += strlen(b), 1) : 0 )
-#define INVALID_DOMID ~0
-
#define LOG(_f, _a...) dolog(__FILE__, __LINE__, __func__, _f "\n", ##_a)
/*
--
2.20.1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 29+ messages in thread* Re: [Xen-devel] [PATCH v4 1/7] libxl: add definition of INVALID_DOMID to the API
2020-01-22 14:44 ` [Xen-devel] [PATCH v4 1/7] libxl: add definition of INVALID_DOMID to the API Paul Durrant
@ 2020-01-22 14:52 ` Roger Pau Monné
2020-01-31 10:31 ` Durrant, Paul
2020-01-30 17:31 ` Ian Jackson
1 sibling, 1 reply; 29+ messages in thread
From: Roger Pau Monné @ 2020-01-22 14:52 UTC (permalink / raw)
To: Paul Durrant; +Cc: Anthony PERARD, xen-devel, Ian Jackson, Wei Liu
On Wed, Jan 22, 2020 at 02:44:40PM +0000, Paul Durrant wrote:
> Currently both xl and libxl have internal definitions of INVALID_DOMID
> which happen to be identical. However, for the purposes of describing the
> behaviour of libxl_domain_create_new/restore() it is useful to have a
> specified invalid value for a domain id.
>
> This patch therefore moves the libxl definition from libxl_internal.h to
> libxl.h and removes the internal definition from xl_utils.h. The hardcoded
> '-1' passed back via domcreate_complete() is then updated to INVALID_DOMID
> and comment above libxl_domain_create_new/restore() is accordingly
> modified.
Urg, it's kind of ugly to add another definition of invalid domid when
there's already DOMID_INVALID in the public headers. I guess there's a
reason I'm missing for not using DOMID_INVALID instead of introducing
a new value?
If so could this be mentioned in the commit message?
Thanks, Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Xen-devel] [PATCH v4 1/7] libxl: add definition of INVALID_DOMID to the API
2020-01-22 14:52 ` Roger Pau Monné
@ 2020-01-31 10:31 ` Durrant, Paul
2020-01-31 11:06 ` Roger Pau Monné
0 siblings, 1 reply; 29+ messages in thread
From: Durrant, Paul @ 2020-01-31 10:31 UTC (permalink / raw)
To: Roger Pau Monné; +Cc: Anthony PERARD, xen-devel, Ian Jackson, Wei Liu
> -----Original Message-----
> From: Xen-devel <xen-devel-bounces@lists.xenproject.org> On Behalf Of
> Roger Pau Monné
> Sent: 22 January 2020 14:53
> To: Durrant, Paul <pdurrant@amazon.co.uk>
> Cc: Anthony PERARD <anthony.perard@citrix.com>; xen-
> devel@lists.xenproject.org; Ian Jackson <ian.jackson@eu.citrix.com>; Wei
> Liu <wl@xen.org>
> Subject: Re: [Xen-devel] [PATCH v4 1/7] libxl: add definition of
> INVALID_DOMID to the API
>
> On Wed, Jan 22, 2020 at 02:44:40PM +0000, Paul Durrant wrote:
> > Currently both xl and libxl have internal definitions of INVALID_DOMID
> > which happen to be identical. However, for the purposes of describing
> the
> > behaviour of libxl_domain_create_new/restore() it is useful to have a
> > specified invalid value for a domain id.
> >
> > This patch therefore moves the libxl definition from libxl_internal.h to
> > libxl.h and removes the internal definition from xl_utils.h. The
> hardcoded
> > '-1' passed back via domcreate_complete() is then updated to
> INVALID_DOMID
> > and comment above libxl_domain_create_new/restore() is accordingly
> > modified.
>
> Urg, it's kind of ugly to add another definition of invalid domid when
> there's already DOMID_INVALID in the public headers. I guess there's a
> reason I'm missing for not using DOMID_INVALID instead of introducing
> a new value?
>
TBH I don't know. As far as xl/libxl goes, domids are uint32_ts so maybe DOMID_INVALID was for some reason not considered appropriate? Bear in mind, this patch is not truly introducing a new value; it's just making something that was internal but identical in both xl and libxl part of the interface.
> If so could this be mentioned in the commit message?
>
I'll add a note to the commit comment to point out that this is not changing any value used by the toolstack.
Paul
> Thanks, Roger.
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Xen-devel] [PATCH v4 1/7] libxl: add definition of INVALID_DOMID to the API
2020-01-31 10:31 ` Durrant, Paul
@ 2020-01-31 11:06 ` Roger Pau Monné
2020-01-31 11:10 ` Durrant, Paul
0 siblings, 1 reply; 29+ messages in thread
From: Roger Pau Monné @ 2020-01-31 11:06 UTC (permalink / raw)
To: Durrant, Paul; +Cc: Anthony PERARD, xen-devel, Ian Jackson, Wei Liu
On Fri, Jan 31, 2020 at 10:31:49AM +0000, Durrant, Paul wrote:
> > -----Original Message-----
> > From: Xen-devel <xen-devel-bounces@lists.xenproject.org> On Behalf Of
> > Roger Pau Monné
> > Sent: 22 January 2020 14:53
> > To: Durrant, Paul <pdurrant@amazon.co.uk>
> > Cc: Anthony PERARD <anthony.perard@citrix.com>; xen-
> > devel@lists.xenproject.org; Ian Jackson <ian.jackson@eu.citrix.com>; Wei
> > Liu <wl@xen.org>
> > Subject: Re: [Xen-devel] [PATCH v4 1/7] libxl: add definition of
> > INVALID_DOMID to the API
> >
> > On Wed, Jan 22, 2020 at 02:44:40PM +0000, Paul Durrant wrote:
> > > Currently both xl and libxl have internal definitions of INVALID_DOMID
> > > which happen to be identical. However, for the purposes of describing
> > the
> > > behaviour of libxl_domain_create_new/restore() it is useful to have a
> > > specified invalid value for a domain id.
> > >
> > > This patch therefore moves the libxl definition from libxl_internal.h to
> > > libxl.h and removes the internal definition from xl_utils.h. The
> > hardcoded
> > > '-1' passed back via domcreate_complete() is then updated to
> > INVALID_DOMID
> > > and comment above libxl_domain_create_new/restore() is accordingly
> > > modified.
> >
> > Urg, it's kind of ugly to add another definition of invalid domid when
> > there's already DOMID_INVALID in the public headers. I guess there's a
> > reason I'm missing for not using DOMID_INVALID instead of introducing
> > a new value?
> >
>
> TBH I don't know. As far as xl/libxl goes, domids are uint32_ts so maybe DOMID_INVALID was for some reason not considered appropriate? Bear in mind, this patch is not truly introducing a new value; it's just making something that was internal but identical in both xl and libxl part of the interface.
Hm, OK. It seems quite a mess that libxl uses a 32bit value when the
hypervisor is using a 16bit field, but I guess there's nothing that
can be done at this point to fix this.
Since this will be part of the public interface now, it might make
sense to define it to the same value as DOMID_INVALID (0x7FF4). And
make sure domid values passed to libxl are truncated to 16bits.
Maybe it's not that relevant, but domids passed to libxl would need to
be sanitized in order to make sure Xen's DOMID_INVALID is not treated
as a valid domid value from libxl's PoV. There are also other special
domids that need to be filtered.
> > If so could this be mentioned in the commit message?
> >
>
> I'll add a note to the commit comment to point out that this is not changing any value used by the toolstack.
Thanks!
Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Xen-devel] [PATCH v4 1/7] libxl: add definition of INVALID_DOMID to the API
2020-01-31 11:06 ` Roger Pau Monné
@ 2020-01-31 11:10 ` Durrant, Paul
2020-01-31 12:07 ` Andrew Cooper
0 siblings, 1 reply; 29+ messages in thread
From: Durrant, Paul @ 2020-01-31 11:10 UTC (permalink / raw)
To: Roger Pau Monné; +Cc: Anthony PERARD, xen-devel, Ian Jackson, Wei Liu
> -----Original Message-----
> From: Roger Pau Monné <roger.pau@citrix.com>
> Sent: 31 January 2020 11:06
> To: Durrant, Paul <pdurrant@amazon.co.uk>
> Cc: Anthony PERARD <anthony.perard@citrix.com>; xen-
> devel@lists.xenproject.org; Ian Jackson <ian.jackson@eu.citrix.com>; Wei
> Liu <wl@xen.org>
> Subject: Re: [Xen-devel] [PATCH v4 1/7] libxl: add definition of
> INVALID_DOMID to the API
>
> On Fri, Jan 31, 2020 at 10:31:49AM +0000, Durrant, Paul wrote:
> > > -----Original Message-----
> > > From: Xen-devel <xen-devel-bounces@lists.xenproject.org> On Behalf Of
> > > Roger Pau Monné
> > > Sent: 22 January 2020 14:53
> > > To: Durrant, Paul <pdurrant@amazon.co.uk>
> > > Cc: Anthony PERARD <anthony.perard@citrix.com>; xen-
> > > devel@lists.xenproject.org; Ian Jackson <ian.jackson@eu.citrix.com>;
> Wei
> > > Liu <wl@xen.org>
> > > Subject: Re: [Xen-devel] [PATCH v4 1/7] libxl: add definition of
> > > INVALID_DOMID to the API
> > >
> > > On Wed, Jan 22, 2020 at 02:44:40PM +0000, Paul Durrant wrote:
> > > > Currently both xl and libxl have internal definitions of
> INVALID_DOMID
> > > > which happen to be identical. However, for the purposes of
> describing
> > > the
> > > > behaviour of libxl_domain_create_new/restore() it is useful to have
> a
> > > > specified invalid value for a domain id.
> > > >
> > > > This patch therefore moves the libxl definition from
> libxl_internal.h to
> > > > libxl.h and removes the internal definition from xl_utils.h. The
> > > hardcoded
> > > > '-1' passed back via domcreate_complete() is then updated to
> > > INVALID_DOMID
> > > > and comment above libxl_domain_create_new/restore() is accordingly
> > > > modified.
> > >
> > > Urg, it's kind of ugly to add another definition of invalid domid when
> > > there's already DOMID_INVALID in the public headers. I guess there's a
> > > reason I'm missing for not using DOMID_INVALID instead of introducing
> > > a new value?
> > >
> >
> > TBH I don't know. As far as xl/libxl goes, domids are uint32_ts so maybe
> DOMID_INVALID was for some reason not considered appropriate? Bear in
> mind, this patch is not truly introducing a new value; it's just making
> something that was internal but identical in both xl and libxl part of the
> interface.
>
> Hm, OK. It seems quite a mess that libxl uses a 32bit value when the
> hypervisor is using a 16bit field, but I guess there's nothing that
> can be done at this point to fix this.
>
> Since this will be part of the public interface now, it might make
> sense to define it to the same value as DOMID_INVALID (0x7FF4). And
> make sure domid values passed to libxl are truncated to 16bits.
That sounds like feature creep that I'd rather not go near in this patch. I suspect a can of worms awaits.
>
> Maybe it's not that relevant, but domids passed to libxl would need to
> be sanitized in order to make sure Xen's DOMID_INVALID is not treated
> as a valid domid value from libxl's PoV. There are also other special
> domids that need to be filtered.
There is already a validity check: libxl_domid_valid_guest().
Paul
>
> > > If so could this be mentioned in the commit message?
> > >
> >
> > I'll add a note to the commit comment to point out that this is not
> changing any value used by the toolstack.
>
> Thanks!
>
> Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Xen-devel] [PATCH v4 1/7] libxl: add definition of INVALID_DOMID to the API
2020-01-31 11:10 ` Durrant, Paul
@ 2020-01-31 12:07 ` Andrew Cooper
2020-01-31 12:11 ` Durrant, Paul
0 siblings, 1 reply; 29+ messages in thread
From: Andrew Cooper @ 2020-01-31 12:07 UTC (permalink / raw)
To: Durrant, Paul, Roger Pau Monné
Cc: Anthony PERARD, xen-devel, Ian Jackson, Wei Liu
On 31/01/2020 11:10, Durrant, Paul wrote:
>> -----Original Message-----
>> From: Roger Pau Monné <roger.pau@citrix.com>
>> Sent: 31 January 2020 11:06
>> To: Durrant, Paul <pdurrant@amazon.co.uk>
>> Cc: Anthony PERARD <anthony.perard@citrix.com>; xen-
>> devel@lists.xenproject.org; Ian Jackson <ian.jackson@eu.citrix.com>; Wei
>> Liu <wl@xen.org>
>> Subject: Re: [Xen-devel] [PATCH v4 1/7] libxl: add definition of
>> INVALID_DOMID to the API
>>
>> On Fri, Jan 31, 2020 at 10:31:49AM +0000, Durrant, Paul wrote:
>>>> -----Original Message-----
>>>> From: Xen-devel <xen-devel-bounces@lists.xenproject.org> On Behalf Of
>>>> Roger Pau Monné
>>>> Sent: 22 January 2020 14:53
>>>> To: Durrant, Paul <pdurrant@amazon.co.uk>
>>>> Cc: Anthony PERARD <anthony.perard@citrix.com>; xen-
>>>> devel@lists.xenproject.org; Ian Jackson <ian.jackson@eu.citrix.com>;
>> Wei
>>>> Liu <wl@xen.org>
>>>> Subject: Re: [Xen-devel] [PATCH v4 1/7] libxl: add definition of
>>>> INVALID_DOMID to the API
>>>>
>>>> On Wed, Jan 22, 2020 at 02:44:40PM +0000, Paul Durrant wrote:
>>>>> Currently both xl and libxl have internal definitions of
>> INVALID_DOMID
>>>>> which happen to be identical. However, for the purposes of
>> describing
>>>> the
>>>>> behaviour of libxl_domain_create_new/restore() it is useful to have
>> a
>>>>> specified invalid value for a domain id.
>>>>>
>>>>> This patch therefore moves the libxl definition from
>> libxl_internal.h to
>>>>> libxl.h and removes the internal definition from xl_utils.h. The
>>>> hardcoded
>>>>> '-1' passed back via domcreate_complete() is then updated to
>>>> INVALID_DOMID
>>>>> and comment above libxl_domain_create_new/restore() is accordingly
>>>>> modified.
>>>> Urg, it's kind of ugly to add another definition of invalid domid when
>>>> there's already DOMID_INVALID in the public headers. I guess there's a
>>>> reason I'm missing for not using DOMID_INVALID instead of introducing
>>>> a new value?
>>>>
>>> TBH I don't know. As far as xl/libxl goes, domids are uint32_ts so maybe
>> DOMID_INVALID was for some reason not considered appropriate?
Read the commit message where I did the blanket change to use uint32_t.
c/s 5b42c82f55
Does this really need to enter the API?
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Xen-devel] [PATCH v4 1/7] libxl: add definition of INVALID_DOMID to the API
2020-01-31 12:07 ` Andrew Cooper
@ 2020-01-31 12:11 ` Durrant, Paul
0 siblings, 0 replies; 29+ messages in thread
From: Durrant, Paul @ 2020-01-31 12:11 UTC (permalink / raw)
To: Andrew Cooper, Roger Pau Monné
Cc: Anthony PERARD, xen-devel, Ian Jackson, Wei Liu
> -----Original Message-----
> From: Andrew Cooper <andrew.cooper3@citrix.com>
> Sent: 31 January 2020 12:08
> To: Durrant, Paul <pdurrant@amazon.co.uk>; Roger Pau Monné
> <roger.pau@citrix.com>
> Cc: Anthony PERARD <anthony.perard@citrix.com>; xen-
> devel@lists.xenproject.org; Ian Jackson <ian.jackson@eu.citrix.com>; Wei
> Liu <wl@xen.org>
> Subject: Re: [Xen-devel] [PATCH v4 1/7] libxl: add definition of
> INVALID_DOMID to the API
>
> On 31/01/2020 11:10, Durrant, Paul wrote:
> >> -----Original Message-----
> >> From: Roger Pau Monné <roger.pau@citrix.com>
> >> Sent: 31 January 2020 11:06
> >> To: Durrant, Paul <pdurrant@amazon.co.uk>
> >> Cc: Anthony PERARD <anthony.perard@citrix.com>; xen-
> >> devel@lists.xenproject.org; Ian Jackson <ian.jackson@eu.citrix.com>;
> Wei
> >> Liu <wl@xen.org>
> >> Subject: Re: [Xen-devel] [PATCH v4 1/7] libxl: add definition of
> >> INVALID_DOMID to the API
> >>
> >> On Fri, Jan 31, 2020 at 10:31:49AM +0000, Durrant, Paul wrote:
> >>>> -----Original Message-----
> >>>> From: Xen-devel <xen-devel-bounces@lists.xenproject.org> On Behalf Of
> >>>> Roger Pau Monné
> >>>> Sent: 22 January 2020 14:53
> >>>> To: Durrant, Paul <pdurrant@amazon.co.uk>
> >>>> Cc: Anthony PERARD <anthony.perard@citrix.com>; xen-
> >>>> devel@lists.xenproject.org; Ian Jackson <ian.jackson@eu.citrix.com>;
> >> Wei
> >>>> Liu <wl@xen.org>
> >>>> Subject: Re: [Xen-devel] [PATCH v4 1/7] libxl: add definition of
> >>>> INVALID_DOMID to the API
> >>>>
> >>>> On Wed, Jan 22, 2020 at 02:44:40PM +0000, Paul Durrant wrote:
> >>>>> Currently both xl and libxl have internal definitions of
> >> INVALID_DOMID
> >>>>> which happen to be identical. However, for the purposes of
> >> describing
> >>>> the
> >>>>> behaviour of libxl_domain_create_new/restore() it is useful to have
> >> a
> >>>>> specified invalid value for a domain id.
> >>>>>
> >>>>> This patch therefore moves the libxl definition from
> >> libxl_internal.h to
> >>>>> libxl.h and removes the internal definition from xl_utils.h. The
> >>>> hardcoded
> >>>>> '-1' passed back via domcreate_complete() is then updated to
> >>>> INVALID_DOMID
> >>>>> and comment above libxl_domain_create_new/restore() is accordingly
> >>>>> modified.
> >>>> Urg, it's kind of ugly to add another definition of invalid domid
> when
> >>>> there's already DOMID_INVALID in the public headers. I guess there's
> a
> >>>> reason I'm missing for not using DOMID_INVALID instead of introducing
> >>>> a new value?
> >>>>
> >>> TBH I don't know. As far as xl/libxl goes, domids are uint32_ts so
> maybe
> >> DOMID_INVALID was for some reason not considered appropriate?
>
> Read the commit message where I did the blanket change to use uint32_t.
>
> c/s 5b42c82f55
>
> Does this really need to enter the API?
>
I need a 'magic' value for RANDOM_DOMID so it seemed reasonable to make this part of the xl/libxl API too. I don't think libxc is in scope here.
Paul
> ~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Xen-devel] [PATCH v4 1/7] libxl: add definition of INVALID_DOMID to the API
2020-01-22 14:44 ` [Xen-devel] [PATCH v4 1/7] libxl: add definition of INVALID_DOMID to the API Paul Durrant
2020-01-22 14:52 ` Roger Pau Monné
@ 2020-01-30 17:31 ` Ian Jackson
2020-01-30 17:35 ` Durrant, Paul
1 sibling, 1 reply; 29+ messages in thread
From: Ian Jackson @ 2020-01-30 17:31 UTC (permalink / raw)
To: Paul Durrant; +Cc: Anthony Perard, xen-devel, Wei Liu
Paul Durrant writes ("[PATCH v4 1/7] libxl: add definition of INVALID_DOMID to the API"):
> Currently both xl and libxl have internal definitions of INVALID_DOMID
> which happen to be identical. However, for the purposes of describing the
> behaviour of libxl_domain_create_new/restore() it is useful to have a
> specified invalid value for a domain id.
Hi. (I'm replying to the 1/ here because I don't seem to have any 0/
in my inbox...)
Thanks for all this. As well as your use case, which is in itself
valuable, I think this change is important for other reasons.
So I want to see it go in.
You'll see I have replied with some comments about the implementation.
I hope you won't be discouraged. If you feel I am asking for too much
work I might be inclined to pick up some of this myself; if so, please
let me know. I definitely don't want this to be dropped.
Thanks.
Regards,
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [Xen-devel] [PATCH v4 1/7] libxl: add definition of INVALID_DOMID to the API
2020-01-30 17:31 ` Ian Jackson
@ 2020-01-30 17:35 ` Durrant, Paul
2020-01-30 17:51 ` Ian Jackson
0 siblings, 1 reply; 29+ messages in thread
From: Durrant, Paul @ 2020-01-30 17:35 UTC (permalink / raw)
To: Ian Jackson; +Cc: Anthony Perard, xen-devel, Wei Liu
> -----Original Message-----
> From: Xen-devel <xen-devel-bounces@lists.xenproject.org> On Behalf Of Ian
> Jackson
> Sent: 30 January 2020 17:32
> To: Durrant, Paul <pdurrant@amazon.co.uk>
> Cc: Anthony Perard <anthony.perard@citrix.com>; xen-
> devel@lists.xenproject.org; Wei Liu <wl@xen.org>
> Subject: Re: [Xen-devel] [PATCH v4 1/7] libxl: add definition of
> INVALID_DOMID to the API
>
> Paul Durrant writes ("[PATCH v4 1/7] libxl: add definition of
> INVALID_DOMID to the API"):
> > Currently both xl and libxl have internal definitions of INVALID_DOMID
> > which happen to be identical. However, for the purposes of describing
> the
> > behaviour of libxl_domain_create_new/restore() it is useful to have a
> > specified invalid value for a domain id.
>
> Hi. (I'm replying to the 1/ here because I don't seem to have any 0/
> in my inbox...)
>
Oh, I must have forgot to copy the combined cc list onto the cover letter. Sorry about that.
> Thanks for all this. As well as your use case, which is in itself
> valuable, I think this change is important for other reasons.
> So I want to see it go in.
>
> You'll see I have replied with some comments about the implementation.
> I hope you won't be discouraged. If you feel I am asking for too much
> work I might be inclined to pick up some of this myself; if so, please
> let me know. I definitely don't want this to be dropped.
Don't worry, your feedback is fine... certainly not asking too much.
Cheers,
Paul
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Xen-devel] [PATCH v4 2/7] libxl_create: make 'soft reset' explicit
2020-01-22 14:44 [Xen-devel] [PATCH v4 0/7] xl/libxl: domid allocation/preservation changes Paul Durrant
2020-01-22 14:44 ` [Xen-devel] [PATCH v4 1/7] libxl: add definition of INVALID_DOMID to the API Paul Durrant
@ 2020-01-22 14:44 ` Paul Durrant
2020-01-22 14:44 ` [Xen-devel] [PATCH v4 3/7] libxl: generalise libxl__domain_userdata_lock() Paul Durrant
` (4 subsequent siblings)
6 siblings, 0 replies; 29+ messages in thread
From: Paul Durrant @ 2020-01-22 14:44 UTC (permalink / raw)
To: xen-devel; +Cc: Anthony PERARD, Paul Durrant, Ian Jackson, Wei Liu
The 'soft reset' code path in libxl__domain_make() is currently taken if a
valid domid is passed into the function. A subsequent patch will enable
higher levels of the toolstack to determine the domid of newly created or
restored domains and therefore this criteria for choosing 'soft reset'
will no longer be usable.
This patch adds an extra boolean option to libxl__domain_make() to specify
whether it is being invoked in soft reset context and appropriately
modifies callers to choose the right value. To facilitate this, a new
'soft_reset' boolean field is added to struct libxl__domain_create_state
and the 'domid_soft_reset' field is renamed to 'domid' in anticipation of
its wider remit. For the moment do_domain_create() will always set
domid to INVALID_DOMID and hence we can add an assertion into
libxl__domain_create() that, if it is not called in soft reset context,
the passed in domid is exactly that value.
Whilst in the neighbourhood, some checks of 'restore_fd > -1' have been
replaced by 'restore_fd >= 0' to be more conventional and consistent with
checks of 'restore_fd < 0'.
Signed-off-by: Paul Durrant <pdurrant@amazon.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
Cc: Wei Liu <wl@xen.org>
Cc: Anthony PERARD <anthony.perard@citrix.com>
---
tools/libxl/libxl_create.c | 56 ++++++++++++++++++++++--------------
tools/libxl/libxl_dm.c | 2 +-
tools/libxl/libxl_internal.h | 5 ++--
3 files changed, 38 insertions(+), 25 deletions(-)
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 8a1bff6cd3..73a2883357 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -538,7 +538,7 @@ out:
int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config,
libxl__domain_build_state *state,
- uint32_t *domid)
+ uint32_t *domid, bool soft_reset)
{
libxl_ctx *ctx = libxl__gc_owner(gc);
int ret, rc, nb_vm;
@@ -555,14 +555,15 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config,
libxl_domain_create_info *info = &d_config->c_info;
libxl_domain_build_info *b_info = &d_config->b_info;
+ assert(soft_reset || *domid == INVALID_DOMID);
+
uuid_string = libxl__uuid2string(gc, info->uuid);
if (!uuid_string) {
rc = ERROR_NOMEM;
goto out;
}
- /* Valid domid here means we're soft resetting. */
- if (!libxl_domid_valid_guest(*domid)) {
+ if (!soft_reset) {
struct xen_domctl_createdomain create = {
.ssidref = info->ssidref,
.max_vcpus = b_info->max_vcpus,
@@ -611,6 +612,14 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config,
goto out;
}
+ /*
+ * If soft_reset is set the the domid will have been valid on entry.
+ * If it was not set then xc_domain_create() should have assigned a
+ * valid value. Either way, if we reach this point, domid should be
+ * valid.
+ */
+ assert(libxl_domid_valid_guest(*domid));
+
ret = xc_cpupool_movedomain(ctx->xch, info->poolid, *domid);
if (ret < 0) {
LOGED(ERROR, *domid, "domain move fail");
@@ -1091,13 +1100,14 @@ static void initiate_domain_create(libxl__egc *egc,
libxl_domain_config *const d_config = dcs->guest_config;
const int restore_fd = dcs->restore_fd;
- domid = dcs->domid_soft_reset;
+ domid = dcs->domid;
libxl__domain_build_state_init(&dcs->build_state);
ret = libxl__domain_config_setdefault(gc,d_config,domid);
if (ret) goto error_out;
- ret = libxl__domain_make(gc, d_config, &dcs->build_state, &domid);
+ ret = libxl__domain_make(gc, d_config, &dcs->build_state, &domid,
+ dcs->soft_reset);
if (ret) {
LOGD(ERROR, domid, "cannot make domain: %d", ret);
dcs->guest_domid = domid;
@@ -1141,7 +1151,7 @@ static void initiate_domain_create(libxl__egc *egc,
if (ret)
goto error_out;
- if (restore_fd >= 0 || dcs->domid_soft_reset != INVALID_DOMID) {
+ if (restore_fd >= 0 || dcs->soft_reset) {
LOGD(DEBUG, domid, "restoring, not running bootloader");
domcreate_bootloader_done(egc, &dcs->bl, 0);
} else {
@@ -1217,7 +1227,7 @@ static void domcreate_bootloader_done(libxl__egc *egc,
dcs->sdss.dm.callback = domcreate_devmodel_started;
dcs->sdss.callback = domcreate_devmodel_started;
- if (restore_fd < 0 && dcs->domid_soft_reset == INVALID_DOMID) {
+ if (restore_fd < 0 && !dcs->soft_reset) {
rc = libxl__domain_build(gc, domid, dcs);
domcreate_rebuild_done(egc, dcs, rc);
return;
@@ -1827,7 +1837,7 @@ static int do_domain_create(libxl_ctx *ctx, libxl_domain_config *d_config,
libxl_domain_config_copy(ctx, &cdcs->dcs.guest_config_saved, d_config);
cdcs->dcs.restore_fd = cdcs->dcs.libxc_fd = restore_fd;
cdcs->dcs.send_back_fd = send_back_fd;
- if (restore_fd > -1) {
+ if (restore_fd >= 0) {
cdcs->dcs.restore_params = *params;
rc = libxl__fd_flags_modify_save(gc, cdcs->dcs.restore_fd,
~(O_NONBLOCK|O_NDELAY), 0,
@@ -1835,7 +1845,8 @@ static int do_domain_create(libxl_ctx *ctx, libxl_domain_config *d_config,
if (rc < 0) goto out_err;
}
cdcs->dcs.callback = domain_create_cb;
- cdcs->dcs.domid_soft_reset = INVALID_DOMID;
+ cdcs->dcs.domid = INVALID_DOMID;
+ cdcs->dcs.soft_reset = false;
if (cdcs->dcs.restore_params.checkpointed_stream ==
LIBXL_CHECKPOINTED_STREAM_COLO) {
@@ -1905,7 +1916,7 @@ static void soft_reset_dm_suspended(libxl__egc *egc,
int rc);
static int do_domain_soft_reset(libxl_ctx *ctx,
libxl_domain_config *d_config,
- uint32_t domid_soft_reset,
+ uint32_t domid,
const libxl_asyncop_how *ao_how,
const libxl_asyncprogress_how
*aop_console_how)
@@ -1933,15 +1944,16 @@ static int do_domain_soft_reset(libxl_ctx *ctx,
libxl_domain_config_copy(ctx, &srs->cdcs.dcs.guest_config_saved,
d_config);
cdcs->dcs.restore_fd = -1;
- cdcs->dcs.domid_soft_reset = domid_soft_reset;
+ cdcs->dcs.domid = domid;
+ cdcs->dcs.soft_reset = true;
cdcs->dcs.callback = domain_create_cb;
libxl__ao_progress_gethow(&srs->cdcs.dcs.aop_console_how,
aop_console_how);
cdcs->domid_out = &domid_out;
- dom_path = libxl__xs_get_dompath(gc, domid_soft_reset);
+ dom_path = libxl__xs_get_dompath(gc, domid);
if (!dom_path) {
- LOGD(ERROR, domid_soft_reset, "failed to read domain path");
+ LOGD(ERROR, domid, "failed to read domain path");
rc = ERROR_FAIL;
goto out;
}
@@ -1950,7 +1962,7 @@ static int do_domain_soft_reset(libxl_ctx *ctx,
GCSPRINTF("%s/store/ring-ref", dom_path),
&xs_store_mfn);
if (rc) {
- LOGD(ERROR, domid_soft_reset, "failed to read store/ring-ref.");
+ LOGD(ERROR, domid, "failed to read store/ring-ref.");
goto out;
}
state->store_mfn = xs_store_mfn ? atol(xs_store_mfn): 0;
@@ -1959,7 +1971,7 @@ static int do_domain_soft_reset(libxl_ctx *ctx,
GCSPRINTF("%s/console/ring-ref", dom_path),
&xs_console_mfn);
if (rc) {
- LOGD(ERROR, domid_soft_reset, "failed to read console/ring-ref.");
+ LOGD(ERROR, domid, "failed to read console/ring-ref.");
goto out;
}
state->console_mfn = xs_console_mfn ? atol(xs_console_mfn): 0;
@@ -1968,20 +1980,20 @@ static int do_domain_soft_reset(libxl_ctx *ctx,
GCSPRINTF("%s/console/tty", dom_path),
&console_tty);
if (rc) {
- LOGD(ERROR, domid_soft_reset, "failed to read console/tty.");
+ LOGD(ERROR, domid, "failed to read console/tty.");
goto out;
}
state->console_tty = libxl__strdup(gc, console_tty);
dss->ao = ao;
- dss->domid = dss->dsps.domid = domid_soft_reset;
+ dss->domid = dss->dsps.domid = domid;
dss->dsps.dm_savefile = GCSPRINTF(LIBXL_DEVICE_MODEL_SAVE_FILE".%d",
- domid_soft_reset);
+ domid);
rc = libxl__save_emulator_xenstore_data(dss, &srs->toolstack_buf,
&srs->toolstack_len);
if (rc) {
- LOGD(ERROR, domid_soft_reset, "failed to save toolstack record.");
+ LOGD(ERROR, domid, "failed to save toolstack record.");
goto out;
}
@@ -2010,10 +2022,10 @@ static void soft_reset_dm_suspended(libxl__egc *egc,
* xenstore again with probably different store/console/...
* channels.
*/
- xs_release_domain(CTX->xsh, cdcs->dcs.domid_soft_reset);
+ xs_release_domain(CTX->xsh, cdcs->dcs.domid);
srs->dds.ao = ao;
- srs->dds.domid = cdcs->dcs.domid_soft_reset;
+ srs->dds.domid = cdcs->dcs.domid;
srs->dds.callback = domain_soft_reset_cb;
srs->dds.soft_reset = true;
libxl__domain_destroy(egc, &srs->dds);
@@ -2029,7 +2041,7 @@ static void domain_create_cb(libxl__egc *egc,
*cdcs->domid_out = domid;
- if (dcs->restore_fd > -1) {
+ if (dcs->restore_fd >= 0) {
flrc = libxl__fd_flags_restore(gc,
dcs->restore_fd, dcs->restore_fdfl);
/*
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 3f08ccad1b..2bd92fb1df 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -2194,7 +2194,7 @@ void libxl__spawn_stub_dm(libxl__egc *egc, libxl__domain_create_state *dcs)
/* fixme: this function can leak the stubdom if it fails */
ret = libxl__domain_make(gc, dm_config, stubdom_state,
- &sdss->pvqemu.guest_domid);
+ &sdss->pvqemu.guest_domid, false);
if (ret)
goto out;
uint32_t dm_domid = sdss->pvqemu.guest_domid;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index f2f753c72b..3a00bdb8b4 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1956,7 +1956,7 @@ _hidden void libxl__exec(libxl__gc *gc, int stdinfd, int stdoutfd,
_hidden int libxl__domain_make(libxl__gc *gc,
libxl_domain_config *d_config,
libxl__domain_build_state *state,
- uint32_t *domid);
+ uint32_t *domid, bool soft_reset);
_hidden int libxl__domain_build(libxl__gc *gc, uint32_t domid,
libxl__domain_create_state *dcs);
@@ -4131,7 +4131,8 @@ struct libxl__domain_create_state {
int restore_fdfl; /* original flags of restore_fd */
int send_back_fd;
libxl_domain_restore_params restore_params;
- uint32_t domid_soft_reset;
+ uint32_t domid;
+ bool soft_reset;
libxl__domain_create_cb *callback;
libxl_asyncprogress_how aop_console_how;
/* private to domain_create */
--
2.20.1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 29+ messages in thread* [Xen-devel] [PATCH v4 3/7] libxl: generalise libxl__domain_userdata_lock()
2020-01-22 14:44 [Xen-devel] [PATCH v4 0/7] xl/libxl: domid allocation/preservation changes Paul Durrant
2020-01-22 14:44 ` [Xen-devel] [PATCH v4 1/7] libxl: add definition of INVALID_DOMID to the API Paul Durrant
2020-01-22 14:44 ` [Xen-devel] [PATCH v4 2/7] libxl_create: make 'soft reset' explicit Paul Durrant
@ 2020-01-22 14:44 ` Paul Durrant
2020-01-30 17:04 ` Ian Jackson
2020-01-22 14:44 ` [Xen-devel] [PATCH v4 4/7] libxl: add infrastructure to track and query 'recent' domids Paul Durrant
` (3 subsequent siblings)
6 siblings, 1 reply; 29+ messages in thread
From: Paul Durrant @ 2020-01-22 14:44 UTC (permalink / raw)
To: xen-devel; +Cc: Anthony PERARD, Paul Durrant, Ian Jackson, Wei Liu
This function implements a file-based lock with a file name generated
from a domid.
This patch splits it into two, generalising the core of the locking code
into a new libxl__lock_file() function which operates on a specified file,
leaving just the file name generation in libxl__domain_userdata_lock().
This patch also generalises libxl__unlock_domain_userdata() to
libxl__unlock_file() and modifies all call-sites.
Suggested-by: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Paul Durrant <pdurrant@amazon.com>
---
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Wei Liu <wl@xen.org>
Cc: Anthony PERARD <anthony.perard@citrix.com>
v4:
- New in v4.
---
tools/libxl/libxl_create.c | 4 +--
tools/libxl/libxl_device.c | 4 +--
tools/libxl/libxl_disk.c | 12 ++++----
tools/libxl/libxl_dom.c | 12 ++++----
tools/libxl/libxl_domain.c | 14 ++++-----
tools/libxl/libxl_internal.c | 55 +++++++++++++++++++++---------------
tools/libxl/libxl_internal.h | 10 ++++---
tools/libxl/libxl_mem.c | 8 +++---
tools/libxl/libxl_pci.c | 4 +--
tools/libxl/libxl_usb.c | 8 +++---
10 files changed, 72 insertions(+), 59 deletions(-)
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 73a2883357..e4aab4fd1c 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -1755,7 +1755,7 @@ static void domcreate_complete(libxl__egc *egc,
bool retain_domain = !rc || rc == ERROR_ABORTED;
if (retain_domain) {
- libxl__domain_userdata_lock *lock;
+ libxl__flock *lock;
/* Note that we hold CTX lock at this point so only need to
* take data store lock
@@ -1769,7 +1769,7 @@ static void domcreate_complete(libxl__egc *egc,
(gc, dcs->guest_domid, d_config_saved);
if (!rc)
rc = cfg_rc;
- libxl__unlock_domain_userdata(lock);
+ libxl__unlock_file(lock);
}
}
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index 9d05d2fd13..0381c5d509 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -1850,7 +1850,7 @@ void libxl__device_add_async(libxl__egc *egc, uint32_t domid,
xs_transaction_t t = XBT_NULL;
libxl_domain_config d_config;
void *type_saved;
- libxl__domain_userdata_lock *lock = NULL;
+ libxl__flock *lock = NULL;
int rc;
libxl_domain_config_init(&d_config);
@@ -1946,7 +1946,7 @@ void libxl__device_add_async(libxl__egc *egc, uint32_t domid,
out:
libxl__xs_transaction_abort(gc, &t);
- if (lock) libxl__unlock_domain_userdata(lock);
+ if (lock) libxl__unlock_file(lock);
dt->dispose(type_saved);
libxl_domain_config_dispose(&d_config);
aodev->rc = rc;
diff --git a/tools/libxl/libxl_disk.c b/tools/libxl/libxl_disk.c
index 64a6691424..e0de1c5781 100644
--- a/tools/libxl/libxl_disk.c
+++ b/tools/libxl/libxl_disk.c
@@ -245,7 +245,7 @@ static void device_disk_add(libxl__egc *egc, uint32_t domid,
xs_transaction_t t = XBT_NULL;
libxl_domain_config d_config;
libxl_device_disk disk_saved;
- libxl__domain_userdata_lock *lock = NULL;
+ libxl__flock *lock = NULL;
libxl_domain_config_init(&d_config);
libxl_device_disk_init(&disk_saved);
@@ -436,7 +436,7 @@ static void device_disk_add(libxl__egc *egc, uint32_t domid,
out:
libxl__xs_transaction_abort(gc, &t);
- if (lock) libxl__unlock_domain_userdata(lock);
+ if (lock) libxl__unlock_file(lock);
libxl_device_disk_dispose(&disk_saved);
libxl_domain_config_dispose(&d_config);
aodev->rc = rc;
@@ -794,7 +794,7 @@ static void cdrom_insert_ejected(libxl__egc *egc,
{
EGC_GC;
libxl__cdrom_insert_state *cis = CONTAINER_OF(qmp, *cis, qmp);
- libxl__domain_userdata_lock *data_lock = NULL;
+ libxl__flock *data_lock = NULL;
libxl__device device;
const char *be_path, *libxl_path;
flexarray_t *empty = NULL;
@@ -896,7 +896,7 @@ static void cdrom_insert_ejected(libxl__egc *egc,
out:
libxl__xs_transaction_abort(gc, &t);
libxl_domain_config_dispose(&d_config);
- if (data_lock) libxl__unlock_domain_userdata(data_lock);
+ if (data_lock) libxl__unlock_file(data_lock);
if (rc) {
cdrom_insert_done(egc, cis, rc); /* must be last */
} else if (!has_callback) {
@@ -951,7 +951,7 @@ static void cdrom_insert_inserted(libxl__egc *egc,
{
EGC_GC;
libxl__cdrom_insert_state *cis = CONTAINER_OF(qmp, *cis, qmp);
- libxl__domain_userdata_lock *data_lock = NULL;
+ libxl__flock *data_lock = NULL;
libxl_domain_config d_config;
flexarray_t *insert = NULL;
xs_transaction_t t = XBT_NULL;
@@ -1029,7 +1029,7 @@ static void cdrom_insert_inserted(libxl__egc *egc,
out:
libxl__xs_transaction_abort(gc, &t);
libxl_domain_config_dispose(&d_config);
- if (data_lock) libxl__unlock_domain_userdata(data_lock);
+ if (data_lock) libxl__unlock_file(data_lock);
cdrom_insert_done(egc, cis, rc); /* must be last */
}
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index e0b6d4a8d3..021cbb4e1c 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -1520,7 +1520,7 @@ int libxl_userdata_store(libxl_ctx *ctx, uint32_t domid,
{
GC_INIT(ctx);
int rc;
- libxl__domain_userdata_lock *lock;
+ libxl__flock *lock;
CTX_LOCK;
lock = libxl__lock_domain_userdata(gc, domid);
@@ -1532,7 +1532,7 @@ int libxl_userdata_store(libxl_ctx *ctx, uint32_t domid,
rc = libxl__userdata_store(gc, domid, userdata_userid,
data, datalen);
- libxl__unlock_domain_userdata(lock);
+ libxl__unlock_file(lock);
out:
CTX_UNLOCK;
@@ -1581,7 +1581,7 @@ int libxl_userdata_retrieve(libxl_ctx *ctx, uint32_t domid,
{
GC_INIT(ctx);
int rc;
- libxl__domain_userdata_lock *lock;
+ libxl__flock *lock;
CTX_LOCK;
lock = libxl__lock_domain_userdata(gc, domid);
@@ -1594,7 +1594,7 @@ int libxl_userdata_retrieve(libxl_ctx *ctx, uint32_t domid,
data_r, datalen_r);
- libxl__unlock_domain_userdata(lock);
+ libxl__unlock_file(lock);
out:
CTX_UNLOCK;
GC_FREE;
@@ -1608,7 +1608,7 @@ int libxl_userdata_unlink(libxl_ctx *ctx, uint32_t domid,
CTX_LOCK;
int rc;
- libxl__domain_userdata_lock *lock = NULL;
+ libxl__flock *lock = NULL;
const char *filename;
lock = libxl__lock_domain_userdata(gc, domid);
@@ -1631,7 +1631,7 @@ int libxl_userdata_unlink(libxl_ctx *ctx, uint32_t domid,
rc = 0;
out:
if (lock)
- libxl__unlock_domain_userdata(lock);
+ libxl__unlock_file(lock);
CTX_UNLOCK;
GC_FREE;
return rc;
diff --git a/tools/libxl/libxl_domain.c b/tools/libxl/libxl_domain.c
index 5714501778..1bdb1615d8 100644
--- a/tools/libxl/libxl_domain.c
+++ b/tools/libxl/libxl_domain.c
@@ -1278,7 +1278,7 @@ static void devices_destroy_cb(libxl__egc *egc,
uint32_t domid = dis->domid;
char *dom_path;
char *vm_path;
- libxl__domain_userdata_lock *lock;
+ libxl__flock *lock;
dom_path = libxl__xs_get_dompath(gc, domid);
if (!dom_path) {
@@ -1308,7 +1308,7 @@ static void devices_destroy_cb(libxl__egc *egc,
}
libxl__userdata_destroyall(gc, domid);
- libxl__unlock_domain_userdata(lock);
+ libxl__unlock_file(lock);
/* Clean up qemu-save and qemu-resume files. They are
* intermediate files created by libxc. Unfortunately they
@@ -1917,7 +1917,7 @@ static void retrieve_domain_configuration_lock_acquired(
retrieve_domain_configuration_state *rdcs =
CONTAINER_OF(devlock, *rdcs, devlock);
STATE_AO_GC(rdcs->qmp.ao);
- libxl__domain_userdata_lock *lock = NULL;
+ libxl__flock *lock = NULL;
bool has_callback = false;
/* Convenience aliases */
@@ -1939,7 +1939,7 @@ static void retrieve_domain_configuration_lock_acquired(
goto out;
}
- libxl__unlock_domain_userdata(lock);
+ libxl__unlock_file(lock);
lock = NULL;
/* We start by querying QEMU, if it is running, for its cpumap as this
@@ -1964,7 +1964,7 @@ static void retrieve_domain_configuration_lock_acquired(
}
out:
- if (lock) libxl__unlock_domain_userdata(lock);
+ if (lock) libxl__unlock_file(lock);
if (!has_callback)
retrieve_domain_configuration_end(egc, rdcs, rc);
}
@@ -1998,7 +1998,7 @@ static void retrieve_domain_configuration_end(libxl__egc *egc,
retrieve_domain_configuration_state *rdcs, int rc)
{
STATE_AO_GC(rdcs->qmp.ao);
- libxl__domain_userdata_lock *lock = NULL;
+ libxl__flock *lock = NULL;
/* Convenience aliases */
libxl_domain_config *const d_config = rdcs->d_config;
@@ -2205,7 +2205,7 @@ static void retrieve_domain_configuration_end(libxl__egc *egc,
out:
libxl__ev_slowlock_unlock(gc, &rdcs->devlock);
- if (lock) libxl__unlock_domain_userdata(lock);
+ if (lock) libxl__unlock_file(lock);
libxl_bitmap_dispose(&rdcs->qemuu_cpus);
libxl__ev_qmp_dispose(gc, &rdcs->qmp);
libxl__ev_time_deregister(gc, &rdcs->timeout);
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index ba5637358e..211236dc99 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -400,26 +400,22 @@ int libxl__device_model_version_running(libxl__gc *gc, uint32_t domid)
/* Portability note: this lock utilises flock(2) so a proper implementation of
* flock(2) is required.
*/
-libxl__domain_userdata_lock *libxl__lock_domain_userdata(libxl__gc *gc,
- uint32_t domid)
+libxl__flock *libxl__lock_file(libxl__gc *gc, const char *lockfile)
{
- libxl__domain_userdata_lock *lock = NULL;
- const char *lockfile;
+ libxl__flock *lock;
int fd;
struct stat stab, fstab;
- lockfile = libxl__userdata_path(gc, domid, "domain-userdata-lock", "l");
- if (!lockfile) goto out;
-
- lock = libxl__zalloc(NOGC, sizeof(libxl__domain_userdata_lock));
+ lock = libxl__zalloc(NOGC, sizeof(libxl__flock));
lock->path = libxl__strdup(NOGC, lockfile);
while (true) {
libxl__carefd_begin();
fd = open(lockfile, O_RDWR|O_CREAT, 0666);
if (fd < 0)
- LOGED(ERROR, domid,
- "cannot open lockfile %s, errno=%d", lockfile, errno);
+ LOGE(ERROR,
+ "cannot open lockfile %s, errno=%d",
+ lockfile, errno);
lock->carefd = libxl__carefd_opened(CTX, fd);
if (fd < 0) goto out;
@@ -433,21 +429,21 @@ libxl__domain_userdata_lock *libxl__lock_domain_userdata(libxl__gc *gc,
continue;
default:
/* All other errno: EBADF, EINVAL, ENOLCK, EWOULDBLOCK */
- LOGED(ERROR, domid,
- "unexpected error while trying to lock %s, fd=%d, errno=%d",
+ LOGE(ERROR,
+ "unexpected error while trying to lock %s, fd=%d, errno=%d",
lockfile, fd, errno);
goto out;
}
}
if (fstat(fd, &fstab)) {
- LOGED(ERROR, domid, "cannot fstat %s, fd=%d, errno=%d",
+ LOGE(ERROR, "cannot fstat %s, fd=%d, errno=%d",
lockfile, fd, errno);
goto out;
}
if (stat(lockfile, &stab)) {
if (errno != ENOENT) {
- LOGED(ERROR, domid, "cannot stat %s, errno=%d", lockfile, errno);
+ LOGE(ERROR, "cannot stat %s, errno=%d", lockfile, errno);
goto out;
}
} else {
@@ -458,20 +454,14 @@ libxl__domain_userdata_lock *libxl__lock_domain_userdata(libxl__gc *gc,
libxl__carefd_close(lock->carefd);
}
- /* Check the domain is still there, if not we should release the
- * lock and clean up.
- */
- if (libxl_domain_info(CTX, NULL, domid))
- goto out;
-
return lock;
out:
- if (lock) libxl__unlock_domain_userdata(lock);
+ if (lock) libxl__unlock_file(lock);
return NULL;
}
-void libxl__unlock_domain_userdata(libxl__domain_userdata_lock *lock)
+void libxl__unlock_file(libxl__flock *lock)
{
/* It's important to unlink the file before closing fd to avoid
* the following race (if close before unlink):
@@ -493,6 +483,27 @@ void libxl__unlock_domain_userdata(libxl__domain_userdata_lock *lock)
free(lock);
}
+libxl__flock *libxl__lock_domain_userdata(libxl__gc *gc, uint32_t domid)
+{
+ const char *lockfile;
+ libxl__flock *lock;
+
+ lockfile = libxl__userdata_path(gc, domid, "domain-userdata-lock", "l");
+ if (!lockfile) return NULL;
+
+ lock = libxl__lock_file(gc, lockfile);
+
+ /* Check the domain is still there, if not we should release the
+ * lock and clean up.
+ */
+ if (libxl_domain_info(CTX, NULL, domid)) {
+ libxl__unlock_file(lock);
+ return NULL;
+ }
+
+ return lock;
+}
+
int libxl__get_domain_configuration(libxl__gc *gc, uint32_t domid,
libxl_domain_config *d_config)
{
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 3a00bdb8b4..3fb38220e5 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -4624,11 +4624,13 @@ int libxl__cpuid_policy_is_empty(libxl_cpuid_policy_list *pl);
typedef struct {
libxl__carefd *carefd;
char *path; /* path of the lock file itself */
-} libxl__domain_userdata_lock;
+} libxl__flock;
/* The CTX_LOCK must be held around uses of this lock */
-libxl__domain_userdata_lock *libxl__lock_domain_userdata(libxl__gc *gc,
- uint32_t domid);
-void libxl__unlock_domain_userdata(libxl__domain_userdata_lock *lock);
+
+libxl__flock *libxl__lock_file(libxl__gc *gc, const char *filename);
+void libxl__unlock_file(libxl__flock *lock);
+
+libxl__flock *libxl__lock_domain_userdata(libxl__gc *gc, uint32_t domid);
/*
* Retrieve / store domain configuration from / to libxl private
diff --git a/tools/libxl/libxl_mem.c b/tools/libxl/libxl_mem.c
index 7c01fac7e5..bc7b95aa74 100644
--- a/tools/libxl/libxl_mem.c
+++ b/tools/libxl/libxl_mem.c
@@ -30,7 +30,7 @@ int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint64_t max_memkb)
uint64_t memorykb, size;
char *dompath = libxl__xs_get_dompath(gc, domid);
int rc = 1;
- libxl__domain_userdata_lock *lock = NULL;
+ libxl__flock *lock = NULL;
libxl_domain_config d_config;
libxl_domain_config_init(&d_config);
@@ -85,7 +85,7 @@ int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint64_t max_memkb)
rc = 0;
out:
libxl_domain_config_dispose(&d_config);
- if (lock) libxl__unlock_domain_userdata(lock);
+ if (lock) libxl__unlock_file(lock);
CTX_UNLOCK;
GC_FREE;
return rc;
@@ -184,7 +184,7 @@ int libxl_set_memory_target(libxl_ctx *ctx, uint32_t domid,
libxl_dominfo ptr;
char *uuid;
xs_transaction_t t;
- libxl__domain_userdata_lock *lock;
+ libxl__flock *lock;
libxl_domain_config d_config;
libxl_domain_config_init(&d_config);
@@ -338,7 +338,7 @@ out:
out_no_transaction:
libxl_domain_config_dispose(&d_config);
- if (lock) libxl__unlock_domain_userdata(lock);
+ if (lock) libxl__unlock_file(lock);
CTX_UNLOCK;
GC_FREE;
return rc;
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 664d74c478..f91bce07ec 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -125,7 +125,7 @@ static int libxl__device_pci_add_xenstore(libxl__gc *gc,
xs_transaction_t t = XBT_NULL;
int rc;
libxl_domain_config d_config;
- libxl__domain_userdata_lock *lock = NULL;
+ libxl__flock *lock = NULL;
bool is_stubdomain = libxl_is_stubdom(CTX, domid, NULL);
/* Stubdomain doesn't have own config. */
@@ -195,7 +195,7 @@ static int libxl__device_pci_add_xenstore(libxl__gc *gc,
out:
libxl__xs_transaction_abort(gc, &t);
- if (lock) libxl__unlock_domain_userdata(lock);
+ if (lock) libxl__unlock_file(lock);
if (!is_stubdomain)
libxl_domain_config_dispose(&d_config);
return rc;
diff --git a/tools/libxl/libxl_usb.c b/tools/libxl/libxl_usb.c
index da5e3708e6..171bb04439 100644
--- a/tools/libxl/libxl_usb.c
+++ b/tools/libxl/libxl_usb.c
@@ -202,7 +202,7 @@ static int libxl__device_usbctrl_add_xenstore(libxl__gc *gc, uint32_t domid,
int i, rc;
libxl_domain_config d_config;
libxl_device_usbctrl usbctrl_saved;
- libxl__domain_userdata_lock *lock = NULL;
+ libxl__flock *lock = NULL;
libxl_domain_config_init(&d_config);
libxl_device_usbctrl_init(&usbctrl_saved);
@@ -291,7 +291,7 @@ static int libxl__device_usbctrl_add_xenstore(libxl__gc *gc, uint32_t domid,
out:
libxl__xs_transaction_abort(gc, &t);
- if (lock) libxl__unlock_domain_userdata(lock);
+ if (lock) libxl__unlock_file(lock);
libxl_device_usbctrl_dispose(&usbctrl_saved);
libxl_domain_config_dispose(&d_config);
return rc;
@@ -1266,7 +1266,7 @@ static int libxl__device_usbdev_add_xenstore(libxl__gc *gc, uint32_t domid,
xs_transaction_t t = XBT_NULL;
libxl_domain_config d_config;
libxl_device_usbdev usbdev_saved;
- libxl__domain_userdata_lock *lock = NULL;
+ libxl__flock *lock = NULL;
libxl_domain_config_init(&d_config);
libxl_device_usbdev_init(&usbdev_saved);
@@ -1323,7 +1323,7 @@ static int libxl__device_usbdev_add_xenstore(libxl__gc *gc, uint32_t domid,
rc = 0;
out:
- if (lock) libxl__unlock_domain_userdata(lock);
+ if (lock) libxl__unlock_file(lock);
libxl_device_usbdev_dispose(&usbdev_saved);
libxl_domain_config_dispose(&d_config);
return rc;
--
2.20.1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 29+ messages in thread* Re: [Xen-devel] [PATCH v4 3/7] libxl: generalise libxl__domain_userdata_lock()
2020-01-22 14:44 ` [Xen-devel] [PATCH v4 3/7] libxl: generalise libxl__domain_userdata_lock() Paul Durrant
@ 2020-01-30 17:04 ` Ian Jackson
0 siblings, 0 replies; 29+ messages in thread
From: Ian Jackson @ 2020-01-30 17:04 UTC (permalink / raw)
To: Paul Durrant; +Cc: Anthony Perard, xen-devel, Wei Liu
Paul Durrant writes ("[PATCH v4 3/7] libxl: generalise libxl__domain_userdata_lock()"):
> This function implements a file-based lock with a file name generated
> from a domid.
>
> This patch splits it into two, generalising the core of the locking code
> into a new libxl__lock_file() function which operates on a specified file,
> leaving just the file name generation in libxl__domain_userdata_lock().
>
> This patch also generalises libxl__unlock_domain_userdata() to
> libxl__unlock_file() and modifies all call-sites.
>
> Suggested-by: Ian Jackson <ian.jackson@eu.citrix.com>
> Signed-off-by: Paul Durrant <pdurrant@amazon.com>
Thanks :-).
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Xen-devel] [PATCH v4 4/7] libxl: add infrastructure to track and query 'recent' domids
2020-01-22 14:44 [Xen-devel] [PATCH v4 0/7] xl/libxl: domid allocation/preservation changes Paul Durrant
` (2 preceding siblings ...)
2020-01-22 14:44 ` [Xen-devel] [PATCH v4 3/7] libxl: generalise libxl__domain_userdata_lock() Paul Durrant
@ 2020-01-22 14:44 ` Paul Durrant
2020-01-30 17:23 ` Ian Jackson
2020-01-31 10:55 ` Anthony PERARD
2020-01-22 14:44 ` [Xen-devel] [PATCH v4 5/7] libxl: allow creation of domains with a specified or random domid Paul Durrant
` (2 subsequent siblings)
6 siblings, 2 replies; 29+ messages in thread
From: Paul Durrant @ 2020-01-22 14:44 UTC (permalink / raw)
To: xen-devel; +Cc: Anthony PERARD, Paul Durrant, Ian Jackson, Wei Liu
A domid is considered recent if the domain it represents was destroyed
less than a specified number of seconds ago. The number can be set using
the environment variable LIBXL_DOMID_REUSE_TIMEOUT. If the variable does
not exist then a default value of 60s is used.
Whenever a domain is destroyed, a time-stamped record will be written into
a history file (/var/run/xen/domid-history). To avoid the history file
growing too large, any records with time-stamps that indicate that the
age of a domid has exceeded the re-use timeout will also be purged.
A new utility function, libxl__is_recent_domid(), has been added. This
function reads the same history file checking whether a specified domid
has a record that does not exceed the re-use timeout. Since this utility
function does not write to the file, no records are actually purged by it.
NOTE: The history file is purged on boot to it is safe to use
CLOCK_MONOTONIC as a time source.
Signed-off-by: Paul Durrant <pdurrant@amazon.com>
---
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Wei Liu <wl@xen.org>
Cc: Anthony PERARD <anthony.perard@citrix.com>
v4:
- Use new generalised libxl__flock
- Don't read and write the same file
- Use 'recent' rather than 'retired'
- Add code into xen-init-dom0 to delete an old history file at boot
v2:
- New in v2
---
tools/helpers/xen-init-dom0.c | 30 ++++++++
tools/libxl/libxl.h | 2 +
tools/libxl/libxl_domain.c | 135 ++++++++++++++++++++++++++++++++++
tools/libxl/libxl_internal.c | 10 +++
tools/libxl/libxl_internal.h | 14 ++++
5 files changed, 191 insertions(+)
diff --git a/tools/helpers/xen-init-dom0.c b/tools/helpers/xen-init-dom0.c
index a1e5729458..56f69ab66f 100644
--- a/tools/helpers/xen-init-dom0.c
+++ b/tools/helpers/xen-init-dom0.c
@@ -12,6 +12,32 @@
#define DOMNAME_PATH "/local/domain/0/name"
#define DOMID_PATH "/local/domain/0/domid"
+int clear_domid_history(void)
+{
+ int rc = 1;
+ xentoollog_logger_stdiostream *logger;
+ libxl_ctx *ctx;
+
+ logger = xtl_createlogger_stdiostream(stderr, XTL_ERROR, 0);
+ if (!logger)
+ return 1;
+
+ if (libxl_ctx_alloc(&ctx, LIBXL_VERSION, 0,
+ (xentoollog_logger *)logger)) {
+ fprintf(stderr, "cannot init libxl context\n");
+ goto outlog;
+ }
+
+ if (!libxl_clear_domid_history(ctx))
+ rc = 0;
+
+ libxl_ctx_free(ctx);
+
+outlog:
+ xtl_logger_destroy((xentoollog_logger *)logger);
+ return rc;
+}
+
int main(int argc, char **argv)
{
int rc;
@@ -70,6 +96,10 @@ int main(int argc, char **argv)
if (rc)
goto out;
+ rc = clear_domid_history();
+ if (rc)
+ goto out;
+
/* Write xenstore entries. */
if (!xs_write(xsh, XBT_NULL, DOMID_PATH, "0", strlen("0"))) {
fprintf(stderr, "cannot set domid for Dom0\n");
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 18c1a2d6bf..1d235ecb1c 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -2657,6 +2657,8 @@ static inline int libxl_qemu_monitor_command_0x041200(libxl_ctx *ctx,
#include <libxl_event.h>
+int libxl_clear_domid_history(libxl_ctx *ctx);
+
#endif /* LIBXL_H */
/*
diff --git a/tools/libxl/libxl_domain.c b/tools/libxl/libxl_domain.c
index 1bdb1615d8..d424a8542f 100644
--- a/tools/libxl/libxl_domain.c
+++ b/tools/libxl/libxl_domain.c
@@ -1268,6 +1268,140 @@ static void dm_destroy_cb(libxl__egc *egc,
libxl__devices_destroy(egc, &dis->drs);
}
+static unsigned int libxl__get_domid_reuse_timeout(void)
+{
+ const char *env_timeout = getenv("LIBXL_DOMID_REUSE_TIMEOUT");
+
+ return env_timeout ? strtol(env_timeout, NULL, 0) :
+ LIBXL_DOMID_REUSE_TIMEOUT;
+}
+
+char *libxl__domid_history_path(libxl__gc *gc, const char *suffix)
+{
+ return GCSPRINTF("%s/domid-history%s", libxl__run_dir_path(),
+ suffix ?: "");
+}
+
+int libxl_clear_domid_history(libxl_ctx *ctx)
+{
+ GC_INIT(ctx);
+ char *path;
+ int rc = ERROR_FAIL;
+
+ path = libxl__domid_history_path(gc, NULL);
+ if (!path)
+ goto out;
+
+ if (unlink(path) < 0 && errno != ENOENT) {
+ LOGE(ERROR, "failed to remove '%s'\n", path);
+ goto out;
+ }
+
+ rc = 0;
+
+out:
+ GC_FREE;
+ return rc;
+}
+
+static void libxl__mark_domid_recent(libxl__gc *gc, uint32_t domid)
+{
+ long timeout = libxl__get_domid_reuse_timeout();
+ libxl__flock *lock;
+ char *old, *new;
+ FILE *of = NULL, *nf = NULL;
+ struct timespec ts;
+ char line[64];
+
+ lock = libxl__lock_domid_history(gc);
+ if (!lock) {
+ LOGED(ERROR, domid, "failed to acquire lock");
+ goto out;
+ }
+
+ old = libxl__domid_history_path(gc, NULL);
+ of = fopen(old, "r");
+ if (!of && errno != ENOENT)
+ LOGED(WARN, domid, "failed to open '%s'", old);
+
+ new = libxl__domid_history_path(gc, ".new");
+ nf = fopen(new, "a");
+ if (!nf) {
+ LOGED(ERROR, domid, "failed to open '%s'", new);
+ goto out;
+ }
+
+ clock_gettime(CLOCK_MONOTONIC, &ts);
+
+ while (of && fgets(line, sizeof(line), of)) {
+ unsigned long sec;
+ unsigned int ignored;
+
+ if (sscanf(line, "%lu %u", &sec, &ignored) != 2) {
+ LOGED(ERROR, domid, "ignoring malformed line: %s", line);
+ continue;
+ }
+
+ if (ts.tv_sec - sec > timeout)
+ continue; /* Ignore expired entries */
+
+ if (fputs(line, nf) == EOF) {
+ LOGED(ERROR, domid, "failed to write");
+ goto out;
+ }
+ }
+
+ if (fprintf(nf, "%lu %u\n", ts.tv_sec, domid) < 0) {
+ LOGED(ERROR, domid, "failed to write");
+ goto out;
+ }
+
+ fflush(nf);
+
+ if (rename(new, old) < 0)
+ LOGED(ERROR, domid, "failed to rename '%s' -> '%s'", old, new);
+
+out:
+ if (nf) fclose(nf);
+ if (of) fclose(of);
+ if (lock) libxl__unlock_file(lock);
+}
+
+bool libxl__is_domid_recent(libxl__gc *gc, uint32_t domid)
+{
+ long timeout = libxl__get_domid_reuse_timeout();
+ bool recent = false;
+ const char *name;
+ FILE *f;
+ struct timespec ts;
+
+ name = GCSPRINTF("%s/domid-history", libxl__run_dir_path());
+ f = fopen(name, "r");
+ if (!f) {
+ if (errno != ENOENT) LOGED(WARN, domid, "failed to open %s", name);
+ return false;
+ }
+
+ clock_gettime(CLOCK_MONOTONIC, &ts);
+
+ while (!feof(f)) {
+ unsigned long sec;
+ unsigned int check;
+
+ if (fscanf(f, "%lu %u", &sec, &check) != 2)
+ continue;
+
+ if (check == domid && ts.tv_sec - sec <= timeout) {
+ recent = true;
+ break;
+ }
+ }
+
+ fclose(f);
+
+ return recent;
+}
+
static void devices_destroy_cb(libxl__egc *egc,
libxl__devices_remove_state *drs,
int rc)
@@ -1331,6 +1465,7 @@ static void devices_destroy_cb(libxl__egc *egc,
if (!ctx->xch) goto badchild;
if (!dis->soft_reset) {
+ libxl__mark_domid_recent(gc, domid);
rc = xc_domain_destroy(ctx->xch, domid);
} else {
rc = xc_domain_pause(ctx->xch, domid);
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 211236dc99..bbd4c6cba9 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -504,6 +504,16 @@ libxl__flock *libxl__lock_domain_userdata(libxl__gc *gc, uint32_t domid)
return lock;
}
+libxl__flock *libxl__lock_domid_history(libxl__gc *gc)
+{
+ const char *lockfile;
+
+ lockfile = libxl__domid_history_path(gc, ".lock");
+ if (!lockfile) return NULL;
+
+ return libxl__lock_file(gc, lockfile);
+}
+
int libxl__get_domain_configuration(libxl__gc *gc, uint32_t domid,
libxl_domain_config *d_config)
{
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 3fb38220e5..a50d5a2939 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -4233,6 +4233,8 @@ _hidden void libxl__remus_teardown(libxl__egc *egc,
_hidden void libxl__remus_restore_setup(libxl__egc *egc,
libxl__domain_create_state *dcs);
+_hidden char *libxl__domid_history_path(libxl__gc *gc,
+ const char *suffix);
/*
* Convenience macros.
@@ -4631,6 +4633,7 @@ libxl__flock *libxl__lock_file(libxl__gc *gc, const char *filename);
void libxl__unlock_file(libxl__flock *lock);
libxl__flock *libxl__lock_domain_userdata(libxl__gc *gc, uint32_t domid);
+libxl__flock *libxl__lock_domid_history(libxl__gc *gc);
/*
* Retrieve / store domain configuration from / to libxl private
@@ -4769,6 +4772,17 @@ _hidden int libxl__domain_pvcontrol(libxl__egc *egc,
libxl__xswait_state *pvcontrol,
domid_t domid, const char *cmd);
+/*
+ * Maximum number of seconds after desctruction then a domid remains
+ * 'recent'. Recent domids are not allowed to be re-used. This can be
+ * overidden, for debugging purposes, by the environment variable of the
+ * same name.
+ */
+#define LIBXL_DOMID_REUSE_TIMEOUT 60
+
+/* Check whether a domid is recent */
+bool libxl__is_domid_recent(libxl__gc *gc, uint32_t domid);
+
#endif
/*
--
2.20.1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 29+ messages in thread* Re: [Xen-devel] [PATCH v4 4/7] libxl: add infrastructure to track and query 'recent' domids
2020-01-22 14:44 ` [Xen-devel] [PATCH v4 4/7] libxl: add infrastructure to track and query 'recent' domids Paul Durrant
@ 2020-01-30 17:23 ` Ian Jackson
2020-01-31 10:55 ` Anthony PERARD
1 sibling, 0 replies; 29+ messages in thread
From: Ian Jackson @ 2020-01-30 17:23 UTC (permalink / raw)
To: Paul Durrant; +Cc: Anthony Perard, xen-devel, Wei Liu
Paul Durrant writes ("[PATCH v4 4/7] libxl: add infrastructure to track and query 'recent' domids"):
> A domid is considered recent if the domain it represents was destroyed
> less than a specified number of seconds ago. The number can be set using
> the environment variable LIBXL_DOMID_REUSE_TIMEOUT. If the variable does
> not exist then a default value of 60s is used.
>
> Whenever a domain is destroyed, a time-stamped record will be written into
> a history file (/var/run/xen/domid-history). To avoid the history file
> growing too large, any records with time-stamps that indicate that the
> age of a domid has exceeded the re-use timeout will also be purged.
>
> A new utility function, libxl__is_recent_domid(), has been added. This
> function reads the same history file checking whether a specified domid
> has a record that does not exceed the re-use timeout. Since this utility
> function does not write to the file, no records are actually purged by it.
>
> NOTE: The history file is purged on boot to it is safe to use
> CLOCK_MONOTONIC as a time source.
Thanks.
> diff --git a/tools/helpers/xen-init-dom0.c b/tools/helpers/xen-init-dom0.c
> index a1e5729458..56f69ab66f 100644
> --- a/tools/helpers/xen-init-dom0.c
> +++ b/tools/helpers/xen-init-dom0.c
Thanks. This part is good.
> +static void libxl__mark_domid_recent(libxl__gc *gc, uint32_t domid)
> +{
...
> + clock_gettime(CLOCK_MONOTONIC, &ts);
> +
> + while (of && fgets(line, sizeof(line), of)) {
> + unsigned long sec;
> + unsigned int ignored;
> +
> + if (sscanf(line, "%lu %u", &sec, &ignored) != 2) {
> + LOGED(ERROR, domid, "ignoring malformed line: %s", line);
> + continue;
> + }
> +
> + if (ts.tv_sec - sec > timeout)
> + continue; /* Ignore expired entries */
I find this code quite similar to this code
> +bool libxl__is_domid_recent(libxl__gc *gc, uint32_t domid)
...
> + while (!feof(f)) {
> + unsigned long sec;
> + unsigned int check;
> +
> + if (fscanf(f, "%lu %u", &sec, &check) != 2)
> + continue;
> +
> + if (check == domid && ts.tv_sec - sec <= timeout) {
> + recent = true;
> + break;
> + }
This makes me uncomfortable. For one thing, it duplicates any bugs
(and there is at least one error handling anomaly here) and duplicates
my review effort looking for those bugs :-).
Do you think this can be combined somehow ? Possibilities seem to
include: explicit read_recent_{init,entry,finish} functions; a single
function with a "per-entry" callback; same but with a macro. If you
do that you can also have it have handle the "file does not exist"
special case.
Also, the stdio error handling doesn't seem quite right. What if
fgets gets a read error ?
While I'm looking at this, I found
> + while (of && fgets(line, sizeof(line), of)) {
that confusing. of!=0 is an entry condition, not a termination
condition. When I first read this I looked for modifications to of in
the loop but of course there aren't any.
If you really want to keep it like this I guess I will tolerate it to
avoid the argument...
> + fflush(nf);
Missing error check. Also you should fclose here, not just fflush.
When you do that, set nf to 0 so the out block doesn't re-close it.
> +bool libxl__is_domid_recent(libxl__gc *gc, uint32_t domid)
> +{
...
> + name = GCSPRINTF("%s/domid-history", libxl__run_dir_path());
> + f = fopen(name, "r");
> + if (!f) {
> + if (errno != ENOENT) LOGED(WARN, domid, "failed to open %s", name);
I think this (and other unexpected manipulation failures) should be
fatal, rather than merely a warning. That means your function should
return rc. Sorry. Same goes for libxl__mark_domid_recent.
Thanks,
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [Xen-devel] [PATCH v4 4/7] libxl: add infrastructure to track and query 'recent' domids
2020-01-22 14:44 ` [Xen-devel] [PATCH v4 4/7] libxl: add infrastructure to track and query 'recent' domids Paul Durrant
2020-01-30 17:23 ` Ian Jackson
@ 2020-01-31 10:55 ` Anthony PERARD
2020-01-31 10:57 ` Durrant, Paul
1 sibling, 1 reply; 29+ messages in thread
From: Anthony PERARD @ 2020-01-31 10:55 UTC (permalink / raw)
To: Paul Durrant; +Cc: xen-devel, Ian Jackson, Wei Liu
On Wed, Jan 22, 2020 at 02:44:43PM +0000, Paul Durrant wrote:
> A domid is considered recent if the domain it represents was destroyed
> less than a specified number of seconds ago. The number can be set using
> the environment variable LIBXL_DOMID_REUSE_TIMEOUT. If the variable does
> not exist then a default value of 60s is used.
Could you rewrite that part of the commit message? By reading it, it
sounds to me like LIBXL_DOMID_REUSE_TIMEOUT is a configuration variable
that a toolstack may want to set. Whereas the comment in
libxl_internal.h indicates that it's for debuging. Having env var for
debugging sounds good, but having env var as configuration doesn't.
> +/*
> + * Maximum number of seconds after desctruction then a domid remains
> + * 'recent'. Recent domids are not allowed to be re-used. This can be
> + * overidden, for debugging purposes, by the environment variable of the
> + * same name.
> + */
> +#define LIBXL_DOMID_REUSE_TIMEOUT 60
Thanks,
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Xen-devel] [PATCH v4 4/7] libxl: add infrastructure to track and query 'recent' domids
2020-01-31 10:55 ` Anthony PERARD
@ 2020-01-31 10:57 ` Durrant, Paul
0 siblings, 0 replies; 29+ messages in thread
From: Durrant, Paul @ 2020-01-31 10:57 UTC (permalink / raw)
To: Anthony PERARD; +Cc: xen-devel, Ian Jackson, Wei Liu
> -----Original Message-----
> From: Anthony PERARD <anthony.perard@citrix.com>
> Sent: 31 January 2020 10:55
> To: Durrant, Paul <pdurrant@amazon.co.uk>
> Cc: xen-devel@lists.xenproject.org; Ian Jackson
> <ian.jackson@eu.citrix.com>; Wei Liu <wl@xen.org>
> Subject: Re: [PATCH v4 4/7] libxl: add infrastructure to track and query
> 'recent' domids
>
> On Wed, Jan 22, 2020 at 02:44:43PM +0000, Paul Durrant wrote:
> > A domid is considered recent if the domain it represents was destroyed
> > less than a specified number of seconds ago. The number can be set using
> > the environment variable LIBXL_DOMID_REUSE_TIMEOUT. If the variable does
> > not exist then a default value of 60s is used.
>
> Could you rewrite that part of the commit message? By reading it, it
> sounds to me like LIBXL_DOMID_REUSE_TIMEOUT is a configuration variable
> that a toolstack may want to set. Whereas the comment in
> libxl_internal.h indicates that it's for debuging. Having env var for
> debugging sounds good, but having env var as configuration doesn't.
>
Sure, I'll make the commit comment clearer.
Paul
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Xen-devel] [PATCH v4 5/7] libxl: allow creation of domains with a specified or random domid
2020-01-22 14:44 [Xen-devel] [PATCH v4 0/7] xl/libxl: domid allocation/preservation changes Paul Durrant
` (3 preceding siblings ...)
2020-01-22 14:44 ` [Xen-devel] [PATCH v4 4/7] libxl: add infrastructure to track and query 'recent' domids Paul Durrant
@ 2020-01-22 14:44 ` Paul Durrant
2020-01-30 17:25 ` Ian Jackson
2020-01-22 14:44 ` [Xen-devel] [PATCH v4 6/7] xl.conf: introduce 'domid_policy' Paul Durrant
2020-01-22 14:44 ` [Xen-devel] [PATCH v4 7/7] xl: allow domid to be preserved on save/restore or migrate Paul Durrant
6 siblings, 1 reply; 29+ messages in thread
From: Paul Durrant @ 2020-01-22 14:44 UTC (permalink / raw)
To: xen-devel
Cc: Stefano Stabellini, Julien Grall, Wei Liu, Konrad Rzeszutek Wilk,
George Dunlap, Andrew Cooper, Paul Durrant, Jason Andryuk,
Ian Jackson, Anthony PERARD
This patch adds a 'domid' field to libxl_domain_create_info and then
modifies libxl__domain_make() to have Xen use that value if it is valid.
If the domid value is invalid then Xen will choose the domid, as before,
unless the value is the new special RANDOM_DOMID value added to the API.
This value instructs libxl__domain_make() to choose a random domid value
for Xen to use.
If Xen determines that a domid specified to or chosen by
libxl__domain_make() co-incides with an existing domain then the create
operation will fail. In this case, if RANDOM_DOMID was specified to
libxl__domain_make() then a new random value will be chosen and the create
operation will be re-tried, otherwise libxl__domain_make() will fail.
After Xen has successfully created a new domain, libxl__domain_make() will
check whether its domid matches any recently used domid values. If it does
then the domain will be destroyed. If the domid used in creation was
specified to libxl__domain_make() then it will fail at this point,
otherwise the create operation will be re-tried with either a new random
or Xen-selected domid value.
NOTE: libxl__logv() is also modified to only log valid domid values in
messages rather than any domid, valid or otherwise, that is not
INVALID_DOMID.
Signed-off-by: Paul Durrant <pdurrant@amazon.com>
---
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Wei Liu <wl@xen.org>
Cc: Anthony PERARD <anthony.perard@citrix.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Julien Grall <julien@xen.org>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>
Cc: Jason Andryuk <jandryuk@gmail.com>
v4:
- Not added Jason's R-b because of substantial change
- Check for recent domid *after* creation
- Re-worked commit comment
v3:
- Added DOMID_MASK definition used to mask randomized values
- Use stack variable to avoid assuming endianness
v2:
- Re-worked to use a value from libxl_domain_create_info
---
tools/libxl/libxl.h | 9 ++++++++
tools/libxl/libxl_create.c | 43 +++++++++++++++++++++++++++++++++++-
tools/libxl/libxl_internal.c | 2 +-
tools/libxl/libxl_types.idl | 1 +
xen/include/public/xen.h | 3 +++
5 files changed, 56 insertions(+), 2 deletions(-)
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 1d235ecb1c..31c6f4b11a 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -1268,6 +1268,14 @@ void libxl_mac_copy(libxl_ctx *ctx, libxl_mac *dst, const libxl_mac *src);
*/
#define LIBXL_HAVE_DOMAIN_NEED_MEMORY_CONFIG
+/*
+ * LIBXL_HAVE_CREATEINFO_DOMID
+ *
+ * libxl_domain_create_new() and libxl_domain_create_restore() will use
+ * a domid specified in libxl_domain_create_info().
+ */
+#define LIBXL_HAVE_CREATEINFO_DOMID
+
typedef char **libxl_string_list;
void libxl_string_list_dispose(libxl_string_list *sl);
int libxl_string_list_length(const libxl_string_list *sl);
@@ -1528,6 +1536,7 @@ int libxl_ctx_free(libxl_ctx *ctx /* 0 is OK */);
/* domain related functions */
#define INVALID_DOMID ~0
+#define RANDOM_DOMID (INVALID_DOMID - 1)
/* If the result is ERROR_ABORTED, the domain may or may not exist
* (in a half-created state). *domid will be valid and will be the
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index e4aab4fd1c..593bf9d225 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -600,9 +600,50 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config,
goto out;
}
- ret = xc_domain_create(ctx->xch, domid, &create);
+ if (libxl_domid_valid_guest(info->domid))
+ *domid = info->domid;
+
+ again:
+ for (;;) {
+ if (info->domid == RANDOM_DOMID) {
+ uint16_t v;
+
+ ret = libxl__random_bytes(gc, (void *)&v, sizeof(v));
+ if (ret < 0)
+ break;
+
+ v &= DOMID_MASK;
+ if (!libxl_domid_valid_guest(v))
+ continue;
+
+ *domid = v;
+ }
+
+ ret = xc_domain_create(ctx->xch, domid, &create);
+ if (ret == 0 || errno != EEXIST || info->domid != RANDOM_DOMID)
+ break;
+ }
+
if (ret < 0) {
LOGED(ERROR, *domid, "domain creation fail");
+ *domid = INVALID_DOMID;
+ rc = ERROR_FAIL;
+ goto out;
+ }
+
+ if (libxl__is_domid_recent(gc, *domid)) {
+ if (*domid == info->domid) /* domid was specified */
+ LOGED(ERROR, *domid, "domain id recently used");
+
+ ret = xc_domain_destroy(ctx->xch, *domid);
+ if (!ret) {
+ *domid = INVALID_DOMID;
+
+ /* If the domid was not specified then have another go */
+ if (!libxl_domid_valid_guest(info->domid))
+ goto again;
+ }
+
rc = ERROR_FAIL;
goto out;
}
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index bbd4c6cba9..d93a75533f 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -234,7 +234,7 @@ void libxl__logv(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
fileline[sizeof(fileline)-1] = 0;
domain[0] = 0;
- if (domid != INVALID_DOMID)
+ if (libxl_domid_valid_guest(domid))
snprintf(domain, sizeof(domain), "Domain %"PRIu32":", domid);
x:
xtl_log(ctx->lg, msglevel, errnoval, "libxl",
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 7921950f6a..d0d431614f 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -409,6 +409,7 @@ libxl_domain_create_info = Struct("domain_create_info",[
("ssidref", uint32),
("ssid_label", string),
("name", string),
+ ("domid", libxl_domid),
("uuid", libxl_uuid),
("xsdata", libxl_key_value_list),
("platformdata", libxl_key_value_list),
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)
+
#ifndef __ASSEMBLY__
typedef uint16_t domid_t;
--
2.20.1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 29+ messages in thread* Re: [Xen-devel] [PATCH v4 5/7] libxl: allow creation of domains with a specified or random domid
2020-01-22 14:44 ` [Xen-devel] [PATCH v4 5/7] libxl: allow creation of domains with a specified or random domid Paul Durrant
@ 2020-01-30 17:25 ` Ian Jackson
2020-01-30 17:32 ` Durrant, Paul
0 siblings, 1 reply; 29+ messages in thread
From: Ian Jackson @ 2020-01-30 17:25 UTC (permalink / raw)
To: Paul Durrant
Cc: Stefano Stabellini, Julien Grall, Wei Liu, Konrad Rzeszutek Wilk,
Andrew Cooper, Jason Andryuk, George Dunlap, Anthony Perard,
xen-devel
Paul Durrant writes ("[PATCH v4 5/7] libxl: allow creation of domains with a specified or random domid"):
> This patch adds a 'domid' field to libxl_domain_create_info and then
> modifies libxl__domain_make() to have Xen use that value if it is valid.
> If the domid value is invalid then Xen will choose the domid, as before,
> unless the value is the new special RANDOM_DOMID value added to the API.
> This value instructs libxl__domain_make() to choose a random domid value
> for Xen to use.
>
> If Xen determines that a domid specified to or chosen by
> libxl__domain_make() co-incides with an existing domain then the create
> operation will fail. In this case, if RANDOM_DOMID was specified to
> libxl__domain_make() then a new random value will be chosen and the create
> operation will be re-tried, otherwise libxl__domain_make() will fail.
>
> After Xen has successfully created a new domain, libxl__domain_make() will
> check whether its domid matches any recently used domid values. If it does
> then the domain will be destroyed. If the domid used in creation was
> specified to libxl__domain_make() then it will fail at this point,
> otherwise the create operation will be re-tried with either a new random
> or Xen-selected domid value.
...
> - ret = xc_domain_create(ctx->xch, domid, &create);
> + if (libxl_domid_valid_guest(info->domid))
> + *domid = info->domid;
> +
> + again:
> + for (;;) {
> + if (info->domid == RANDOM_DOMID) {
> + uint16_t v;
> +
> + ret = libxl__random_bytes(gc, (void *)&v, sizeof(v));
> + if (ret < 0)
> + break;
> +
> + v &= DOMID_MASK;
> + if (!libxl_domid_valid_guest(v))
> + continue;
> +
> + *domid = v;
> + }
> +
> + ret = xc_domain_create(ctx->xch, domid, &create);
> + if (ret == 0 || errno != EEXIST || info->domid != RANDOM_DOMID)
> + break;
> + }
> +
> if (ret < 0) {
> LOGED(ERROR, *domid, "domain creation fail");
> + *domid = INVALID_DOMID;
> + rc = ERROR_FAIL;
> + goto out;
> + }
> +
> + if (libxl__is_domid_recent(gc, *domid)) {
> + if (*domid == info->domid) /* domid was specified */
> + LOGED(ERROR, *domid, "domain id recently used");
> +
> + ret = xc_domain_destroy(ctx->xch, *domid);
> + if (!ret) {
> + *domid = INVALID_DOMID;
> +
> + /* If the domid was not specified then have another go */
> + if (!libxl_domid_valid_guest(info->domid))
> + goto again;
> + }
You have written this as two nested loops, one of which is implemented
as a goto, but actually logically this is surely only one loop ?
Please could you reorganise this and then I'll read it again...
Thanks,
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [Xen-devel] [PATCH v4 5/7] libxl: allow creation of domains with a specified or random domid
2020-01-30 17:25 ` Ian Jackson
@ 2020-01-30 17:32 ` Durrant, Paul
0 siblings, 0 replies; 29+ messages in thread
From: Durrant, Paul @ 2020-01-30 17:32 UTC (permalink / raw)
To: Ian Jackson
Cc: Stefano Stabellini, Julien Grall, Wei Liu, Konrad Rzeszutek Wilk,
Andrew Cooper, Jason Andryuk, George Dunlap, Anthony Perard,
xen-devel
> -----Original Message-----
> From: Ian Jackson <ian.jackson@citrix.com>
> Sent: 30 January 2020 17:26
> To: Durrant, Paul <pdurrant@amazon.co.uk>
> Cc: xen-devel@lists.xenproject.org; Wei Liu <wl@xen.org>; Anthony Perard
> <anthony.perard@citrix.com>; Andrew Cooper <Andrew.Cooper3@citrix.com>;
> George Dunlap <George.Dunlap@citrix.com>; Jan Beulich <jbeulich@suse.com>;
> Julien Grall <julien@xen.org>; Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com>; Stefano Stabellini <sstabellini@kernel.org>;
> Jason Andryuk <jandryuk@gmail.com>
> Subject: Re: [PATCH v4 5/7] libxl: allow creation of domains with a
> specified or random domid
>
> Paul Durrant writes ("[PATCH v4 5/7] libxl: allow creation of domains with
> a specified or random domid"):
> > This patch adds a 'domid' field to libxl_domain_create_info and then
> > modifies libxl__domain_make() to have Xen use that value if it is valid.
> > If the domid value is invalid then Xen will choose the domid, as before,
> > unless the value is the new special RANDOM_DOMID value added to the API.
> > This value instructs libxl__domain_make() to choose a random domid value
> > for Xen to use.
> >
> > If Xen determines that a domid specified to or chosen by
> > libxl__domain_make() co-incides with an existing domain then the create
> > operation will fail. In this case, if RANDOM_DOMID was specified to
> > libxl__domain_make() then a new random value will be chosen and the
> create
> > operation will be re-tried, otherwise libxl__domain_make() will fail.
> >
> > After Xen has successfully created a new domain, libxl__domain_make()
> will
> > check whether its domid matches any recently used domid values. If it
> does
> > then the domain will be destroyed. If the domid used in creation was
> > specified to libxl__domain_make() then it will fail at this point,
> > otherwise the create operation will be re-tried with either a new random
> > or Xen-selected domid value.
> ...
> > - ret = xc_domain_create(ctx->xch, domid, &create);
> > + if (libxl_domid_valid_guest(info->domid))
> > + *domid = info->domid;
> > +
> > + again:
> > + for (;;) {
> > + if (info->domid == RANDOM_DOMID) {
> > + uint16_t v;
> > +
> > + ret = libxl__random_bytes(gc, (void *)&v, sizeof(v));
> > + if (ret < 0)
> > + break;
> > +
> > + v &= DOMID_MASK;
> > + if (!libxl_domid_valid_guest(v))
> > + continue;
> > +
> > + *domid = v;
> > + }
> > +
> > + ret = xc_domain_create(ctx->xch, domid, &create);
> > + if (ret == 0 || errno != EEXIST || info->domid !=
> RANDOM_DOMID)
> > + break;
> > + }
> > +
> > if (ret < 0) {
> > LOGED(ERROR, *domid, "domain creation fail");
> > + *domid = INVALID_DOMID;
> > + rc = ERROR_FAIL;
> > + goto out;
> > + }
> > +
> > + if (libxl__is_domid_recent(gc, *domid)) {
> > + if (*domid == info->domid) /* domid was specified */
> > + LOGED(ERROR, *domid, "domain id recently used");
> > +
> > + ret = xc_domain_destroy(ctx->xch, *domid);
> > + if (!ret) {
> > + *domid = INVALID_DOMID;
> > +
> > + /* If the domid was not specified then have another go
> */
> > + if (!libxl_domid_valid_guest(info->domid))
> > + goto again;
> > + }
>
> You have written this as two nested loops, one of which is implemented
> as a goto, but actually logically this is surely only one loop ?
> Please could you reorganise this and then I'll read it again...
>
Ok, I'll try to squash it down to one. It should be do-able.
Paul
> Thanks,
> Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Xen-devel] [PATCH v4 6/7] xl.conf: introduce 'domid_policy'
2020-01-22 14:44 [Xen-devel] [PATCH v4 0/7] xl/libxl: domid allocation/preservation changes Paul Durrant
` (4 preceding siblings ...)
2020-01-22 14:44 ` [Xen-devel] [PATCH v4 5/7] libxl: allow creation of domains with a specified or random domid Paul Durrant
@ 2020-01-22 14:44 ` Paul Durrant
2020-01-22 14:44 ` [Xen-devel] [PATCH v4 7/7] xl: allow domid to be preserved on save/restore or migrate Paul Durrant
6 siblings, 0 replies; 29+ messages in thread
From: Paul Durrant @ 2020-01-22 14:44 UTC (permalink / raw)
To: xen-devel; +Cc: Anthony PERARD, Paul Durrant, Ian Jackson, Wei Liu
This patch adds a new global 'domid_policy' configuration option to decide
how domain id values are allocated for new domains. It may be set to one of
two values:
"xen", the default value, will cause an invalid domid value to be passed
to do_domain_create() preserving the existing behaviour of having Xen
choose the domid value during domain_create().
"random" will cause the special RANDOM_DOMID value to be passed to
do_domain_create() such that libxl__domain_make() will select a random
domid value.
Signed-off-by: Paul Durrant <pdurrant@amazon.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
Cc: Wei Liu <wl@xen.org>
Cc: Anthony PERARD <anthony.perard@citrix.com>
v2:
- New in v2
---
docs/man/xl.conf.5.pod | 10 ++++++++++
tools/examples/xl.conf | 4 ++++
tools/xl/xl.c | 10 ++++++++++
tools/xl/xl.h | 1 +
tools/xl/xl_vmcontrol.c | 2 ++
5 files changed, 27 insertions(+)
diff --git a/docs/man/xl.conf.5.pod b/docs/man/xl.conf.5.pod
index 207ab3e77a..41ee428744 100644
--- a/docs/man/xl.conf.5.pod
+++ b/docs/man/xl.conf.5.pod
@@ -45,6 +45,16 @@ The semantics of each C<KEY> defines which form of C<VALUE> is required.
=over 4
+=item B<domid_policy="xen"|"random">
+
+Determines how domain-id is set when creating a new domain.
+
+If set to "xen" then the hypervisor will allocate new domain-id values on a sequential basis.
+
+If set to "random" then a random domain-id value will be chosen.
+
+Default: "xen"
+
=item B<autoballoon="off"|"on"|"auto">
If set to "on" then C<xl> will automatically reduce the amount of
diff --git a/tools/examples/xl.conf b/tools/examples/xl.conf
index 0446deb304..95f2f442d3 100644
--- a/tools/examples/xl.conf
+++ b/tools/examples/xl.conf
@@ -1,5 +1,9 @@
## Global XL config file ##
+# Set domain-id policy. "xen" means that the hypervisor will choose the
+# id of a new domain. "random" means that a random value will be chosen.
+#domid_policy="xen"
+
# Control whether dom0 is ballooned down when xen doesn't have enough
# free memory to create a domain. "auto" means only balloon if dom0
# starts with all the host's memory.
diff --git a/tools/xl/xl.c b/tools/xl/xl.c
index 3d4390a46d..2a5ddd4390 100644
--- a/tools/xl/xl.c
+++ b/tools/xl/xl.c
@@ -54,6 +54,7 @@ int claim_mode = 1;
bool progress_use_cr = 0;
int max_grant_frames = -1;
int max_maptrack_frames = -1;
+libxl_domid domid_policy = INVALID_DOMID;
xentoollog_level minmsglevel = minmsglevel_default;
@@ -228,6 +229,15 @@ static void parse_global_config(const char *configfile,
else
libxl_bitmap_set_any(&global_pv_affinity_mask);
+ if (!xlu_cfg_get_string (config, "domid_policy", &buf, 0)) {
+ if (!strcmp(buf, "xen"))
+ domid_policy = INVALID_DOMID;
+ else if (!strcmp(buf, "random"))
+ domid_policy = RANDOM_DOMID;
+ else
+ fprintf(stderr, "invalid domid_policy option");
+ }
+
xlu_cfg_destroy(config);
}
diff --git a/tools/xl/xl.h b/tools/xl/xl.h
index 60bdad8ffb..2b4709efb2 100644
--- a/tools/xl/xl.h
+++ b/tools/xl/xl.h
@@ -283,6 +283,7 @@ extern int max_maptrack_frames;
extern libxl_bitmap global_vm_affinity_mask;
extern libxl_bitmap global_hvm_affinity_mask;
extern libxl_bitmap global_pv_affinity_mask;
+extern libxl_domid domid_policy;
enum output_format {
OUTPUT_FORMAT_JSON,
diff --git a/tools/xl/xl_vmcontrol.c b/tools/xl/xl_vmcontrol.c
index e520b1da79..39292acfe6 100644
--- a/tools/xl/xl_vmcontrol.c
+++ b/tools/xl/xl_vmcontrol.c
@@ -899,6 +899,8 @@ start:
autoconnect_console_how = 0;
}
+ d_config.c_info.domid = domid_policy;
+
if ( restoring ) {
libxl_domain_restore_params params;
--
2.20.1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 29+ messages in thread* [Xen-devel] [PATCH v4 7/7] xl: allow domid to be preserved on save/restore or migrate
2020-01-22 14:44 [Xen-devel] [PATCH v4 0/7] xl/libxl: domid allocation/preservation changes Paul Durrant
` (5 preceding siblings ...)
2020-01-22 14:44 ` [Xen-devel] [PATCH v4 6/7] xl.conf: introduce 'domid_policy' Paul Durrant
@ 2020-01-22 14:44 ` Paul Durrant
2020-01-30 17:28 ` Ian Jackson
6 siblings, 1 reply; 29+ messages in thread
From: Paul Durrant @ 2020-01-22 14:44 UTC (permalink / raw)
To: xen-devel; +Cc: Anthony PERARD, Paul Durrant, Ian Jackson, Wei Liu
This patch adds a '-D' command line option to save and migrate to allow
the domain id to be incorporated into the saved domain configuration and
hence be preserved.
Signed-off-by: Paul Durrant <pdurrant@amazon.com>
---
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Wei Liu <wl@xen.org>
Cc: Anthony PERARD <anthony.perard@citrix.com>
v2:
- Heavily re-worked based on new libxl_domain_create_info
---
docs/man/xl.1.pod.in | 14 ++++++++++++++
tools/xl/xl.h | 1 +
tools/xl/xl_cmdtable.c | 6 ++++--
tools/xl/xl_migrate.c | 15 ++++++++++-----
tools/xl/xl_saverestore.c | 19 ++++++++++++++-----
tools/xl/xl_vmcontrol.c | 3 ++-
6 files changed, 45 insertions(+), 13 deletions(-)
diff --git a/docs/man/xl.1.pod.in b/docs/man/xl.1.pod.in
index d4b5e8e362..937eda690f 100644
--- a/docs/man/xl.1.pod.in
+++ b/docs/man/xl.1.pod.in
@@ -490,6 +490,13 @@ Display huge (!) amount of debug information during the migration process.
Leave the domain on the receive side paused after migration.
+=item B<-D>
+
+Preserve the B<domain-id> in the domain coniguration that is transferred
+such that it will be identical on the destination host, unless that
+configuration is overridden using the B<-C> option. Note that it is not
+possible to use this option for a 'localhost' migration.
+
=back
=item B<remus> [I<OPTIONS>] I<domain-id> I<host>
@@ -692,6 +699,13 @@ Leave the domain running after creating the snapshot.
Leave the domain paused after creating the snapshot.
+=item B<-D>
+
+Preserve the B<domain-id> in the domain coniguration that is embedded in
+the state file such that it will be identical when the domain is restored,
+unless that configuration is overridden. (See the B<restore> operation
+above).
+
=back
=item B<sharing> [I<domain-id>]
diff --git a/tools/xl/xl.h b/tools/xl/xl.h
index 2b4709efb2..06569c6c4a 100644
--- a/tools/xl/xl.h
+++ b/tools/xl/xl.h
@@ -99,6 +99,7 @@ struct save_file_header {
#define SAVEFILE_BYTEORDER_VALUE ((uint32_t)0x01020304UL)
void save_domain_core_begin(uint32_t domid,
+ int preserve_domid,
const char *override_config_file,
uint8_t **config_data_r,
int *config_len_r);
diff --git a/tools/xl/xl_cmdtable.c b/tools/xl/xl_cmdtable.c
index 3b302b2f20..08335394e5 100644
--- a/tools/xl/xl_cmdtable.c
+++ b/tools/xl/xl_cmdtable.c
@@ -153,7 +153,8 @@ struct cmd_spec cmd_table[] = {
"[options] <Domain> <CheckpointFile> [<ConfigFile>]",
"-h Print this help.\n"
"-c Leave domain running after creating the snapshot.\n"
- "-p Leave domain paused after creating the snapshot."
+ "-p Leave domain paused after creating the snapshot.\n"
+ "-D Store the domain id in the configration."
},
{ "migrate",
&main_migrate, 0, 1,
@@ -167,7 +168,8 @@ struct cmd_spec cmd_table[] = {
"-e Do not wait in the background (on <host>) for the death\n"
" of the domain.\n"
"--debug Print huge (!) amount of debug during the migration process.\n"
- "-p Do not unpause domain after migrating it."
+ "-p Do not unpause domain after migrating it.\n"
+ "-D Preserve the domain id"
},
{ "restore",
&main_restore, 0, 1,
diff --git a/tools/xl/xl_migrate.c b/tools/xl/xl_migrate.c
index 22f0429b84..0813beb801 100644
--- a/tools/xl/xl_migrate.c
+++ b/tools/xl/xl_migrate.c
@@ -176,7 +176,8 @@ static void migrate_do_preamble(int send_fd, int recv_fd, pid_t child,
}
-static void migrate_domain(uint32_t domid, const char *rune, int debug,
+static void migrate_domain(uint32_t domid, int preserve_domid,
+ const char *rune, int debug,
const char *override_config_file)
{
pid_t child = -1;
@@ -187,7 +188,7 @@ static void migrate_domain(uint32_t domid, const char *rune, int debug,
uint8_t *config_data;
int config_len, flags = LIBXL_SUSPEND_LIVE;
- save_domain_core_begin(domid, override_config_file,
+ save_domain_core_begin(domid, preserve_domid, override_config_file,
&config_data, &config_len);
if (!config_len) {
@@ -537,13 +538,14 @@ int main_migrate(int argc, char **argv)
char *rune = NULL;
char *host;
int opt, daemonize = 1, monitor = 1, debug = 0, pause_after_migration = 0;
+ int preserve_domid = 0;
static struct option opts[] = {
{"debug", 0, 0, 0x100},
{"live", 0, 0, 0x200},
COMMON_LONG_OPTS
};
- SWITCH_FOREACH_OPT(opt, "FC:s:ep", opts, "migrate", 2) {
+ SWITCH_FOREACH_OPT(opt, "FC:s:epD", opts, "migrate", 2) {
case 'C':
config_filename = optarg;
break;
@@ -560,6 +562,9 @@ int main_migrate(int argc, char **argv)
case 'p':
pause_after_migration = 1;
break;
+ case 'D':
+ preserve_domid = 1;
+ break;
case 0x100: /* --debug */
debug = 1;
break;
@@ -596,7 +601,7 @@ int main_migrate(int argc, char **argv)
pause_after_migration ? " -p" : "");
}
- migrate_domain(domid, rune, debug, config_filename);
+ migrate_domain(domid, preserve_domid, rune, debug, config_filename);
return EXIT_SUCCESS;
}
@@ -716,7 +721,7 @@ int main_remus(int argc, char **argv)
}
}
- save_domain_core_begin(domid, NULL, &config_data, &config_len);
+ save_domain_core_begin(domid, 0, NULL, &config_data, &config_len);
if (!config_len) {
fprintf(stderr, "No config file stored for running domain and "
diff --git a/tools/xl/xl_saverestore.c b/tools/xl/xl_saverestore.c
index 9be033fe65..953d791d1a 100644
--- a/tools/xl/xl_saverestore.c
+++ b/tools/xl/xl_saverestore.c
@@ -32,6 +32,7 @@
#ifndef LIBXL_HAVE_NO_SUSPEND_RESUME
void save_domain_core_begin(uint32_t domid,
+ int preserve_domid,
const char *override_config_file,
uint8_t **config_data_r,
int *config_len_r)
@@ -62,6 +63,8 @@ void save_domain_core_begin(uint32_t domid,
fprintf(stderr, "unable to retrieve domain configuration\n");
exit(EXIT_FAILURE);
}
+
+ d_config.c_info.domid = preserve_domid ? domid : 0;
}
config_c = libxl_domain_config_to_json(ctx, &d_config);
@@ -120,14 +123,15 @@ void save_domain_core_writeconfig(int fd, const char *source,
hdr.optional_data_len);
}
-static int save_domain(uint32_t domid, const char *filename, int checkpoint,
- int leavepaused, const char *override_config_file)
+static int save_domain(uint32_t domid, int preserve_domid,
+ const char *filename, int checkpoint,
+ int leavepaused, const char *override_config_file)
{
int fd;
uint8_t *config_data;
int config_len;
- save_domain_core_begin(domid, override_config_file,
+ save_domain_core_begin(domid, preserve_domid, override_config_file,
&config_data, &config_len);
if (!config_len) {
@@ -236,15 +240,19 @@ int main_save(int argc, char **argv)
const char *config_filename = NULL;
int checkpoint = 0;
int leavepaused = 0;
+ int preserve_domid = 0;
int opt;
- SWITCH_FOREACH_OPT(opt, "cp", NULL, "save", 2) {
+ SWITCH_FOREACH_OPT(opt, "cpD", NULL, "save", 2) {
case 'c':
checkpoint = 1;
break;
case 'p':
leavepaused = 1;
break;
+ case 'D':
+ preserve_domid = 1;
+ break;
}
if (argc-optind > 3) {
@@ -257,7 +265,8 @@ int main_save(int argc, char **argv)
if ( argc - optind >= 3 )
config_filename = argv[optind + 2];
- save_domain(domid, filename, checkpoint, leavepaused, config_filename);
+ save_domain(domid, preserve_domid, filename, checkpoint, leavepaused,
+ config_filename);
return EXIT_SUCCESS;
}
diff --git a/tools/xl/xl_vmcontrol.c b/tools/xl/xl_vmcontrol.c
index 39292acfe6..2e2d427492 100644
--- a/tools/xl/xl_vmcontrol.c
+++ b/tools/xl/xl_vmcontrol.c
@@ -899,7 +899,8 @@ start:
autoconnect_console_how = 0;
}
- d_config.c_info.domid = domid_policy;
+ if (!libxl_domid_valid_guest(d_config.c_info.domid))
+ d_config.c_info.domid = domid_policy;
if ( restoring ) {
libxl_domain_restore_params params;
--
2.20.1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 29+ messages in thread* Re: [Xen-devel] [PATCH v4 7/7] xl: allow domid to be preserved on save/restore or migrate
2020-01-22 14:44 ` [Xen-devel] [PATCH v4 7/7] xl: allow domid to be preserved on save/restore or migrate Paul Durrant
@ 2020-01-30 17:28 ` Ian Jackson
2020-01-30 17:42 ` Durrant, Paul
0 siblings, 1 reply; 29+ messages in thread
From: Ian Jackson @ 2020-01-30 17:28 UTC (permalink / raw)
To: Paul Durrant; +Cc: Anthony Perard, xen-devel, Wei Liu
Paul Durrant writes ("[PATCH v4 7/7] xl: allow domid to be preserved on save/restore or migrate"):
> This patch adds a '-D' command line option to save and migrate to allow
> the domain id to be incorporated into the saved domain configuration and
> hence be preserved.
Thanks.
In response to v3 6/6 I wrote:
I wonder if this should be done more in libxl. Should this be a
domain property ? Wei, Anthony ?
This question remains unanswered. I'm sorry that neither Wei nor
Anthony had a chance to answer yet...
Paul, do you have a reason for doing it this way ? My inclination is
that think doing it at the libxl layer would make more sense. Do you
think that would be possible ?
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [Xen-devel] [PATCH v4 7/7] xl: allow domid to be preserved on save/restore or migrate
2020-01-30 17:28 ` Ian Jackson
@ 2020-01-30 17:42 ` Durrant, Paul
2020-01-30 18:20 ` Andrew Cooper
0 siblings, 1 reply; 29+ messages in thread
From: Durrant, Paul @ 2020-01-30 17:42 UTC (permalink / raw)
To: Ian Jackson; +Cc: Anthony Perard, xen-devel, Wei Liu
> -----Original Message-----
> From: Ian Jackson <ian.jackson@citrix.com>
> Sent: 30 January 2020 17:29
> To: Durrant, Paul <pdurrant@amazon.co.uk>
> Cc: xen-devel@lists.xenproject.org; Wei Liu <wl@xen.org>; Anthony Perard
> <anthony.perard@citrix.com>
> Subject: Re: [PATCH v4 7/7] xl: allow domid to be preserved on
> save/restore or migrate
>
> Paul Durrant writes ("[PATCH v4 7/7] xl: allow domid to be preserved on
> save/restore or migrate"):
> > This patch adds a '-D' command line option to save and migrate to allow
> > the domain id to be incorporated into the saved domain configuration and
> > hence be preserved.
>
> Thanks.
>
> In response to v3 6/6 I wrote:
>
> I wonder if this should be done more in libxl. Should this be a
> domain property ? Wei, Anthony ?
>
> This question remains unanswered. I'm sorry that neither Wei nor
> Anthony had a chance to answer yet...
>
> Paul, do you have a reason for doing it this way ? My inclination is
> that think doing it at the libxl layer would make more sense. Do you
> think that would be possible ?
>
I'm not sure how it would work at the libxl level as the domid is part of create_info and that it transferred by xl on migration. IIUC we'd need a new libxl save record to transfer it at that level, and then I'm not sure whether we'd hit an ordering problem as we'd have to dig that save record out before we could actually create the domain.
Paul
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [Xen-devel] [PATCH v4 7/7] xl: allow domid to be preserved on save/restore or migrate
2020-01-30 17:42 ` Durrant, Paul
@ 2020-01-30 18:20 ` Andrew Cooper
2020-01-31 16:07 ` Wei Liu
0 siblings, 1 reply; 29+ messages in thread
From: Andrew Cooper @ 2020-01-30 18:20 UTC (permalink / raw)
To: Durrant, Paul, Ian Jackson; +Cc: Anthony Perard, xen-devel, Wei Liu
On 30/01/2020 17:42, Durrant, Paul wrote:
>> -----Original Message-----
>> From: Ian Jackson <ian.jackson@citrix.com>
>> Sent: 30 January 2020 17:29
>> To: Durrant, Paul <pdurrant@amazon.co.uk>
>> Cc: xen-devel@lists.xenproject.org; Wei Liu <wl@xen.org>; Anthony Perard
>> <anthony.perard@citrix.com>
>> Subject: Re: [PATCH v4 7/7] xl: allow domid to be preserved on
>> save/restore or migrate
>>
>> Paul Durrant writes ("[PATCH v4 7/7] xl: allow domid to be preserved on
>> save/restore or migrate"):
>>> This patch adds a '-D' command line option to save and migrate to allow
>>> the domain id to be incorporated into the saved domain configuration and
>>> hence be preserved.
>> Thanks.
>>
>> In response to v3 6/6 I wrote:
>>
>> I wonder if this should be done more in libxl. Should this be a
>> domain property ? Wei, Anthony ?
>>
>> This question remains unanswered. I'm sorry that neither Wei nor
>> Anthony had a chance to answer yet...
>>
>> Paul, do you have a reason for doing it this way ? My inclination is
>> that think doing it at the libxl layer would make more sense. Do you
>> think that would be possible ?
>>
> I'm not sure how it would work at the libxl level as the domid is part of create_info and that it transferred by xl on migration. IIUC we'd need a new libxl save record to transfer it at that level, and then I'm not sure whether we'd hit an ordering problem as we'd have to dig that save record out before we could actually create the domain.
There is definitely an ordering problem.
I agree that it should logically be part of the libxl level of the
stream, but none of that is even parsed until after the domain has been
created on the destination side.
I have no idea how easy/difficult it would be to rearrange libxl to
start parsing the migration stream before creating the domain. I think
there will be a lot of code relying on the domid already being valid.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [Xen-devel] [PATCH v4 7/7] xl: allow domid to be preserved on save/restore or migrate
2020-01-30 18:20 ` Andrew Cooper
@ 2020-01-31 16:07 ` Wei Liu
2020-02-01 11:56 ` Durrant, Paul
0 siblings, 1 reply; 29+ messages in thread
From: Wei Liu @ 2020-01-31 16:07 UTC (permalink / raw)
To: Andrew Cooper
Cc: Anthony Perard, Ian Jackson, xen-devel, Wei Liu, Durrant, Paul
On Thu, Jan 30, 2020 at 06:20:08PM +0000, Andrew Cooper wrote:
> On 30/01/2020 17:42, Durrant, Paul wrote:
> >> -----Original Message-----
> >> From: Ian Jackson <ian.jackson@citrix.com>
> >> Sent: 30 January 2020 17:29
> >> To: Durrant, Paul <pdurrant@amazon.co.uk>
> >> Cc: xen-devel@lists.xenproject.org; Wei Liu <wl@xen.org>; Anthony Perard
> >> <anthony.perard@citrix.com>
> >> Subject: Re: [PATCH v4 7/7] xl: allow domid to be preserved on
> >> save/restore or migrate
> >>
> >> Paul Durrant writes ("[PATCH v4 7/7] xl: allow domid to be preserved on
> >> save/restore or migrate"):
> >>> This patch adds a '-D' command line option to save and migrate to allow
> >>> the domain id to be incorporated into the saved domain configuration and
> >>> hence be preserved.
> >> Thanks.
> >>
> >> In response to v3 6/6 I wrote:
> >>
> >> I wonder if this should be done more in libxl. Should this be a
> >> domain property ? Wei, Anthony ?
> >>
> >> This question remains unanswered. I'm sorry that neither Wei nor
> >> Anthony had a chance to answer yet...
> >>
> >> Paul, do you have a reason for doing it this way ? My inclination is
> >> that think doing it at the libxl layer would make more sense. Do you
> >> think that would be possible ?
> >>
> > I'm not sure how it would work at the libxl level as the domid is
> > part of create_info and that it transferred by xl on migration. IIUC
> > we'd need a new libxl save record to transfer it at that level, and
> > then I'm not sure whether we'd hit an ordering problem as we'd have
> > to dig that save record out before we could actually create the
> > domain.
>
> There is definitely an ordering problem.
>
> I agree that it should logically be part of the libxl level of the
> stream, but none of that is even parsed until after the domain has been
> created on the destination side.
>
> I have no idea how easy/difficult it would be to rearrange libxl to
> start parsing the migration stream before creating the domain. I think
> there will be a lot of code relying on the domid already being valid.
This.
The other way I can think of is to specify something (domid policy??) in
create_info and apply it during domain creation. But that reeks like a
layering violation to me.
Wei.
>
> ~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [Xen-devel] [PATCH v4 7/7] xl: allow domid to be preserved on save/restore or migrate
2020-01-31 16:07 ` Wei Liu
@ 2020-02-01 11:56 ` Durrant, Paul
2020-02-21 11:58 ` Wei Liu
0 siblings, 1 reply; 29+ messages in thread
From: Durrant, Paul @ 2020-02-01 11:56 UTC (permalink / raw)
To: Wei Liu, Andrew Cooper; +Cc: Anthony Perard, Ian Jackson, xen-devel
> -----Original Message-----
> From: Wei Liu <wl@xen.org>
> Sent: 31 January 2020 16:08
> To: Andrew Cooper <andrew.cooper3@citrix.com>
> Cc: Durrant, Paul <pdurrant@amazon.co.uk>; Ian Jackson
> <ian.jackson@citrix.com>; Anthony Perard <anthony.perard@citrix.com>; xen-
> devel@lists.xenproject.org; Wei Liu <wl@xen.org>
> Subject: Re: [Xen-devel] [PATCH v4 7/7] xl: allow domid to be preserved on
> save/restore or migrate
>
> On Thu, Jan 30, 2020 at 06:20:08PM +0000, Andrew Cooper wrote:
> > On 30/01/2020 17:42, Durrant, Paul wrote:
> > >> -----Original Message-----
> > >> From: Ian Jackson <ian.jackson@citrix.com>
> > >> Sent: 30 January 2020 17:29
> > >> To: Durrant, Paul <pdurrant@amazon.co.uk>
> > >> Cc: xen-devel@lists.xenproject.org; Wei Liu <wl@xen.org>; Anthony
> Perard
> > >> <anthony.perard@citrix.com>
> > >> Subject: Re: [PATCH v4 7/7] xl: allow domid to be preserved on
> > >> save/restore or migrate
> > >>
> > >> Paul Durrant writes ("[PATCH v4 7/7] xl: allow domid to be preserved
> on
> > >> save/restore or migrate"):
> > >>> This patch adds a '-D' command line option to save and migrate to
> allow
> > >>> the domain id to be incorporated into the saved domain configuration
> and
> > >>> hence be preserved.
> > >> Thanks.
> > >>
> > >> In response to v3 6/6 I wrote:
> > >>
> > >> I wonder if this should be done more in libxl. Should this be a
> > >> domain property ? Wei, Anthony ?
> > >>
> > >> This question remains unanswered. I'm sorry that neither Wei nor
> > >> Anthony had a chance to answer yet...
> > >>
> > >> Paul, do you have a reason for doing it this way ? My inclination is
> > >> that think doing it at the libxl layer would make more sense. Do you
> > >> think that would be possible ?
> > >>
> > > I'm not sure how it would work at the libxl level as the domid is
> > > part of create_info and that it transferred by xl on migration. IIUC
> > > we'd need a new libxl save record to transfer it at that level, and
> > > then I'm not sure whether we'd hit an ordering problem as we'd have
> > > to dig that save record out before we could actually create the
> > > domain.
> >
> > There is definitely an ordering problem.
> >
> > I agree that it should logically be part of the libxl level of the
> > stream, but none of that is even parsed until after the domain has been
> > created on the destination side.
> >
> > I have no idea how easy/difficult it would be to rearrange libxl to
> > start parsing the migration stream before creating the domain. I think
> > there will be a lot of code relying on the domid already being valid.
>
> This.
>
> The other way I can think of is to specify something (domid policy??) in
> create_info and apply it during domain creation. But that reeks like a
> layering violation to me.
>
That's basically what this series does, but I don't see it as a layering violation. It has always been the case that xl is in control of the domain creation and then passes the migration stream into libxl. Passing in a 'domid policy' (specific value, 'random', or 'allocated by Xen') as part of create_info, and not messing with the libxl migration data, seems like the right approach to me... which is why I've done it that way.
Paul
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [Xen-devel] [PATCH v4 7/7] xl: allow domid to be preserved on save/restore or migrate
2020-02-01 11:56 ` Durrant, Paul
@ 2020-02-21 11:58 ` Wei Liu
0 siblings, 0 replies; 29+ messages in thread
From: Wei Liu @ 2020-02-21 11:58 UTC (permalink / raw)
To: Durrant, Paul
Cc: Anthony Perard, Andrew Cooper, xen-devel, Wei Liu, Ian Jackson
On Sat, Feb 01, 2020 at 11:56:19AM +0000, Durrant, Paul wrote:
> > -----Original Message-----
> > From: Wei Liu <wl@xen.org>
> > Sent: 31 January 2020 16:08
> > To: Andrew Cooper <andrew.cooper3@citrix.com>
> > Cc: Durrant, Paul <pdurrant@amazon.co.uk>; Ian Jackson
> > <ian.jackson@citrix.com>; Anthony Perard <anthony.perard@citrix.com>; xen-
> > devel@lists.xenproject.org; Wei Liu <wl@xen.org>
> > Subject: Re: [Xen-devel] [PATCH v4 7/7] xl: allow domid to be preserved on
> > save/restore or migrate
> >
> > On Thu, Jan 30, 2020 at 06:20:08PM +0000, Andrew Cooper wrote:
> > > On 30/01/2020 17:42, Durrant, Paul wrote:
> > > >> -----Original Message-----
> > > >> From: Ian Jackson <ian.jackson@citrix.com>
> > > >> Sent: 30 January 2020 17:29
> > > >> To: Durrant, Paul <pdurrant@amazon.co.uk>
> > > >> Cc: xen-devel@lists.xenproject.org; Wei Liu <wl@xen.org>; Anthony
> > Perard
> > > >> <anthony.perard@citrix.com>
> > > >> Subject: Re: [PATCH v4 7/7] xl: allow domid to be preserved on
> > > >> save/restore or migrate
> > > >>
> > > >> Paul Durrant writes ("[PATCH v4 7/7] xl: allow domid to be preserved
> > on
> > > >> save/restore or migrate"):
> > > >>> This patch adds a '-D' command line option to save and migrate to
> > allow
> > > >>> the domain id to be incorporated into the saved domain configuration
> > and
> > > >>> hence be preserved.
> > > >> Thanks.
> > > >>
> > > >> In response to v3 6/6 I wrote:
> > > >>
> > > >> I wonder if this should be done more in libxl. Should this be a
> > > >> domain property ? Wei, Anthony ?
> > > >>
> > > >> This question remains unanswered. I'm sorry that neither Wei nor
> > > >> Anthony had a chance to answer yet...
> > > >>
> > > >> Paul, do you have a reason for doing it this way ? My inclination is
> > > >> that think doing it at the libxl layer would make more sense. Do you
> > > >> think that would be possible ?
> > > >>
> > > > I'm not sure how it would work at the libxl level as the domid is
> > > > part of create_info and that it transferred by xl on migration. IIUC
> > > > we'd need a new libxl save record to transfer it at that level, and
> > > > then I'm not sure whether we'd hit an ordering problem as we'd have
> > > > to dig that save record out before we could actually create the
> > > > domain.
> > >
> > > There is definitely an ordering problem.
> > >
> > > I agree that it should logically be part of the libxl level of the
> > > stream, but none of that is even parsed until after the domain has been
> > > created on the destination side.
> > >
> > > I have no idea how easy/difficult it would be to rearrange libxl to
> > > start parsing the migration stream before creating the domain. I think
> > > there will be a lot of code relying on the domid already being valid.
> >
> > This.
> >
> > The other way I can think of is to specify something (domid policy??) in
> > create_info and apply it during domain creation. But that reeks like a
> > layering violation to me.
> >
>
> That's basically what this series does, but I don't see it as a
> layering violation. It has always been the case that xl is in control
> of the domain creation and then passes the migration stream into
> libxl. Passing in a 'domid policy' (specific value, 'random', or
> 'allocated by Xen') as part of create_info, and not messing with the
> libxl migration data, seems like the right approach to me... which is
> why I've done it that way.
Going through the code more carefully I think your implementation should
be fine.
Wei.
>
> Paul
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 29+ messages in thread