Domain IDs and Capabilities

[Jason Andryuk <jason.andryuk@xxxxxxx>]

Hi,

I'm finding it necessary to expose a domain's domid and capabilities to 
the domain itself.
On x86, SIF_privileged and SIF_hardware allow a domain to know its 
privileges through start_info.  ARM does not have start_info, and 
xenstore domain status is not exposed.
Xen sets XENFEAT_dom0 for is_hardware_domain(), and then ARM Linux 
creates local xen_start_flags with both SIF_PRIVILEGED (control) and 
SIF_INITDOMAIN (hardware) set.  This is inaccurate with a split hardware 
and control domains.
(This looks like a mis-use of XENFEAT_dom0.  It's present in ELF Notes 
seems more like a flag for a binary to indicate to Xen's ELF loader that 
it is capable of running as dom0.)
xen_start_flags influences Linux kernel behavior and userspace. 
/proc/xen/capabilities control_d is only set for SIF_INITDOMAIN. 
Similarly, the /proc/xen/xsd_{kva,port} keys needed to run xenstored 
locally depend on xen_initial_domain(), which can be incorrect.
It is useful for a domain to know its own domid.  Xenstored has command 
line flags to set --master-domid (the local domid) and --priv-domid, but 
it would be better to autodetect those.  Also, domids are necessary to 
set xenstore permissions - DOMID_SELF is not supported today.
Juergen already implemented a get_domid() function for Mini-OS for a 
xenstore stubdom to query its own domid indirectly through event channel 
games.  That can be re-imlemented in Linux userspace, but it needs the 
unstable xenctrl library to query event channel status.
x86 HVM exposes the domid through a CPUID leaf, so it isn't actually hidden.

Should I add a hypercall to query a domid?  An alternative, for ARM at 
least, is to expose the domid and capabilities in the domain's DT in 
/hypervisor/domid and /hypervisor/caps.  I've tried this out as just 
dumping the domid and caps as uint32_ts.
Reviewing 
https://lore.kernel.org/xen-devel/20231110113435.22609-1-jgross@xxxxxxxx/ 
it seems like both a hypercall and an arch specific means might be possible.
XENFEAT could be extended to exposed finer grain capabilities: 
XENFEAT_{control,hwdom,xenstore}.  This is easy.  Seems a little bit 
like a mis-use of XENFEAT to me, but it works.
If generally exposing domids is not desirable, they could be exposed 
only to domains with capabilities since those are not migratable, AFAICT.
I'm open to suggestions.

Regards,
Jason