On 2025-03-07 16:01, Julien Grall wrote:
Hi Jason,
On 07/03/2025 16:03, Jason Andryuk wrote:
On 2025-03-07 03:31, Julien Grall wrote:
Hi,
On 06/03/2025 22:03, Jason Andryuk wrote:
Assign domid 0 to the hwdom. Normally, dom0less does not use domid 0.
A few years ago, we went to great length to avoid making the
assumption that the hardware domain is domid 0. See all the calls to
"is_hardware_domain()". So I am reluctant to force the domain ID to 0.
I was disappointed when it didn't "just work".
This fixes using the Xen console which assumes domid 0 to use the
hypercall interface.
I had a brief look at drivers/char/console.c and I can't find any
place assuming "domid 0". Do you have any pointer?
As Jan pointed out, Denis Mukhin's patch removed the domid 0
assumption. This was developed without this patch when it mattered.
I tested before posting without this patch (and with Denis's), and
again now, and I didn't get a hwdom login. Turns out xenstored was
assuming domid 0. Changing that with --master-domid gets to the login
prompt.
Hmmm, I am not sure --master-domid should point to the hardware domain.
Instead, it feels like it should be the control domain because it needs
to manage the VMs so needs to create any nodes in Xenstore.
--master-domid encompasses "the domid where xenstored is running" (which
really xenstored should figure out itself), and is needed for xenstored
to start.
There is an additional --priv-domid, which can point at the control domain.
Still, there are now other userspace errors. xen-init-dom0 hardcodes
domid 0 which doesn't exist.
I am confused. Why would you call xen-init-dom0 in a domain that is
meant to be the hardware domain rather than dom0?
I was using domid 0 :) Also, it's called by default in xencommons and
sets up the cpupools.
init-dom0less only initializes non- introduced domains, so hwdom
doesn't get its "domid" xenstore node populated. That leads to other
errors.
> > So I think with Denis's patch, this isn't strictly needed. It does
help
existing toolstack code work today.
I don't think the toolstack is ready for a split between control/
hardware domain. That said, shouldn't the toolstack run in the control
domain? Same for xenstored (unless you have a xenstored domain)?
Yes, maybe running control and xenstore together is better. I came from
the perspective of dom0less with a hardware/control split, the toolstack
is less important.
But in general, it's all intertwined. You have to start somewhere
untangling.
Running xenstored in the hardware domain, and leaving hardware domain at
domid 0 seemed like a good way to keep most things working while
splitting out the hardware/control permissions.
There was also this practical consideration:
Xen:
if ( is_hardware_domain(d) )
fi.submap |= 1U << XENFEAT_dom0;
arch/arm/xen/enlighten.c
if (xen_feature(XENFEAT_dom0))
xen_start_flags |= SIF_INITDOMAIN|SIF_PRIVILEGED;
drivers/xen/xenfs/super.c
if (xen_initial_domain())
tmp = "control_d\n";
So control_d is set in /proc/xen/capabilities for the hardware
domain/initial domain. That is checked in xencommons. Sure, that can
be worked around, but I was trying to get something going.
I tried a combined control|xenstore domain, but it doesn't have
/proc/xen/xsd_port, so xenstored fails:
Failed to initialize dom0 port: No such file or directory
Regards,
Jason
