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.
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?
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)?
Cheers,
--
Julien Grall
