Re: Domain IDs and Capabilities

[Jan Beulich <jbeulich@xxxxxxxx>]

On 31.03.2025 23:46, Jason Andryuk wrote:
> 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.

Setting permissions for oneself?

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

Since guests have ways to figure out their IDs, there's probably nothing
wrong with having a dedicated means for them to obtain them. It just needs
to be made very clear that the ID can (and, at least for now, typically
will) change across migration. As to the mechanism thereof, I stand by my
views voiced in that earlier thread you point at.

Jan