Re: [PATCH v10 3/3] xen/domain: use get_initial_domain_id() instead of open-coded 0

[dmkhn@proton.me]

On Tue, Jun 24, 2025 at 08:07:55AM +0200, Jan Beulich wrote:
> On 23.06.2025 20:28, dmkhn@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