On Tue, Jun 24, 2025 at 08:07:55AM +0200, Jan Beulich wrote:
> On 23.06.2025 20:28, dm...@proton.me wrote:
> > --- a/xen/common/domain.c
> > +++ b/xen/common/domain.c
> > @@ -492,7 +492,7 @@ static int late_hwdom_init(struct domain *d)
> > struct domain *dom0;
> > int rv;
> >
> > - if ( d != hardware_domain || d->domain_id == 0 )
> > + if ( d != hardware_domain || d->domain_id == get_initial_domain_id() )
> > return 0;
> >
> > rv = xsm_init_hardware_domain(XSM_HOOK, d);
> > @@ -501,7 +501,7 @@ static int late_hwdom_init(struct domain *d)
> >
> > printk("Initialising hardware domain %d\n", hardware_domid);
> >
> > - dom0 = rcu_lock_domain_by_id(0);
> > + dom0 = rcu_lock_domain_by_id(get_initial_domain_id());
> > ASSERT(dom0 != NULL);
>
> For both changes above you're introducing a subtle (largely theoretical)
> behavioral change: In shim mode, this assertion, if we somehow made it
> here, would suddenly not trigger anymore. Similarly for the earlier
> change the return path may wrongly be taken then.
Thanks.
>
> > @@ -2479,7 +2479,7 @@ domid_t domid_alloc(domid_t domid)
> > if ( domid == DOMID_FIRST_RESERVED )
> > domid = find_next_zero_bit(domid_bitmap,
> > DOMID_FIRST_RESERVED,
> > - 1);
> > + get_initial_domain_id() + 1);
>
> This imo is the worst of the changes. get_initial_domain_id() can return
> non-zero. In that case we still would (in principle) want to re-start
> from 1 here.
Thanks.
I will postpone this patch until the split of dom0 into control/hardware
settles.
>
> Jan
