On 22.07.2025 14:09, Jason Andryuk wrote:
> On 2025-07-21 20:19, Jason Andryuk wrote:
>> Expose a domain's capabilities - control, hardware or xenstore - through
>> stable get domain state hypercall.
>>
>> The xenstore domain can use this information to assign appropriate
>> permissions on connections.
>>
>> Repurpose the 16bit pad field for this purpose.
>>
>> Signed-off-by: Jason Andryuk <jason.andr...@amd.com>
>> Reviewed-by: Juergen Gross <jgr...@suse.com>
>> ---
>> v2:
>> Init info->caps = 0
>> Remove stale comment on caps field
>> Add Juergen's R-b
>> ---
>> xen/common/domain.c | 10 +++++++++-
>> xen/include/public/domctl.h | 7 +++++--
>> 2 files changed, 14 insertions(+), 3 deletions(-)
>>
>> diff --git a/xen/common/domain.c b/xen/common/domain.c
>> index c347de4335..bb33b1f1c7 100644
>> --- a/xen/common/domain.c
>> +++ b/xen/common/domain.c
>
>> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
>> index f1f6f96bc2..136820ea5b 100644
>> --- a/xen/include/public/domctl.h
>> +++ b/xen/include/public/domctl.h
>> @@ -1269,8 +1269,11 @@ struct xen_domctl_get_domain_state {
>> #define XEN_DOMCTL_GETDOMSTATE_STATE_SHUTDOWN 0x0002 /* Shutdown
>> finished. */
>> #define XEN_DOMCTL_GETDOMSTATE_STATE_DYING 0x0004 /* Domain dying. */
>> #define XEN_DOMCTL_GETDOMSTATE_STATE_DEAD 0x0008 /* Domain dead. */
>> - uint16_t pad0; /* Must be 0 on input, returned as 0. */
>> - uint32_t pad1; /* Must be 0 on input, returned as 0. */
>> + uint16_t caps;
>> +#define XEN_DOMCTL_GETDOMSTATE_CAP_CONTROL 0x0001 /* Control domain. */
>> +#define XEN_DOMCTL_GETDOMSTATE_CAP_HARDWARE 0x0002 /* Hardware domain.
>> */
>> +#define XEN_DOMCTL_GETDOMSTATE_CAP_XENSTORE 0x0004 /* Xenstore domain.
>> */
>> + uint32_t pad0; /* Must be 0 on input, returned as 0. */
>
> I have wondered if we should use some of this padding to start returning
> the valid capability bits. When the hypercall (and library) will be
> ready in case the number increases.
How would a caller use that information? The hypervisor wouldn't return
"invalid" bits set. (If any such plausible use could be envisioned, it
being a stable sub-op, providing such information would certainly make
sense.)
> The other alternative would be to return the bits in some other call, in
> which case this one would not need to change. And returning the
> unchanging valids bits on each call seems unnecessary.
Indeed. Yet the same interface could still be used (then perhaps also
to indicate the valid XEN_DOMCTL_GETDOMSTATE_STATE_* bits): Have the
caller pass in another special DOMID_* (DOMID_INVALID already has a
meaning, though).
Jan
