| Message ID | 20250306220343.203047-7-jason.andryuk@amd.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | ARM split hardware and control domains | expand |
On 06.03.2025 23:03, Jason Andryuk wrote: > --- a/xen/include/public/domctl.h > +++ b/xen/include/public/domctl.h > @@ -155,6 +155,12 @@ struct xen_domctl_getdomaininfo { > /* domain has hardware assisted paging */ > #define _XEN_DOMINF_hap 8 > #define XEN_DOMINF_hap (1U<<_XEN_DOMINF_hap) > +/* domain is hardware domain */ > +#define _XEN_DOMINF_hardware 9 > +#define XEN_DOMINF_hardware (1U<<_XEN_DOMINF_hardware) > +/* domain is privileged */ > +#define _XEN_DOMINF_priv 10 > +#define XEN_DOMINF_priv (1U<<_XEN_DOMINF_priv) Better use "control" in place of "priv", as "privileged" can also be a gradual thing? Jan
On 06.03.2025 23:03, Jason Andryuk wrote: > --- a/xen/include/public/domctl.h > +++ b/xen/include/public/domctl.h > @@ -155,6 +155,12 @@ struct xen_domctl_getdomaininfo { > /* domain has hardware assisted paging */ > #define _XEN_DOMINF_hap 8 > #define XEN_DOMINF_hap (1U<<_XEN_DOMINF_hap) > +/* domain is hardware domain */ > +#define _XEN_DOMINF_hardware 9 > +#define XEN_DOMINF_hardware (1U<<_XEN_DOMINF_hardware) > +/* domain is privileged */ > +#define _XEN_DOMINF_priv 10 > +#define XEN_DOMINF_priv (1U<<_XEN_DOMINF_priv) Oh, and: If we really need both constants (I doubt we do), the latter wants to follow style even if all of its siblings don't (i.e. blanks around binary operators). Jan
On 2025-03-10 05:03, Jan Beulich wrote: > On 06.03.2025 23:03, Jason Andryuk wrote: >> --- a/xen/include/public/domctl.h >> +++ b/xen/include/public/domctl.h >> @@ -155,6 +155,12 @@ struct xen_domctl_getdomaininfo { >> /* domain has hardware assisted paging */ >> #define _XEN_DOMINF_hap 8 >> #define XEN_DOMINF_hap (1U<<_XEN_DOMINF_hap) >> +/* domain is hardware domain */ >> +#define _XEN_DOMINF_hardware 9 >> +#define XEN_DOMINF_hardware (1U<<_XEN_DOMINF_hardware) >> +/* domain is privileged */ >> +#define _XEN_DOMINF_priv 10 >> +#define XEN_DOMINF_priv (1U<<_XEN_DOMINF_priv) > > Oh, and: If we really need both constants (I doubt we do), the latter wants > to follow style even if all of its siblings don't (i.e. blanks around binary > operators). Ok on this and the rename. Why do you think they are not necessary? I did not see a way to expose the capabilities for other domains. Or do you mean if they are added to XEN_DOMCTL_get_domain_state that won't be necessary? Thanks, Jason
On 10.03.2025 15:11, Jason Andryuk wrote: > On 2025-03-10 05:03, Jan Beulich wrote: >> On 06.03.2025 23:03, Jason Andryuk wrote: >>> --- a/xen/include/public/domctl.h >>> +++ b/xen/include/public/domctl.h >>> @@ -155,6 +155,12 @@ struct xen_domctl_getdomaininfo { >>> /* domain has hardware assisted paging */ >>> #define _XEN_DOMINF_hap 8 >>> #define XEN_DOMINF_hap (1U<<_XEN_DOMINF_hap) >>> +/* domain is hardware domain */ >>> +#define _XEN_DOMINF_hardware 9 >>> +#define XEN_DOMINF_hardware (1U<<_XEN_DOMINF_hardware) >>> +/* domain is privileged */ >>> +#define _XEN_DOMINF_priv 10 >>> +#define XEN_DOMINF_priv (1U<<_XEN_DOMINF_priv) >> >> Oh, and: If we really need both constants (I doubt we do), the latter wants >> to follow style even if all of its siblings don't (i.e. blanks around binary >> operators). > > Ok on this and the rename. > > Why do you think they are not necessary? I did not see a way to expose > the capabilities for other domains. > > Or do you mean if they are added to XEN_DOMCTL_get_domain_state that > won't be necessary? Oh, I guess "both" was ambiguous: I meant both _XEN_DOMINF_* and XEN_DOMINF_*. Of course we need both a hardware and control bit here. Jan
diff --git a/xen/common/domctl.c b/xen/common/domctl.c index 05abb581a0..3c6dcfed87 100644 --- a/xen/common/domctl.c +++ b/xen/common/domctl.c @@ -103,6 +103,8 @@ void getdomaininfo(struct domain *d, struct xen_domctl_getdomaininfo *info) (d->debugger_attached ? XEN_DOMINF_debugged : 0) | (is_xenstore_domain(d) ? XEN_DOMINF_xs_domain : 0) | (is_hvm_domain(d) ? XEN_DOMINF_hvm_guest : 0) | + (is_hardware_domain(d) ? XEN_DOMINF_hardware : 0) | + (is_control_domain(d) ? XEN_DOMINF_priv : 0) | d->shutdown_code << XEN_DOMINF_shutdownshift; xsm_security_domaininfo(d, info); diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h index e2d392d1e5..84c2af6a09 100644 --- a/xen/include/public/domctl.h +++ b/xen/include/public/domctl.h @@ -155,6 +155,12 @@ struct xen_domctl_getdomaininfo { /* domain has hardware assisted paging */ #define _XEN_DOMINF_hap 8 #define XEN_DOMINF_hap (1U<<_XEN_DOMINF_hap) +/* domain is hardware domain */ +#define _XEN_DOMINF_hardware 9 +#define XEN_DOMINF_hardware (1U<<_XEN_DOMINF_hardware) +/* domain is privileged */ +#define _XEN_DOMINF_priv 10 +#define XEN_DOMINF_priv (1U<<_XEN_DOMINF_priv) /* XEN_DOMINF_shutdown guest-supplied code. */ #define XEN_DOMINF_shutdownmask 255 #define XEN_DOMINF_shutdownshift 16
There isn't currently a way to determine if a domain is the hardware domain or a privilged (control) domain. Add new domain info flags to indicate these properties. This is useful for a hyperlaunch-ed xenstore domain to determine which domains are privileged. Signed-off-by: Jason Andryuk <jason.andryuk@amd.com> --- xen/common/domctl.c | 2 ++ xen/include/public/domctl.h | 6 ++++++ 2 files changed, 8 insertions(+)