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
