Function xsm_getdomaininfo() is only invoked in XEN_DOMCTL_getdomaininfo
domctl-op, and it shall be wrapped with CONFIG_MGMT_HYPERCALLS
Signed-off-by: Penny Zheng <Penny.Zheng@amd.com>
---
v1 -> v2:
- adapt to changes of "unify DOMCTL to MGMT_HYPERCALLS"
---
xen/include/xsm/xsm.h | 6 +++++-
xen/xsm/dummy.c | 2 +-
xen/xsm/flask/hooks.c | 4 ++--
3 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 678cb0f346..2a107b2cde 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -55,8 +55,8 @@ struct xsm_ops {
void (*security_domaininfo)(struct domain *d,
struct xen_domctl_getdomaininfo *info);
int (*domain_create)(struct domain *d, uint32_t ssidref);
- int (*getdomaininfo)(struct domain *d);
#ifdef CONFIG_MGMT_HYPERCALLS
+ int (*getdomaininfo)(struct domain *d);
int (*domctl_scheduler_op)(struct domain *d, int op);
int (*sysctl_scheduler_op)(int op);
int (*set_target)(struct domain *d, struct domain *e);
@@ -234,7 +234,11 @@ static inline int xsm_domain_create(
static inline int xsm_getdomaininfo(xsm_default_t def, struct domain *d)
{
+#ifdef CONFIG_MGMT_HYPERCALLS
return alternative_call(xsm_ops.getdomaininfo, d);
+#else
+ return -EOPNOTSUPP;
+#endif
}
static inline int xsm_get_domain_state(xsm_default_t def, struct domain *d)
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index f6986dd2bb..7c4e6176aa 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -17,8 +17,8 @@ static const struct xsm_ops __initconst_cf_clobber dummy_ops = {
.set_system_active = xsm_set_system_active,
.security_domaininfo = xsm_security_domaininfo,
.domain_create = xsm_domain_create,
- .getdomaininfo = xsm_getdomaininfo,
#ifdef CONFIG_MGMT_HYPERCALLS
+ .getdomaininfo = xsm_getdomaininfo,
.domctl_scheduler_op = xsm_domctl_scheduler_op,
.sysctl_scheduler_op = xsm_sysctl_scheduler_op,
.set_target = xsm_set_target,
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index ed4e466302..7392e95e55 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -604,12 +604,12 @@ static int cf_check flask_domain_create(struct domain *d, uint32_t ssidref)
return rc;
}
+#ifdef CONFIG_MGMT_HYPERCALLS
static int cf_check flask_getdomaininfo(struct domain *d)
{
return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__GETDOMAININFO);
}
-#ifdef CONFIG_MGMT_HYPERCALLS
static int cf_check flask_domctl_scheduler_op(struct domain *d, int op)
{
switch ( op )
@@ -1889,8 +1889,8 @@ static const struct xsm_ops __initconst_cf_clobber flask_ops = {
.set_system_active = flask_set_system_active,
.security_domaininfo = flask_security_domaininfo,
.domain_create = flask_domain_create,
- .getdomaininfo = flask_getdomaininfo,
#ifdef CONFIG_MGMT_HYPERCALLS
+ .getdomaininfo = flask_getdomaininfo,
.domctl_scheduler_op = flask_domctl_scheduler_op,
.sysctl_scheduler_op = flask_sysctl_scheduler_op,
.set_target = flask_set_target,
--
2.34.1On 10.09.2025 09:38, Penny Zheng wrote:
> --- a/xen/include/xsm/xsm.h
> +++ b/xen/include/xsm/xsm.h
> @@ -55,8 +55,8 @@ struct xsm_ops {
> void (*security_domaininfo)(struct domain *d,
> struct xen_domctl_getdomaininfo *info);
> int (*domain_create)(struct domain *d, uint32_t ssidref);
> - int (*getdomaininfo)(struct domain *d);
> #ifdef CONFIG_MGMT_HYPERCALLS
> + int (*getdomaininfo)(struct domain *d);
> int (*domctl_scheduler_op)(struct domain *d, int op);
> int (*sysctl_scheduler_op)(int op);
> int (*set_target)(struct domain *d, struct domain *e);
> @@ -234,7 +234,11 @@ static inline int xsm_domain_create(
>
> static inline int xsm_getdomaininfo(xsm_default_t def, struct domain *d)
> {
> +#ifdef CONFIG_MGMT_HYPERCALLS
> return alternative_call(xsm_ops.getdomaininfo, d);
> +#else
> + return -EOPNOTSUPP;
> +#endif
> }
This is in use by a Xenstore sysctl and a Xenstore domctl. The sysctl is
hence already broken with the earlier series. Now the domctl is also being
screwed up. I don't think MGMT_HYPERCALLS really ought to extend to any
operations available to other than the core toolstack. That's the Xenstore
ones here, but also the ones used by qemu (whether run in Dom0 or a stubdom).
IOW I think there's a conceptual issue with this work which needs resolving
first.
Jan
[Public]
> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Thursday, September 11, 2025 9:30 PM
> To: Penny, Zheng <penny.zheng@amd.com>
> Cc: Huang, Ray <Ray.Huang@amd.com>; Daniel P. Smith
> <dpsmith@apertussolutions.com>; xen-devel@lists.xenproject.org
> Subject: Re: [PATCH v2 18/26] xen/domctl: wrap xsm_getdomaininfo() with
> CONFIG_MGMT_HYPERCALLS
>
> On 10.09.2025 09:38, Penny Zheng wrote:
> > --- a/xen/include/xsm/xsm.h
> > +++ b/xen/include/xsm/xsm.h
> > @@ -55,8 +55,8 @@ struct xsm_ops {
> > void (*security_domaininfo)(struct domain *d,
> > struct xen_domctl_getdomaininfo *info);
> > int (*domain_create)(struct domain *d, uint32_t ssidref);
> > - int (*getdomaininfo)(struct domain *d);
> > #ifdef CONFIG_MGMT_HYPERCALLS
> > + int (*getdomaininfo)(struct domain *d);
> > int (*domctl_scheduler_op)(struct domain *d, int op);
> > int (*sysctl_scheduler_op)(int op);
> > int (*set_target)(struct domain *d, struct domain *e); @@ -234,7
> > +234,11 @@ static inline int xsm_domain_create(
> >
> > static inline int xsm_getdomaininfo(xsm_default_t def, struct domain
> > *d) {
> > +#ifdef CONFIG_MGMT_HYPERCALLS
> > return alternative_call(xsm_ops.getdomaininfo, d);
> > +#else
> > + return -EOPNOTSUPP;
> > +#endif
> > }
>
> This is in use by a Xenstore sysctl and a Xenstore domctl. The sysctl is hence
> already broken with the earlier series. Now the domctl is also being screwed up. I
> don't think MGMT_HYPERCALLS really ought to extend to any operations available
> to other than the core toolstack. That's the Xenstore ones here, but also the ones
> used by qemu (whether run in Dom0 or a stubdom).
Maybe not only limited to the core toolstack. In dom0less/hyperlaunched scenarios, hypercalls are strictly limited. QEMU is also limited to pvh machine type and with very restricted functionality(, only acting as a few virtio-pci devices backend). @Andryuk, Jason @Stabellini, Stefano Am I understanding correctly and thoroughly about our scenario here for upstream?
Tracking the codes, if Xenstore is created as a stub domain, it requires getdomaininfo-domctl to acquire related info. Sorry, I haven't found how it was called in QEMU...
> IOW I think there's a conceptual issue with this work which needs resolving first.
>
> Jan
On 25.09.2025 11:41, Penny, Zheng wrote:
> [Public]
>
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: Thursday, September 11, 2025 9:30 PM
>> To: Penny, Zheng <penny.zheng@amd.com>
>> Cc: Huang, Ray <Ray.Huang@amd.com>; Daniel P. Smith
>> <dpsmith@apertussolutions.com>; xen-devel@lists.xenproject.org
>> Subject: Re: [PATCH v2 18/26] xen/domctl: wrap xsm_getdomaininfo() with
>> CONFIG_MGMT_HYPERCALLS
>>
>> On 10.09.2025 09:38, Penny Zheng wrote:
>>> --- a/xen/include/xsm/xsm.h
>>> +++ b/xen/include/xsm/xsm.h
>>> @@ -55,8 +55,8 @@ struct xsm_ops {
>>> void (*security_domaininfo)(struct domain *d,
>>> struct xen_domctl_getdomaininfo *info);
>>> int (*domain_create)(struct domain *d, uint32_t ssidref);
>>> - int (*getdomaininfo)(struct domain *d);
>>> #ifdef CONFIG_MGMT_HYPERCALLS
>>> + int (*getdomaininfo)(struct domain *d);
>>> int (*domctl_scheduler_op)(struct domain *d, int op);
>>> int (*sysctl_scheduler_op)(int op);
>>> int (*set_target)(struct domain *d, struct domain *e); @@ -234,7
>>> +234,11 @@ static inline int xsm_domain_create(
>>>
>>> static inline int xsm_getdomaininfo(xsm_default_t def, struct domain
>>> *d) {
>>> +#ifdef CONFIG_MGMT_HYPERCALLS
>>> return alternative_call(xsm_ops.getdomaininfo, d);
>>> +#else
>>> + return -EOPNOTSUPP;
>>> +#endif
>>> }
>>
>> This is in use by a Xenstore sysctl and a Xenstore domctl. The sysctl is hence
>> already broken with the earlier series. Now the domctl is also being screwed up. I
>> don't think MGMT_HYPERCALLS really ought to extend to any operations available
>> to other than the core toolstack. That's the Xenstore ones here, but also the ones
>> used by qemu (whether run in Dom0 or a stubdom).
>
> Maybe not only limited to the core toolstack. In dom0less/hyperlaunched scenarios, hypercalls are strictly limited. QEMU is also limited to pvh machine type and with very restricted functionality(, only acting as a few virtio-pci devices backend). @Andryuk, Jason @Stabellini, Stefano Am I understanding correctly and thoroughly about our scenario here for upstream?
> Tracking the codes, if Xenstore is created as a stub domain, it requires getdomaininfo-domctl to acquire related info. Sorry, I haven't found how it was called in QEMU...
It's not "it"; it's different ones. First and foremost I was thinking of
* XEN_DOMCTL_ioport_mapping
* XEN_DOMCTL_memory_mapping
* XEN_DOMCTL_bind_pt_irq
* XEN_DOMCTL_unbind_pt_irq
but there may be others (albeit per the dummy xsm_domctl() this is the full
set). As a general criteria, anything using XSM_DM_PRIV checking can in
principle be called by qemu.
Jan
[Public]
> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Thursday, September 25, 2025 10:29 PM
> To: Penny, Zheng <penny.zheng@amd.com>
> Cc: Huang, Ray <Ray.Huang@amd.com>; Daniel P. Smith
> <dpsmith@apertussolutions.com>; xen-devel@lists.xenproject.org; Andryuk, Jason
> <Jason.Andryuk@amd.com>; Stabellini, Stefano <stefano.stabellini@amd.com>
> Subject: Re: [PATCH v2 18/26] xen/domctl: wrap xsm_getdomaininfo() with
> CONFIG_MGMT_HYPERCALLS
>
> On 25.09.2025 11:41, Penny, Zheng wrote:
> > [Public]
> >
> >> -----Original Message-----
> >> From: Jan Beulich <jbeulich@suse.com>
> >> Sent: Thursday, September 11, 2025 9:30 PM
> >> To: Penny, Zheng <penny.zheng@amd.com>
> >> Cc: Huang, Ray <Ray.Huang@amd.com>; Daniel P. Smith
> >> <dpsmith@apertussolutions.com>; xen-devel@lists.xenproject.org
> >> Subject: Re: [PATCH v2 18/26] xen/domctl: wrap xsm_getdomaininfo()
> >> with CONFIG_MGMT_HYPERCALLS
> >>
> >> On 10.09.2025 09:38, Penny Zheng wrote:
> >>> --- a/xen/include/xsm/xsm.h
> >>> +++ b/xen/include/xsm/xsm.h
> >>> @@ -55,8 +55,8 @@ struct xsm_ops {
> >>> void (*security_domaininfo)(struct domain *d,
> >>> struct xen_domctl_getdomaininfo *info);
> >>> int (*domain_create)(struct domain *d, uint32_t ssidref);
> >>> - int (*getdomaininfo)(struct domain *d);
> >>> #ifdef CONFIG_MGMT_HYPERCALLS
> >>> + int (*getdomaininfo)(struct domain *d);
> >>> int (*domctl_scheduler_op)(struct domain *d, int op);
> >>> int (*sysctl_scheduler_op)(int op);
> >>> int (*set_target)(struct domain *d, struct domain *e); @@
> >>> -234,7
> >>> +234,11 @@ static inline int xsm_domain_create(
> >>>
> >>> static inline int xsm_getdomaininfo(xsm_default_t def, struct
> >>> domain
> >>> *d) {
> >>> +#ifdef CONFIG_MGMT_HYPERCALLS
> >>> return alternative_call(xsm_ops.getdomaininfo, d);
> >>> +#else
> >>> + return -EOPNOTSUPP;
> >>> +#endif
> >>> }
> >>
> >> This is in use by a Xenstore sysctl and a Xenstore domctl. The sysctl
> >> is hence already broken with the earlier series. Now the domctl is
> >> also being screwed up. I don't think MGMT_HYPERCALLS really ought to
> >> extend to any operations available to other than the core toolstack.
> >> That's the Xenstore ones here, but also the ones used by qemu (whether run in
> Dom0 or a stubdom).
> >
> > Maybe not only limited to the core toolstack. In dom0less/hyperlaunched
> scenarios, hypercalls are strictly limited. QEMU is also limited to pvh machine type
> and with very restricted functionality(, only acting as a few virtio-pci devices
> backend). @Andryuk, Jason @Stabellini, Stefano Am I understanding correctly and
> thoroughly about our scenario here for upstream?
> > Tracking the codes, if Xenstore is created as a stub domain, it requires
> getdomaininfo-domctl to acquire related info. Sorry, I haven't found how it was
> called in QEMU...
>
> It's not "it"; it's different ones. First and foremost I was thinking of
> * XEN_DOMCTL_ioport_mapping
> * XEN_DOMCTL_memory_mapping
> * XEN_DOMCTL_bind_pt_irq
> * XEN_DOMCTL_unbind_pt_irq
> but there may be others (albeit per the dummy xsm_domctl() this is the full set). As
> a general criteria, anything using XSM_DM_PRIV checking can in principle be
> called by qemu.
>
Understood.
I assume that they are all for device passthrough. We are not accepting device passthrough via core toolstack in dom0less/hyperlaunch-ed scenarios. Jason has developed device passthrough through device tree to only accept "static configured" passthrough in dom0less/hyperlaunch-ed scenario, while it is still internal , it may be the only accept way to do device passthrough in dom0less/hyperlaunch-ed scenario.
The major role of QEMU in dom0less/hyperlaunch-ed scenario is to provide limited virtio-pci devices backend. So we need hypercalls majorly involving ioreq server, event channel, virtual interrupt injection and foreign memory mapping, which shall not use XSM_DM_PRIV(xsm_iomem_permission()/xsm_irq_permission()/xsm_iomem_mapping()) checking, I assume.
> Jan
On 26.09.2025 06:41, Penny, Zheng wrote:
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: Thursday, September 25, 2025 10:29 PM
>>
>> On 25.09.2025 11:41, Penny, Zheng wrote:
>>>> -----Original Message-----
>>>> From: Jan Beulich <jbeulich@suse.com>
>>>> Sent: Thursday, September 11, 2025 9:30 PM
>>>>
>>>> On 10.09.2025 09:38, Penny Zheng wrote:
>>>>> --- a/xen/include/xsm/xsm.h
>>>>> +++ b/xen/include/xsm/xsm.h
>>>>> @@ -55,8 +55,8 @@ struct xsm_ops {
>>>>> void (*security_domaininfo)(struct domain *d,
>>>>> struct xen_domctl_getdomaininfo *info);
>>>>> int (*domain_create)(struct domain *d, uint32_t ssidref);
>>>>> - int (*getdomaininfo)(struct domain *d);
>>>>> #ifdef CONFIG_MGMT_HYPERCALLS
>>>>> + int (*getdomaininfo)(struct domain *d);
>>>>> int (*domctl_scheduler_op)(struct domain *d, int op);
>>>>> int (*sysctl_scheduler_op)(int op);
>>>>> int (*set_target)(struct domain *d, struct domain *e); @@
>>>>> -234,7
>>>>> +234,11 @@ static inline int xsm_domain_create(
>>>>>
>>>>> static inline int xsm_getdomaininfo(xsm_default_t def, struct
>>>>> domain
>>>>> *d) {
>>>>> +#ifdef CONFIG_MGMT_HYPERCALLS
>>>>> return alternative_call(xsm_ops.getdomaininfo, d);
>>>>> +#else
>>>>> + return -EOPNOTSUPP;
>>>>> +#endif
>>>>> }
>>>>
>>>> This is in use by a Xenstore sysctl and a Xenstore domctl. The sysctl
>>>> is hence already broken with the earlier series. Now the domctl is
>>>> also being screwed up. I don't think MGMT_HYPERCALLS really ought to
>>>> extend to any operations available to other than the core toolstack.
>>>> That's the Xenstore ones here, but also the ones used by qemu (whether run in
>> Dom0 or a stubdom).
>>>
>>> Maybe not only limited to the core toolstack. In dom0less/hyperlaunched
>> scenarios, hypercalls are strictly limited. QEMU is also limited to pvh machine type
>> and with very restricted functionality(, only acting as a few virtio-pci devices
>> backend). @Andryuk, Jason @Stabellini, Stefano Am I understanding correctly and
>> thoroughly about our scenario here for upstream?
>>> Tracking the codes, if Xenstore is created as a stub domain, it requires
>> getdomaininfo-domctl to acquire related info. Sorry, I haven't found how it was
>> called in QEMU...
>>
>> It's not "it"; it's different ones. First and foremost I was thinking of
>> * XEN_DOMCTL_ioport_mapping
>> * XEN_DOMCTL_memory_mapping
>> * XEN_DOMCTL_bind_pt_irq
>> * XEN_DOMCTL_unbind_pt_irq
>> but there may be others (albeit per the dummy xsm_domctl() this is the full set). As
>> a general criteria, anything using XSM_DM_PRIV checking can in principle be
>> called by qemu.
>>
>
> Understood.
> I assume that they are all for device passthrough. We are not accepting device passthrough via core toolstack in dom0less/hyperlaunch-ed scenarios. Jason has developed device passthrough through device tree to only accept "static configured" passthrough in dom0less/hyperlaunch-ed scenario, while it is still internal , it may be the only accept way to do device passthrough in dom0less/hyperlaunch-ed scenario.
Right, but no matter what your goals, the upstream contributions need to be self-
consistent. I.e. not (risk to) break other functionality. (Really the four domctl-s
mentioned above might better have been put elsewhere, e.g. as dm-ops. Moving them
may be an option here.)
Jan
[Public]
> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Friday, September 26, 2025 2:53 PM
> To: Penny, Zheng <penny.zheng@amd.com>
> Cc: Huang, Ray <Ray.Huang@amd.com>; Daniel P. Smith
> <dpsmith@apertussolutions.com>; xen-devel@lists.xenproject.org; Stabellini,
> Stefano <stefano.stabellini@amd.com>; Andryuk, Jason
> <Jason.Andryuk@amd.com>
> Subject: Re: [PATCH v2 18/26] xen/domctl: wrap xsm_getdomaininfo() with
> CONFIG_MGMT_HYPERCALLS
>
> On 26.09.2025 06:41, Penny, Zheng wrote:
> >> -----Original Message-----
> >> From: Jan Beulich <jbeulich@suse.com>
> >> Sent: Thursday, September 25, 2025 10:29 PM
> >>
> >> On 25.09.2025 11:41, Penny, Zheng wrote:
> >>>> -----Original Message-----
> >>>> From: Jan Beulich <jbeulich@suse.com>
> >>>> Sent: Thursday, September 11, 2025 9:30 PM
> >>>>
> >>>> On 10.09.2025 09:38, Penny Zheng wrote:
> >>>>> --- a/xen/include/xsm/xsm.h
> >>>>> +++ b/xen/include/xsm/xsm.h
> >>>>> @@ -55,8 +55,8 @@ struct xsm_ops {
> >>>>> void (*security_domaininfo)(struct domain *d,
> >>>>> struct xen_domctl_getdomaininfo *info);
> >>>>> int (*domain_create)(struct domain *d, uint32_t ssidref);
> >>>>> - int (*getdomaininfo)(struct domain *d);
> >>>>> #ifdef CONFIG_MGMT_HYPERCALLS
> >>>>> + int (*getdomaininfo)(struct domain *d);
> >>>>> int (*domctl_scheduler_op)(struct domain *d, int op);
> >>>>> int (*sysctl_scheduler_op)(int op);
> >>>>> int (*set_target)(struct domain *d, struct domain *e); @@
> >>>>> -234,7
> >>>>> +234,11 @@ static inline int xsm_domain_create(
> >>>>>
> >>>>> static inline int xsm_getdomaininfo(xsm_default_t def, struct
> >>>>> domain
> >>>>> *d) {
> >>>>> +#ifdef CONFIG_MGMT_HYPERCALLS
> >>>>> return alternative_call(xsm_ops.getdomaininfo, d);
> >>>>> +#else
> >>>>> + return -EOPNOTSUPP;
> >>>>> +#endif
> >>>>> }
> >>>>
> >>>> This is in use by a Xenstore sysctl and a Xenstore domctl. The
> >>>> sysctl is hence already broken with the earlier series. Now the
> >>>> domctl is also being screwed up. I don't think MGMT_HYPERCALLS
> >>>> really ought to extend to any operations available to other than the core
> toolstack.
> >>>> That's the Xenstore ones here, but also the ones used by qemu
> >>>> (whether run in
> >> Dom0 or a stubdom).
> >>>
> >>> Maybe not only limited to the core toolstack. In
> >>> dom0less/hyperlaunched
> >> scenarios, hypercalls are strictly limited. QEMU is also limited to
> >> pvh machine type and with very restricted functionality(, only acting
> >> as a few virtio-pci devices backend). @Andryuk, Jason @Stabellini,
> >> Stefano Am I understanding correctly and thoroughly about our scenario here for
> upstream?
> >>> Tracking the codes, if Xenstore is created as a stub domain, it
> >>> requires
> >> getdomaininfo-domctl to acquire related info. Sorry, I haven't found
> >> how it was called in QEMU...
> >>
> >> It's not "it"; it's different ones. First and foremost I was thinking
> >> of
> >> * XEN_DOMCTL_ioport_mapping
> >> * XEN_DOMCTL_memory_mapping
> >> * XEN_DOMCTL_bind_pt_irq
> >> * XEN_DOMCTL_unbind_pt_irq
> >> but there may be others (albeit per the dummy xsm_domctl() this is
> >> the full set). As a general criteria, anything using XSM_DM_PRIV
> >> checking can in principle be called by qemu.
> >>
> >
> > Understood.
> > I assume that they are all for device passthrough. We are not accepting device
> passthrough via core toolstack in dom0less/hyperlaunch-ed scenarios. Jason has
> developed device passthrough through device tree to only accept "static
> configured" passthrough in dom0less/hyperlaunch-ed scenario, while it is still
> internal , it may be the only accept way to do device passthrough in
> dom0less/hyperlaunch-ed scenario.
>
> Right, but no matter what your goals, the upstream contributions need to be self-
> consistent. I.e. not (risk to) break other functionality. (Really the four domctl-s
> mentioned above might better have been put elsewhere, e.g. as dm-ops. Moving
> them may be an option here.)
Understood.
I'll move them all to the dm-ops
>
> Jan
On Thu, 25 Sep 2025, Penny, Zheng wrote:
> > -----Original Message-----
> > From: Jan Beulich <jbeulich@suse.com>
> > Sent: Friday, September 26, 2025 2:53 PM
> > To: Penny, Zheng <penny.zheng@amd.com>
> > Cc: Huang, Ray <Ray.Huang@amd.com>; Daniel P. Smith
> > <dpsmith@apertussolutions.com>; xen-devel@lists.xenproject.org; Stabellini,
> > Stefano <stefano.stabellini@amd.com>; Andryuk, Jason
> > <Jason.Andryuk@amd.com>
> > Subject: Re: [PATCH v2 18/26] xen/domctl: wrap xsm_getdomaininfo() with
> > CONFIG_MGMT_HYPERCALLS
> >
> > On 26.09.2025 06:41, Penny, Zheng wrote:
> > >> -----Original Message-----
> > >> From: Jan Beulich <jbeulich@suse.com>
> > >> Sent: Thursday, September 25, 2025 10:29 PM
> > >>
> > >> On 25.09.2025 11:41, Penny, Zheng wrote:
> > >>>> -----Original Message-----
> > >>>> From: Jan Beulich <jbeulich@suse.com>
> > >>>> Sent: Thursday, September 11, 2025 9:30 PM
> > >>>>
> > >>>> On 10.09.2025 09:38, Penny Zheng wrote:
> > >>>>> --- a/xen/include/xsm/xsm.h
> > >>>>> +++ b/xen/include/xsm/xsm.h
> > >>>>> @@ -55,8 +55,8 @@ struct xsm_ops {
> > >>>>> void (*security_domaininfo)(struct domain *d,
> > >>>>> struct xen_domctl_getdomaininfo *info);
> > >>>>> int (*domain_create)(struct domain *d, uint32_t ssidref);
> > >>>>> - int (*getdomaininfo)(struct domain *d);
> > >>>>> #ifdef CONFIG_MGMT_HYPERCALLS
> > >>>>> + int (*getdomaininfo)(struct domain *d);
> > >>>>> int (*domctl_scheduler_op)(struct domain *d, int op);
> > >>>>> int (*sysctl_scheduler_op)(int op);
> > >>>>> int (*set_target)(struct domain *d, struct domain *e); @@
> > >>>>> -234,7
> > >>>>> +234,11 @@ static inline int xsm_domain_create(
> > >>>>>
> > >>>>> static inline int xsm_getdomaininfo(xsm_default_t def, struct
> > >>>>> domain
> > >>>>> *d) {
> > >>>>> +#ifdef CONFIG_MGMT_HYPERCALLS
> > >>>>> return alternative_call(xsm_ops.getdomaininfo, d);
> > >>>>> +#else
> > >>>>> + return -EOPNOTSUPP;
> > >>>>> +#endif
> > >>>>> }
> > >>>>
> > >>>> This is in use by a Xenstore sysctl and a Xenstore domctl. The
> > >>>> sysctl is hence already broken with the earlier series. Now the
> > >>>> domctl is also being screwed up. I don't think MGMT_HYPERCALLS
> > >>>> really ought to extend to any operations available to other than the core
> > toolstack.
> > >>>> That's the Xenstore ones here, but also the ones used by qemu
> > >>>> (whether run in
> > >> Dom0 or a stubdom).
> > >>>
> > >>> Maybe not only limited to the core toolstack. In
> > >>> dom0less/hyperlaunched
> > >> scenarios, hypercalls are strictly limited. QEMU is also limited to
> > >> pvh machine type and with very restricted functionality(, only acting
> > >> as a few virtio-pci devices backend). @Andryuk, Jason @Stabellini,
> > >> Stefano Am I understanding correctly and thoroughly about our scenario here for
> > upstream?
> > >>> Tracking the codes, if Xenstore is created as a stub domain, it
> > >>> requires
> > >> getdomaininfo-domctl to acquire related info. Sorry, I haven't found
> > >> how it was called in QEMU...
> > >>
> > >> It's not "it"; it's different ones. First and foremost I was thinking
> > >> of
> > >> * XEN_DOMCTL_ioport_mapping
> > >> * XEN_DOMCTL_memory_mapping
> > >> * XEN_DOMCTL_bind_pt_irq
> > >> * XEN_DOMCTL_unbind_pt_irq
> > >> but there may be others (albeit per the dummy xsm_domctl() this is
> > >> the full set). As a general criteria, anything using XSM_DM_PRIV
> > >> checking can in principle be called by qemu.
> > >>
> > >
> > > Understood.
> > > I assume that they are all for device passthrough. We are not accepting device
> > passthrough via core toolstack in dom0less/hyperlaunch-ed scenarios. Jason has
> > developed device passthrough through device tree to only accept "static
> > configured" passthrough in dom0less/hyperlaunch-ed scenario, while it is still
> > internal , it may be the only accept way to do device passthrough in
> > dom0less/hyperlaunch-ed scenario.
> >
> > Right, but no matter what your goals, the upstream contributions need to be self-
> > consistent. I.e. not (risk to) break other functionality. (Really the four domctl-s
> > mentioned above might better have been put elsewhere, e.g. as dm-ops. Moving
> > them may be an option here.)
>
> Understood.
> I'll move them all to the dm-ops
Hi Penny, Jan, I advise against this.
I think it is clear that there are open questions on how to deal with
the safety scenarios. I briefly mentioned some of the issues last week
at Xen Summit. One example is the listdomains hypercall that should be
available to the control domain. We cannot resolve all problems with
this patch series. I think we should follow a simpler plan:
1) introduce CONFIG_MGMT_HYPERCALLS the way this patch series does,
removing all domctls and sysctls
2) make further adjustments, such as making available the listdomains
hypercall and/or the hypercalls listed by Jan as a second step after
it
This is because 1) is already a major improvement that might even be
enough in the simpler deployment scenarios.
So I advise against making this series more complex and instead just
focusing on removing all sysctls and domctls the way it is already
doing. This is regardless of the Xen release schedule.
As it happens, my suggestion would also make it more suitable for 4.21.
At the same time, I realize it is coming later than expected so I
understand if Oleksii and Jan prefer to postpone it after the 4.21
release regardless.
On 26.09.2025 21:24, Stefano Stabellini wrote:
> On Thu, 25 Sep 2025, Penny, Zheng wrote:
>>> -----Original Message-----
>>> From: Jan Beulich <jbeulich@suse.com>
>>> Sent: Friday, September 26, 2025 2:53 PM
>>> To: Penny, Zheng <penny.zheng@amd.com>
>>> Cc: Huang, Ray <Ray.Huang@amd.com>; Daniel P. Smith
>>> <dpsmith@apertussolutions.com>; xen-devel@lists.xenproject.org; Stabellini,
>>> Stefano <stefano.stabellini@amd.com>; Andryuk, Jason
>>> <Jason.Andryuk@amd.com>
>>> Subject: Re: [PATCH v2 18/26] xen/domctl: wrap xsm_getdomaininfo() with
>>> CONFIG_MGMT_HYPERCALLS
>>>
>>> On 26.09.2025 06:41, Penny, Zheng wrote:
>>>>> -----Original Message-----
>>>>> From: Jan Beulich <jbeulich@suse.com>
>>>>> Sent: Thursday, September 25, 2025 10:29 PM
>>>>>
>>>>> On 25.09.2025 11:41, Penny, Zheng wrote:
>>>>>>> -----Original Message-----
>>>>>>> From: Jan Beulich <jbeulich@suse.com>
>>>>>>> Sent: Thursday, September 11, 2025 9:30 PM
>>>>>>>
>>>>>>> On 10.09.2025 09:38, Penny Zheng wrote:
>>>>>>>> --- a/xen/include/xsm/xsm.h
>>>>>>>> +++ b/xen/include/xsm/xsm.h
>>>>>>>> @@ -55,8 +55,8 @@ struct xsm_ops {
>>>>>>>> void (*security_domaininfo)(struct domain *d,
>>>>>>>> struct xen_domctl_getdomaininfo *info);
>>>>>>>> int (*domain_create)(struct domain *d, uint32_t ssidref);
>>>>>>>> - int (*getdomaininfo)(struct domain *d);
>>>>>>>> #ifdef CONFIG_MGMT_HYPERCALLS
>>>>>>>> + int (*getdomaininfo)(struct domain *d);
>>>>>>>> int (*domctl_scheduler_op)(struct domain *d, int op);
>>>>>>>> int (*sysctl_scheduler_op)(int op);
>>>>>>>> int (*set_target)(struct domain *d, struct domain *e); @@
>>>>>>>> -234,7
>>>>>>>> +234,11 @@ static inline int xsm_domain_create(
>>>>>>>>
>>>>>>>> static inline int xsm_getdomaininfo(xsm_default_t def, struct
>>>>>>>> domain
>>>>>>>> *d) {
>>>>>>>> +#ifdef CONFIG_MGMT_HYPERCALLS
>>>>>>>> return alternative_call(xsm_ops.getdomaininfo, d);
>>>>>>>> +#else
>>>>>>>> + return -EOPNOTSUPP;
>>>>>>>> +#endif
>>>>>>>> }
>>>>>>>
>>>>>>> This is in use by a Xenstore sysctl and a Xenstore domctl. The
>>>>>>> sysctl is hence already broken with the earlier series. Now the
>>>>>>> domctl is also being screwed up. I don't think MGMT_HYPERCALLS
>>>>>>> really ought to extend to any operations available to other than the core
>>> toolstack.
>>>>>>> That's the Xenstore ones here, but also the ones used by qemu
>>>>>>> (whether run in
>>>>> Dom0 or a stubdom).
>>>>>>
>>>>>> Maybe not only limited to the core toolstack. In
>>>>>> dom0less/hyperlaunched
>>>>> scenarios, hypercalls are strictly limited. QEMU is also limited to
>>>>> pvh machine type and with very restricted functionality(, only acting
>>>>> as a few virtio-pci devices backend). @Andryuk, Jason @Stabellini,
>>>>> Stefano Am I understanding correctly and thoroughly about our scenario here for
>>> upstream?
>>>>>> Tracking the codes, if Xenstore is created as a stub domain, it
>>>>>> requires
>>>>> getdomaininfo-domctl to acquire related info. Sorry, I haven't found
>>>>> how it was called in QEMU...
>>>>>
>>>>> It's not "it"; it's different ones. First and foremost I was thinking
>>>>> of
>>>>> * XEN_DOMCTL_ioport_mapping
>>>>> * XEN_DOMCTL_memory_mapping
>>>>> * XEN_DOMCTL_bind_pt_irq
>>>>> * XEN_DOMCTL_unbind_pt_irq
>>>>> but there may be others (albeit per the dummy xsm_domctl() this is
>>>>> the full set). As a general criteria, anything using XSM_DM_PRIV
>>>>> checking can in principle be called by qemu.
>>>>>
>>>>
>>>> Understood.
>>>> I assume that they are all for device passthrough. We are not accepting device
>>> passthrough via core toolstack in dom0less/hyperlaunch-ed scenarios. Jason has
>>> developed device passthrough through device tree to only accept "static
>>> configured" passthrough in dom0less/hyperlaunch-ed scenario, while it is still
>>> internal , it may be the only accept way to do device passthrough in
>>> dom0less/hyperlaunch-ed scenario.
>>>
>>> Right, but no matter what your goals, the upstream contributions need to be self-
>>> consistent. I.e. not (risk to) break other functionality. (Really the four domctl-s
>>> mentioned above might better have been put elsewhere, e.g. as dm-ops. Moving
>>> them may be an option here.)
>>
>> Understood.
>> I'll move them all to the dm-ops
>
> Hi Penny, Jan, I advise against this.
>
> I think it is clear that there are open questions on how to deal with
> the safety scenarios. I briefly mentioned some of the issues last week
> at Xen Summit. One example is the listdomains hypercall that should be
> available to the control domain. We cannot resolve all problems with
> this patch series. I think we should follow a simpler plan:
>
> 1) introduce CONFIG_MGMT_HYPERCALLS the way this patch series does,
> removing all domctls and sysctls
>
> 2) make further adjustments, such as making available the listdomains
> hypercall and/or the hypercalls listed by Jan as a second step after
> it
I'm going to be okay-ish with that as long as the help text of the Kconfig
option clearly mentions those extra pitfalls.
Jan
On Sun, 28 Sep 2025, Jan Beulich wrote:
> On 26.09.2025 21:24, Stefano Stabellini wrote:
> > On Thu, 25 Sep 2025, Penny, Zheng wrote:
> >>> -----Original Message-----
> >>> From: Jan Beulich <jbeulich@suse.com>
> >>> Sent: Friday, September 26, 2025 2:53 PM
> >>> To: Penny, Zheng <penny.zheng@amd.com>
> >>> Cc: Huang, Ray <Ray.Huang@amd.com>; Daniel P. Smith
> >>> <dpsmith@apertussolutions.com>; xen-devel@lists.xenproject.org; Stabellini,
> >>> Stefano <stefano.stabellini@amd.com>; Andryuk, Jason
> >>> <Jason.Andryuk@amd.com>
> >>> Subject: Re: [PATCH v2 18/26] xen/domctl: wrap xsm_getdomaininfo() with
> >>> CONFIG_MGMT_HYPERCALLS
> >>>
> >>> On 26.09.2025 06:41, Penny, Zheng wrote:
> >>>>> -----Original Message-----
> >>>>> From: Jan Beulich <jbeulich@suse.com>
> >>>>> Sent: Thursday, September 25, 2025 10:29 PM
> >>>>>
> >>>>> On 25.09.2025 11:41, Penny, Zheng wrote:
> >>>>>>> -----Original Message-----
> >>>>>>> From: Jan Beulich <jbeulich@suse.com>
> >>>>>>> Sent: Thursday, September 11, 2025 9:30 PM
> >>>>>>>
> >>>>>>> On 10.09.2025 09:38, Penny Zheng wrote:
> >>>>>>>> --- a/xen/include/xsm/xsm.h
> >>>>>>>> +++ b/xen/include/xsm/xsm.h
> >>>>>>>> @@ -55,8 +55,8 @@ struct xsm_ops {
> >>>>>>>> void (*security_domaininfo)(struct domain *d,
> >>>>>>>> struct xen_domctl_getdomaininfo *info);
> >>>>>>>> int (*domain_create)(struct domain *d, uint32_t ssidref);
> >>>>>>>> - int (*getdomaininfo)(struct domain *d);
> >>>>>>>> #ifdef CONFIG_MGMT_HYPERCALLS
> >>>>>>>> + int (*getdomaininfo)(struct domain *d);
> >>>>>>>> int (*domctl_scheduler_op)(struct domain *d, int op);
> >>>>>>>> int (*sysctl_scheduler_op)(int op);
> >>>>>>>> int (*set_target)(struct domain *d, struct domain *e); @@
> >>>>>>>> -234,7
> >>>>>>>> +234,11 @@ static inline int xsm_domain_create(
> >>>>>>>>
> >>>>>>>> static inline int xsm_getdomaininfo(xsm_default_t def, struct
> >>>>>>>> domain
> >>>>>>>> *d) {
> >>>>>>>> +#ifdef CONFIG_MGMT_HYPERCALLS
> >>>>>>>> return alternative_call(xsm_ops.getdomaininfo, d);
> >>>>>>>> +#else
> >>>>>>>> + return -EOPNOTSUPP;
> >>>>>>>> +#endif
> >>>>>>>> }
> >>>>>>>
> >>>>>>> This is in use by a Xenstore sysctl and a Xenstore domctl. The
> >>>>>>> sysctl is hence already broken with the earlier series. Now the
> >>>>>>> domctl is also being screwed up. I don't think MGMT_HYPERCALLS
> >>>>>>> really ought to extend to any operations available to other than the core
> >>> toolstack.
> >>>>>>> That's the Xenstore ones here, but also the ones used by qemu
> >>>>>>> (whether run in
> >>>>> Dom0 or a stubdom).
> >>>>>>
> >>>>>> Maybe not only limited to the core toolstack. In
> >>>>>> dom0less/hyperlaunched
> >>>>> scenarios, hypercalls are strictly limited. QEMU is also limited to
> >>>>> pvh machine type and with very restricted functionality(, only acting
> >>>>> as a few virtio-pci devices backend). @Andryuk, Jason @Stabellini,
> >>>>> Stefano Am I understanding correctly and thoroughly about our scenario here for
> >>> upstream?
> >>>>>> Tracking the codes, if Xenstore is created as a stub domain, it
> >>>>>> requires
> >>>>> getdomaininfo-domctl to acquire related info. Sorry, I haven't found
> >>>>> how it was called in QEMU...
> >>>>>
> >>>>> It's not "it"; it's different ones. First and foremost I was thinking
> >>>>> of
> >>>>> * XEN_DOMCTL_ioport_mapping
> >>>>> * XEN_DOMCTL_memory_mapping
> >>>>> * XEN_DOMCTL_bind_pt_irq
> >>>>> * XEN_DOMCTL_unbind_pt_irq
> >>>>> but there may be others (albeit per the dummy xsm_domctl() this is
> >>>>> the full set). As a general criteria, anything using XSM_DM_PRIV
> >>>>> checking can in principle be called by qemu.
> >>>>>
> >>>>
> >>>> Understood.
> >>>> I assume that they are all for device passthrough. We are not accepting device
> >>> passthrough via core toolstack in dom0less/hyperlaunch-ed scenarios. Jason has
> >>> developed device passthrough through device tree to only accept "static
> >>> configured" passthrough in dom0less/hyperlaunch-ed scenario, while it is still
> >>> internal , it may be the only accept way to do device passthrough in
> >>> dom0less/hyperlaunch-ed scenario.
> >>>
> >>> Right, but no matter what your goals, the upstream contributions need to be self-
> >>> consistent. I.e. not (risk to) break other functionality. (Really the four domctl-s
> >>> mentioned above might better have been put elsewhere, e.g. as dm-ops. Moving
> >>> them may be an option here.)
> >>
> >> Understood.
> >> I'll move them all to the dm-ops
> >
> > Hi Penny, Jan, I advise against this.
> >
> > I think it is clear that there are open questions on how to deal with
> > the safety scenarios. I briefly mentioned some of the issues last week
> > at Xen Summit. One example is the listdomains hypercall that should be
> > available to the control domain. We cannot resolve all problems with
> > this patch series. I think we should follow a simpler plan:
> >
> > 1) introduce CONFIG_MGMT_HYPERCALLS the way this patch series does,
> > removing all domctls and sysctls
> >
> > 2) make further adjustments, such as making available the listdomains
> > hypercall and/or the hypercalls listed by Jan as a second step after
> > it
>
> I'm going to be okay-ish with that as long as the help text of the Kconfig
> option clearly mentions those extra pitfalls.
+0
On Mon, 29 Sep 2025, Stefano Stabellini wrote:
> On Sun, 28 Sep 2025, Jan Beulich wrote:
> > On 26.09.2025 21:24, Stefano Stabellini wrote:
> > > On Thu, 25 Sep 2025, Penny, Zheng wrote:
> > >>> -----Original Message-----
> > >>> From: Jan Beulich <jbeulich@suse.com>
> > >>> Sent: Friday, September 26, 2025 2:53 PM
> > >>> To: Penny, Zheng <penny.zheng@amd.com>
> > >>> Cc: Huang, Ray <Ray.Huang@amd.com>; Daniel P. Smith
> > >>> <dpsmith@apertussolutions.com>; xen-devel@lists.xenproject.org; Stabellini,
> > >>> Stefano <stefano.stabellini@amd.com>; Andryuk, Jason
> > >>> <Jason.Andryuk@amd.com>
> > >>> Subject: Re: [PATCH v2 18/26] xen/domctl: wrap xsm_getdomaininfo() with
> > >>> CONFIG_MGMT_HYPERCALLS
> > >>>
> > >>> On 26.09.2025 06:41, Penny, Zheng wrote:
> > >>>>> -----Original Message-----
> > >>>>> From: Jan Beulich <jbeulich@suse.com>
> > >>>>> Sent: Thursday, September 25, 2025 10:29 PM
> > >>>>>
> > >>>>> On 25.09.2025 11:41, Penny, Zheng wrote:
> > >>>>>>> -----Original Message-----
> > >>>>>>> From: Jan Beulich <jbeulich@suse.com>
> > >>>>>>> Sent: Thursday, September 11, 2025 9:30 PM
> > >>>>>>>
> > >>>>>>> On 10.09.2025 09:38, Penny Zheng wrote:
> > >>>>>>>> --- a/xen/include/xsm/xsm.h
> > >>>>>>>> +++ b/xen/include/xsm/xsm.h
> > >>>>>>>> @@ -55,8 +55,8 @@ struct xsm_ops {
> > >>>>>>>> void (*security_domaininfo)(struct domain *d,
> > >>>>>>>> struct xen_domctl_getdomaininfo *info);
> > >>>>>>>> int (*domain_create)(struct domain *d, uint32_t ssidref);
> > >>>>>>>> - int (*getdomaininfo)(struct domain *d);
> > >>>>>>>> #ifdef CONFIG_MGMT_HYPERCALLS
> > >>>>>>>> + int (*getdomaininfo)(struct domain *d);
> > >>>>>>>> int (*domctl_scheduler_op)(struct domain *d, int op);
> > >>>>>>>> int (*sysctl_scheduler_op)(int op);
> > >>>>>>>> int (*set_target)(struct domain *d, struct domain *e); @@
> > >>>>>>>> -234,7
> > >>>>>>>> +234,11 @@ static inline int xsm_domain_create(
> > >>>>>>>>
> > >>>>>>>> static inline int xsm_getdomaininfo(xsm_default_t def, struct
> > >>>>>>>> domain
> > >>>>>>>> *d) {
> > >>>>>>>> +#ifdef CONFIG_MGMT_HYPERCALLS
> > >>>>>>>> return alternative_call(xsm_ops.getdomaininfo, d);
> > >>>>>>>> +#else
> > >>>>>>>> + return -EOPNOTSUPP;
> > >>>>>>>> +#endif
> > >>>>>>>> }
> > >>>>>>>
> > >>>>>>> This is in use by a Xenstore sysctl and a Xenstore domctl. The
> > >>>>>>> sysctl is hence already broken with the earlier series. Now the
> > >>>>>>> domctl is also being screwed up. I don't think MGMT_HYPERCALLS
> > >>>>>>> really ought to extend to any operations available to other than the core
> > >>> toolstack.
> > >>>>>>> That's the Xenstore ones here, but also the ones used by qemu
> > >>>>>>> (whether run in
> > >>>>> Dom0 or a stubdom).
> > >>>>>>
> > >>>>>> Maybe not only limited to the core toolstack. In
> > >>>>>> dom0less/hyperlaunched
> > >>>>> scenarios, hypercalls are strictly limited. QEMU is also limited to
> > >>>>> pvh machine type and with very restricted functionality(, only acting
> > >>>>> as a few virtio-pci devices backend). @Andryuk, Jason @Stabellini,
> > >>>>> Stefano Am I understanding correctly and thoroughly about our scenario here for
> > >>> upstream?
> > >>>>>> Tracking the codes, if Xenstore is created as a stub domain, it
> > >>>>>> requires
> > >>>>> getdomaininfo-domctl to acquire related info. Sorry, I haven't found
> > >>>>> how it was called in QEMU...
> > >>>>>
> > >>>>> It's not "it"; it's different ones. First and foremost I was thinking
> > >>>>> of
> > >>>>> * XEN_DOMCTL_ioport_mapping
> > >>>>> * XEN_DOMCTL_memory_mapping
> > >>>>> * XEN_DOMCTL_bind_pt_irq
> > >>>>> * XEN_DOMCTL_unbind_pt_irq
> > >>>>> but there may be others (albeit per the dummy xsm_domctl() this is
> > >>>>> the full set). As a general criteria, anything using XSM_DM_PRIV
> > >>>>> checking can in principle be called by qemu.
> > >>>>>
> > >>>>
> > >>>> Understood.
> > >>>> I assume that they are all for device passthrough. We are not accepting device
> > >>> passthrough via core toolstack in dom0less/hyperlaunch-ed scenarios. Jason has
> > >>> developed device passthrough through device tree to only accept "static
> > >>> configured" passthrough in dom0less/hyperlaunch-ed scenario, while it is still
> > >>> internal , it may be the only accept way to do device passthrough in
> > >>> dom0less/hyperlaunch-ed scenario.
> > >>>
> > >>> Right, but no matter what your goals, the upstream contributions need to be self-
> > >>> consistent. I.e. not (risk to) break other functionality. (Really the four domctl-s
> > >>> mentioned above might better have been put elsewhere, e.g. as dm-ops. Moving
> > >>> them may be an option here.)
> > >>
> > >> Understood.
> > >> I'll move them all to the dm-ops
> > >
> > > Hi Penny, Jan, I advise against this.
> > >
> > > I think it is clear that there are open questions on how to deal with
> > > the safety scenarios. I briefly mentioned some of the issues last week
> > > at Xen Summit. One example is the listdomains hypercall that should be
> > > available to the control domain. We cannot resolve all problems with
> > > this patch series. I think we should follow a simpler plan:
> > >
> > > 1) introduce CONFIG_MGMT_HYPERCALLS the way this patch series does,
> > > removing all domctls and sysctls
> > >
> > > 2) make further adjustments, such as making available the listdomains
> > > hypercall and/or the hypercalls listed by Jan as a second step after
> > > it
> >
> > I'm going to be okay-ish with that as long as the help text of the Kconfig
> > option clearly mentions those extra pitfalls.
>
> +0
Ahah I mistyped this :-)
I meant +1 in the sense that I am happy with the idea of kconfig clearly
mentioning the pitfalls.
On 26.09.2025 08:57, Penny, Zheng wrote:
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: Friday, September 26, 2025 2:53 PM
>>
>> On 26.09.2025 06:41, Penny, Zheng wrote:
>>>> -----Original Message-----
>>>> From: Jan Beulich <jbeulich@suse.com>
>>>> Sent: Thursday, September 25, 2025 10:29 PM
>>>>
>>>> On 25.09.2025 11:41, Penny, Zheng wrote:
>>>>>> -----Original Message-----
>>>>>> From: Jan Beulich <jbeulich@suse.com>
>>>>>> Sent: Thursday, September 11, 2025 9:30 PM
>>>>>>
>>>>>> On 10.09.2025 09:38, Penny Zheng wrote:
>>>>>>> --- a/xen/include/xsm/xsm.h
>>>>>>> +++ b/xen/include/xsm/xsm.h
>>>>>>> @@ -55,8 +55,8 @@ struct xsm_ops {
>>>>>>> void (*security_domaininfo)(struct domain *d,
>>>>>>> struct xen_domctl_getdomaininfo *info);
>>>>>>> int (*domain_create)(struct domain *d, uint32_t ssidref);
>>>>>>> - int (*getdomaininfo)(struct domain *d);
>>>>>>> #ifdef CONFIG_MGMT_HYPERCALLS
>>>>>>> + int (*getdomaininfo)(struct domain *d);
>>>>>>> int (*domctl_scheduler_op)(struct domain *d, int op);
>>>>>>> int (*sysctl_scheduler_op)(int op);
>>>>>>> int (*set_target)(struct domain *d, struct domain *e); @@
>>>>>>> -234,7
>>>>>>> +234,11 @@ static inline int xsm_domain_create(
>>>>>>>
>>>>>>> static inline int xsm_getdomaininfo(xsm_default_t def, struct
>>>>>>> domain
>>>>>>> *d) {
>>>>>>> +#ifdef CONFIG_MGMT_HYPERCALLS
>>>>>>> return alternative_call(xsm_ops.getdomaininfo, d);
>>>>>>> +#else
>>>>>>> + return -EOPNOTSUPP;
>>>>>>> +#endif
>>>>>>> }
>>>>>>
>>>>>> This is in use by a Xenstore sysctl and a Xenstore domctl. The
>>>>>> sysctl is hence already broken with the earlier series. Now the
>>>>>> domctl is also being screwed up. I don't think MGMT_HYPERCALLS
>>>>>> really ought to extend to any operations available to other than the core
>> toolstack.
>>>>>> That's the Xenstore ones here, but also the ones used by qemu
>>>>>> (whether run in
>>>> Dom0 or a stubdom).
>>>>>
>>>>> Maybe not only limited to the core toolstack. In
>>>>> dom0less/hyperlaunched
>>>> scenarios, hypercalls are strictly limited. QEMU is also limited to
>>>> pvh machine type and with very restricted functionality(, only acting
>>>> as a few virtio-pci devices backend). @Andryuk, Jason @Stabellini,
>>>> Stefano Am I understanding correctly and thoroughly about our scenario here for
>> upstream?
>>>>> Tracking the codes, if Xenstore is created as a stub domain, it
>>>>> requires
>>>> getdomaininfo-domctl to acquire related info. Sorry, I haven't found
>>>> how it was called in QEMU...
>>>>
>>>> It's not "it"; it's different ones. First and foremost I was thinking
>>>> of
>>>> * XEN_DOMCTL_ioport_mapping
>>>> * XEN_DOMCTL_memory_mapping
>>>> * XEN_DOMCTL_bind_pt_irq
>>>> * XEN_DOMCTL_unbind_pt_irq
>>>> but there may be others (albeit per the dummy xsm_domctl() this is
>>>> the full set). As a general criteria, anything using XSM_DM_PRIV
>>>> checking can in principle be called by qemu.
>>>>
>>>
>>> Understood.
>>> I assume that they are all for device passthrough. We are not accepting device
>> passthrough via core toolstack in dom0less/hyperlaunch-ed scenarios. Jason has
>> developed device passthrough through device tree to only accept "static
>> configured" passthrough in dom0less/hyperlaunch-ed scenario, while it is still
>> internal , it may be the only accept way to do device passthrough in
>> dom0less/hyperlaunch-ed scenario.
>>
>> Right, but no matter what your goals, the upstream contributions need to be self-
>> consistent. I.e. not (risk to) break other functionality. (Really the four domctl-s
>> mentioned above might better have been put elsewhere, e.g. as dm-ops. Moving
>> them may be an option here.)
>
> Understood.
> I'll move them all to the dm-ops
Before you do so, please consider the consequences, though (I said "may" for a
reason). Also please allow others to chime in. (In this context I notice that
several REST maintainers weren't even Cc-ed here, and hence may not have seen
the earlier discussion.)
One thing seems pretty clear to me: This work likely isn't going to be suitable
for 4.21 anymore. Hence we're back to considering alternatives to address the
still pending build issue. (My take on it remains: Revert the tail of the
sysctl work.) Adding Oleksii to Cc as well.
Jan
On 9/26/25 9:14 AM, Jan Beulich wrote:
> On 26.09.2025 08:57, Penny, Zheng wrote:
>>> -----Original Message-----
>>> From: Jan Beulich<jbeulich@suse.com>
>>> Sent: Friday, September 26, 2025 2:53 PM
>>>
>>> On 26.09.2025 06:41, Penny, Zheng wrote:
>>>>> -----Original Message-----
>>>>> From: Jan Beulich<jbeulich@suse.com>
>>>>> Sent: Thursday, September 25, 2025 10:29 PM
>>>>>
>>>>> On 25.09.2025 11:41, Penny, Zheng wrote:
>>>>>>> -----Original Message-----
>>>>>>> From: Jan Beulich<jbeulich@suse.com>
>>>>>>> Sent: Thursday, September 11, 2025 9:30 PM
>>>>>>>
>>>>>>> On 10.09.2025 09:38, Penny Zheng wrote:
>>>>>>>> --- a/xen/include/xsm/xsm.h
>>>>>>>> +++ b/xen/include/xsm/xsm.h
>>>>>>>> @@ -55,8 +55,8 @@ struct xsm_ops {
>>>>>>>> void (*security_domaininfo)(struct domain *d,
>>>>>>>> struct xen_domctl_getdomaininfo *info);
>>>>>>>> int (*domain_create)(struct domain *d, uint32_t ssidref);
>>>>>>>> - int (*getdomaininfo)(struct domain *d);
>>>>>>>> #ifdef CONFIG_MGMT_HYPERCALLS
>>>>>>>> + int (*getdomaininfo)(struct domain *d);
>>>>>>>> int (*domctl_scheduler_op)(struct domain *d, int op);
>>>>>>>> int (*sysctl_scheduler_op)(int op);
>>>>>>>> int (*set_target)(struct domain *d, struct domain *e); @@
>>>>>>>> -234,7
>>>>>>>> +234,11 @@ static inline int xsm_domain_create(
>>>>>>>>
>>>>>>>> static inline int xsm_getdomaininfo(xsm_default_t def, struct
>>>>>>>> domain
>>>>>>>> *d) {
>>>>>>>> +#ifdef CONFIG_MGMT_HYPERCALLS
>>>>>>>> return alternative_call(xsm_ops.getdomaininfo, d);
>>>>>>>> +#else
>>>>>>>> + return -EOPNOTSUPP;
>>>>>>>> +#endif
>>>>>>>> }
>>>>>>> This is in use by a Xenstore sysctl and a Xenstore domctl. The
>>>>>>> sysctl is hence already broken with the earlier series. Now the
>>>>>>> domctl is also being screwed up. I don't think MGMT_HYPERCALLS
>>>>>>> really ought to extend to any operations available to other than the core
>>> toolstack.
>>>>>>> That's the Xenstore ones here, but also the ones used by qemu
>>>>>>> (whether run in
>>>>> Dom0 or a stubdom).
>>>>>> Maybe not only limited to the core toolstack. In
>>>>>> dom0less/hyperlaunched
>>>>> scenarios, hypercalls are strictly limited. QEMU is also limited to
>>>>> pvh machine type and with very restricted functionality(, only acting
>>>>> as a few virtio-pci devices backend). @Andryuk, Jason @Stabellini,
>>>>> Stefano Am I understanding correctly and thoroughly about our scenario here for
>>> upstream?
>>>>>> Tracking the codes, if Xenstore is created as a stub domain, it
>>>>>> requires
>>>>> getdomaininfo-domctl to acquire related info. Sorry, I haven't found
>>>>> how it was called in QEMU...
>>>>>
>>>>> It's not "it"; it's different ones. First and foremost I was thinking
>>>>> of
>>>>> * XEN_DOMCTL_ioport_mapping
>>>>> * XEN_DOMCTL_memory_mapping
>>>>> * XEN_DOMCTL_bind_pt_irq
>>>>> * XEN_DOMCTL_unbind_pt_irq
>>>>> but there may be others (albeit per the dummy xsm_domctl() this is
>>>>> the full set). As a general criteria, anything using XSM_DM_PRIV
>>>>> checking can in principle be called by qemu.
>>>>>
>>>> Understood.
>>>> I assume that they are all for device passthrough. We are not accepting device
>>> passthrough via core toolstack in dom0less/hyperlaunch-ed scenarios. Jason has
>>> developed device passthrough through device tree to only accept "static
>>> configured" passthrough in dom0less/hyperlaunch-ed scenario, while it is still
>>> internal , it may be the only accept way to do device passthrough in
>>> dom0less/hyperlaunch-ed scenario.
>>>
>>> Right, but no matter what your goals, the upstream contributions need to be self-
>>> consistent. I.e. not (risk to) break other functionality. (Really the four domctl-s
>>> mentioned above might better have been put elsewhere, e.g. as dm-ops. Moving
>>> them may be an option here.)
>> Understood.
>> I'll move them all to the dm-ops
> Before you do so, please consider the consequences, though (I said "may" for a
> reason). Also please allow others to chime in. (In this context I notice that
> several REST maintainers weren't even Cc-ed here, and hence may not have seen
> the earlier discussion.)
>
> One thing seems pretty clear to me: This work likely isn't going to be suitable
> for 4.21 anymore. Hence we're back to considering alternatives to address the
> still pending build issue. (My take on it remains: Revert the tail of the
> sysctl work.) Adding Oleksii to Cc as well.
I agree, the patch series is still quite far from being ready to merge.
So let’s consider it for the next release.
As mentioned in the earlier (related) patch series, reverting the tail of the
sysctl work is still, in my opinion, the best option.
~ Oleksii
[Public]
> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Friday, September 26, 2025 3:14 PM
> To: Penny, Zheng <penny.zheng@amd.com>
> Cc: Huang, Ray <Ray.Huang@amd.com>; Daniel P. Smith
> <dpsmith@apertussolutions.com>; xen-devel@lists.xenproject.org; Andryuk, Jason
> <Jason.Andryuk@amd.com>; Andrew Cooper <andrew.cooper3@citrix.com>;
> Julien Grall <julien@xen.org>; Stefano Stabellini <sstabellini@kernel.org>; Anthony
> PERARD <anthony.perard@vates.tech>; Orzel, Michal <Michal.Orzel@amd.com>;
> Roger Pau Monné <roger.pau@citrix.com>; Oleksii Kurochko
> <oleksii.kurochko@gmail.com>
> Subject: Re: [PATCH v2 18/26] xen/domctl: wrap xsm_getdomaininfo() with
> CONFIG_MGMT_HYPERCALLS
>
> On 26.09.2025 08:57, Penny, Zheng wrote:
> >> -----Original Message-----
> >> From: Jan Beulich <jbeulich@suse.com>
> >> Sent: Friday, September 26, 2025 2:53 PM
> >>
> >> On 26.09.2025 06:41, Penny, Zheng wrote:
> >>>> -----Original Message-----
> >>>> From: Jan Beulich <jbeulich@suse.com>
> >>>> Sent: Thursday, September 25, 2025 10:29 PM
> >>>>
> >>>> On 25.09.2025 11:41, Penny, Zheng wrote:
> >>>>>> -----Original Message-----
> >>>>>> From: Jan Beulich <jbeulich@suse.com>
> >>>>>> Sent: Thursday, September 11, 2025 9:30 PM
> >>>>>>
> >>>>>> On 10.09.2025 09:38, Penny Zheng wrote:
> >>>>>>> --- a/xen/include/xsm/xsm.h
> >>>>>>> +++ b/xen/include/xsm/xsm.h
> >>>>>>> @@ -55,8 +55,8 @@ struct xsm_ops {
> >>>>>>> void (*security_domaininfo)(struct domain *d,
> >>>>>>> struct xen_domctl_getdomaininfo *info);
> >>>>>>> int (*domain_create)(struct domain *d, uint32_t ssidref);
> >>>>>>> - int (*getdomaininfo)(struct domain *d);
> >>>>>>> #ifdef CONFIG_MGMT_HYPERCALLS
> >>>>>>> + int (*getdomaininfo)(struct domain *d);
> >>>>>>> int (*domctl_scheduler_op)(struct domain *d, int op);
> >>>>>>> int (*sysctl_scheduler_op)(int op);
> >>>>>>> int (*set_target)(struct domain *d, struct domain *e); @@
> >>>>>>> -234,7
> >>>>>>> +234,11 @@ static inline int xsm_domain_create(
> >>>>>>>
> >>>>>>> static inline int xsm_getdomaininfo(xsm_default_t def, struct
> >>>>>>> domain
> >>>>>>> *d) {
> >>>>>>> +#ifdef CONFIG_MGMT_HYPERCALLS
> >>>>>>> return alternative_call(xsm_ops.getdomaininfo, d);
> >>>>>>> +#else
> >>>>>>> + return -EOPNOTSUPP;
> >>>>>>> +#endif
> >>>>>>> }
> >>>>>>
> >>>>>> This is in use by a Xenstore sysctl and a Xenstore domctl. The
> >>>>>> sysctl is hence already broken with the earlier series. Now the
> >>>>>> domctl is also being screwed up. I don't think MGMT_HYPERCALLS
> >>>>>> really ought to extend to any operations available to other than
> >>>>>> the core
> >> toolstack.
> >>>>>> That's the Xenstore ones here, but also the ones used by qemu
> >>>>>> (whether run in
> >>>> Dom0 or a stubdom).
> >>>>>
> >>>>> Maybe not only limited to the core toolstack. In
> >>>>> dom0less/hyperlaunched
> >>>> scenarios, hypercalls are strictly limited. QEMU is also limited to
> >>>> pvh machine type and with very restricted functionality(, only
> >>>> acting as a few virtio-pci devices backend). @Andryuk, Jason
> >>>> @Stabellini, Stefano Am I understanding correctly and thoroughly
> >>>> about our scenario here for
> >> upstream?
> >>>>> Tracking the codes, if Xenstore is created as a stub domain, it
> >>>>> requires
> >>>> getdomaininfo-domctl to acquire related info. Sorry, I haven't
> >>>> found how it was called in QEMU...
> >>>>
> >>>> It's not "it"; it's different ones. First and foremost I was
> >>>> thinking of
> >>>> * XEN_DOMCTL_ioport_mapping
> >>>> * XEN_DOMCTL_memory_mapping
> >>>> * XEN_DOMCTL_bind_pt_irq
> >>>> * XEN_DOMCTL_unbind_pt_irq
> >>>> but there may be others (albeit per the dummy xsm_domctl() this is
> >>>> the full set). As a general criteria, anything using XSM_DM_PRIV
> >>>> checking can in principle be called by qemu.
> >>>>
> >>>
> >>> Understood.
> >>> I assume that they are all for device passthrough. We are not
> >>> accepting device
> >> passthrough via core toolstack in dom0less/hyperlaunch-ed scenarios.
> >> Jason has developed device passthrough through device tree to only
> >> accept "static configured" passthrough in dom0less/hyperlaunch-ed
> >> scenario, while it is still internal , it may be the only accept way
> >> to do device passthrough in dom0less/hyperlaunch-ed scenario.
> >>
> >> Right, but no matter what your goals, the upstream contributions need
> >> to be self- consistent. I.e. not (risk to) break other functionality.
> >> (Really the four domctl-s mentioned above might better have been put
> >> elsewhere, e.g. as dm-ops. Moving them may be an option here.)
> >
> > Understood.
> > I'll move them all to the dm-ops
>
> Before you do so, please consider the consequences, though (I said "may" for a
> reason). Also please allow others to chime in. (In this context I notice that several
> REST maintainers weren't even Cc-ed here, and hence may not have seen the
> earlier discussion.)
>
Sorry, what I really mean is that I'm going to investigate the actual work required for moving these four hypercalls to dm-ops. Then I could go back to the discussion to have a clearer view. To be clear, you are suggesting ABI change, like XEN_DOMCTL_ioport_mapping to XEN_DMOP_ioport_mapping, or new ABI added?
> One thing seems pretty clear to me: This work likely isn't going to be suitable for
> 4.21 anymore. Hence we're back to considering alternatives to address the still
> pending build issue. (My take on it remains: Revert the tail of the sysctl work.)
> Adding Oleksii to Cc as well.
>
> Jan
On 26.09.2025 10:22, Penny, Zheng wrote:
> [Public]
>
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: Friday, September 26, 2025 3:14 PM
>> To: Penny, Zheng <penny.zheng@amd.com>
>> Cc: Huang, Ray <Ray.Huang@amd.com>; Daniel P. Smith
>> <dpsmith@apertussolutions.com>; xen-devel@lists.xenproject.org; Andryuk, Jason
>> <Jason.Andryuk@amd.com>; Andrew Cooper <andrew.cooper3@citrix.com>;
>> Julien Grall <julien@xen.org>; Stefano Stabellini <sstabellini@kernel.org>; Anthony
>> PERARD <anthony.perard@vates.tech>; Orzel, Michal <Michal.Orzel@amd.com>;
>> Roger Pau Monné <roger.pau@citrix.com>; Oleksii Kurochko
>> <oleksii.kurochko@gmail.com>
>> Subject: Re: [PATCH v2 18/26] xen/domctl: wrap xsm_getdomaininfo() with
>> CONFIG_MGMT_HYPERCALLS
>>
>> On 26.09.2025 08:57, Penny, Zheng wrote:
>>>> -----Original Message-----
>>>> From: Jan Beulich <jbeulich@suse.com>
>>>> Sent: Friday, September 26, 2025 2:53 PM
>>>>
>>>> On 26.09.2025 06:41, Penny, Zheng wrote:
>>>>>> -----Original Message-----
>>>>>> From: Jan Beulich <jbeulich@suse.com>
>>>>>> Sent: Thursday, September 25, 2025 10:29 PM
>>>>>>
>>>>>> On 25.09.2025 11:41, Penny, Zheng wrote:
>>>>>>>> -----Original Message-----
>>>>>>>> From: Jan Beulich <jbeulich@suse.com>
>>>>>>>> Sent: Thursday, September 11, 2025 9:30 PM
>>>>>>>>
>>>>>>>> On 10.09.2025 09:38, Penny Zheng wrote:
>>>>>>>>> --- a/xen/include/xsm/xsm.h
>>>>>>>>> +++ b/xen/include/xsm/xsm.h
>>>>>>>>> @@ -55,8 +55,8 @@ struct xsm_ops {
>>>>>>>>> void (*security_domaininfo)(struct domain *d,
>>>>>>>>> struct xen_domctl_getdomaininfo *info);
>>>>>>>>> int (*domain_create)(struct domain *d, uint32_t ssidref);
>>>>>>>>> - int (*getdomaininfo)(struct domain *d);
>>>>>>>>> #ifdef CONFIG_MGMT_HYPERCALLS
>>>>>>>>> + int (*getdomaininfo)(struct domain *d);
>>>>>>>>> int (*domctl_scheduler_op)(struct domain *d, int op);
>>>>>>>>> int (*sysctl_scheduler_op)(int op);
>>>>>>>>> int (*set_target)(struct domain *d, struct domain *e); @@
>>>>>>>>> -234,7
>>>>>>>>> +234,11 @@ static inline int xsm_domain_create(
>>>>>>>>>
>>>>>>>>> static inline int xsm_getdomaininfo(xsm_default_t def, struct
>>>>>>>>> domain
>>>>>>>>> *d) {
>>>>>>>>> +#ifdef CONFIG_MGMT_HYPERCALLS
>>>>>>>>> return alternative_call(xsm_ops.getdomaininfo, d);
>>>>>>>>> +#else
>>>>>>>>> + return -EOPNOTSUPP;
>>>>>>>>> +#endif
>>>>>>>>> }
>>>>>>>>
>>>>>>>> This is in use by a Xenstore sysctl and a Xenstore domctl. The
>>>>>>>> sysctl is hence already broken with the earlier series. Now the
>>>>>>>> domctl is also being screwed up. I don't think MGMT_HYPERCALLS
>>>>>>>> really ought to extend to any operations available to other than
>>>>>>>> the core
>>>> toolstack.
>>>>>>>> That's the Xenstore ones here, but also the ones used by qemu
>>>>>>>> (whether run in
>>>>>> Dom0 or a stubdom).
>>>>>>>
>>>>>>> Maybe not only limited to the core toolstack. In
>>>>>>> dom0less/hyperlaunched
>>>>>> scenarios, hypercalls are strictly limited. QEMU is also limited to
>>>>>> pvh machine type and with very restricted functionality(, only
>>>>>> acting as a few virtio-pci devices backend). @Andryuk, Jason
>>>>>> @Stabellini, Stefano Am I understanding correctly and thoroughly
>>>>>> about our scenario here for
>>>> upstream?
>>>>>>> Tracking the codes, if Xenstore is created as a stub domain, it
>>>>>>> requires
>>>>>> getdomaininfo-domctl to acquire related info. Sorry, I haven't
>>>>>> found how it was called in QEMU...
>>>>>>
>>>>>> It's not "it"; it's different ones. First and foremost I was
>>>>>> thinking of
>>>>>> * XEN_DOMCTL_ioport_mapping
>>>>>> * XEN_DOMCTL_memory_mapping
>>>>>> * XEN_DOMCTL_bind_pt_irq
>>>>>> * XEN_DOMCTL_unbind_pt_irq
>>>>>> but there may be others (albeit per the dummy xsm_domctl() this is
>>>>>> the full set). As a general criteria, anything using XSM_DM_PRIV
>>>>>> checking can in principle be called by qemu.
>>>>>>
>>>>>
>>>>> Understood.
>>>>> I assume that they are all for device passthrough. We are not
>>>>> accepting device
>>>> passthrough via core toolstack in dom0less/hyperlaunch-ed scenarios.
>>>> Jason has developed device passthrough through device tree to only
>>>> accept "static configured" passthrough in dom0less/hyperlaunch-ed
>>>> scenario, while it is still internal , it may be the only accept way
>>>> to do device passthrough in dom0less/hyperlaunch-ed scenario.
>>>>
>>>> Right, but no matter what your goals, the upstream contributions need
>>>> to be self- consistent. I.e. not (risk to) break other functionality.
>>>> (Really the four domctl-s mentioned above might better have been put
>>>> elsewhere, e.g. as dm-ops. Moving them may be an option here.)
>>>
>>> Understood.
>>> I'll move them all to the dm-ops
>>
>> Before you do so, please consider the consequences, though (I said "may" for a
>> reason). Also please allow others to chime in. (In this context I notice that several
>> REST maintainers weren't even Cc-ed here, and hence may not have seen the
>> earlier discussion.)
>>
>
> Sorry, what I really mean is that I'm going to investigate the actual work required for moving these four hypercalls to dm-ops. Then I could go back to the discussion to have a clearer view. To be clear, you are suggesting ABI change, like XEN_DOMCTL_ioport_mapping to XEN_DMOP_ioport_mapping, or new ABI added?
Well, merely adding new ABIs wouldn't address the problem, would it? You'd
need to make sure the old ABIs aren't used anymore by up-to-date code, at
which point the old domctl sub-ops could as well go away. A follow-on
question then would be whether retaining the wrappers in libxc is
appropriate; aiui dm-ops are rather intended to be dealt with in
libxendevicemodel. Yet moving things between libraries can (will?) break
consumers of the libraries.
Jan
© 2016 - 2026 Red Hat, Inc.