On Fri, 7 Mar 2025, Jason Andryuk wrote: > 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.
I wrote a longer reply here: https://marc.info/?l=xen-devel&m=174139414000462 I think there are valid reasons to run xenstored in either the control domain or the hardware domain, so it should be configurable. If no specific preference is indicated, I would place it in the hardware domain because the control domain must remain free from interference. Given that I don't think we know for sure today whether the Xenstore protocol could be a potential vector for interference, it is safer to avoid placing it in the control domain by default. > 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. +1 > 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.
