On 25.07.25 04:28, Jason Andryuk wrote:
Usually, priv_domid == dom0_domid == 0, and that is what is expected. If we rename s/dom0_domid/store_domid/, it seems more likely we want to actually have the priv_domid as the owner.
Yes, I agree.
That leads to follow on changes to ensure that the priv_domid is created first. Signed-off-by: Jason Andryuk <jason.andr...@amd.com> --- Will this blow up if priv_domid doesn't exist?
That won't be a problem. The problematic case will be when priv_domid is never changed due to no doamin having the CONTROL cap, and some random other domU happens to have domid 0. So maybe priv_domid should be initialized statically to e.g. DOMID_IDLE, as with your init_domains() loop a "normal" dom0 will always have the CONTROL cap and thus will result in priv_domid being set. Same applies probably to store_domid, but that should be set to priv_domid after init_domains() in case no domain had the XENSTORE cap. If both aren't detected it should be fine to bail out early.
Maybe it would be better to just create these as store_domid.
No, reasoning see above. And xenstore-stubdom accesses to Xenstore nodes via the "normal" interfaces shouldn't need any special privileges. Reviewed-by: Juergen Gross <jgr...@suse.com> Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
