On 2025-03-07 16:24, Julien Grall wrote:
Hi,
On 06/03/2025 22:03, Jason Andryuk wrote:
With a split hardware and control domain, the control domain may still
want and xenstore access. Currently this relies on init-dom0less to
seed the grants. This is problematic since we don't want hardware
domain to be able to map the control domain's resources. Instead have
the hypervisor see the grant table entry. The grant is then accessible
as normal.
I am probably missing something, but why would run xenstored in the
hardware domain rather than the control domain? Isn't xenstored more
related to the VM management than HW?
I addressed this in my other email. You're probably right that
xenstored should run in control, but implementation details prevent that
in the short term.
Regardless, of the xenstored placement, I think it's a better design for
Xen to seed the grants. With Xen allocating the xenstore page and event
channel, and now seeding the grant table, they can just be used. A
xenstore stubdom can just establish all the connections without relying
on another domain to perform an action.
I tested that with hyperlaunching the xenstore stubdom. That is where
the two XS_PRIV changes later in the series come from. xenstore stubdom
iterates the domains, reads the hvm_param for the event channel, and
then runs introduce to set up the connection.
Regards,
Jason
