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(+)

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
-- 
2.48.1

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

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