On 02.09.2026 15:29, Oleksii Kurochko wrote: > On 9/2/26 3:07 PM, Jan Beulich wrote: >> On 02.09.2026 13:42, Oleksii Kurochko wrote: >>> It will also affect then common code as vcpu_csr_init() could be then >>> called before domain type is set: >>> >>> +++ b/xen/common/device-tree/dom0less-build.c >>> @@ -812,17 +812,18 @@ static int __init construct_domU(struct >>> kernel_info *kinfo, >>> else if ( rc == 0 && !strcmp(dom0less_enhanced, "no-xenstore") ) >>> kinfo->dom0less_feature = DOM0LESS_ENHANCED_NO_XS; >>> >>> - if ( vcpu_create(d, 0) == NULL ) >>> - return -ENOMEM; >>> - >>> d->max_pages = ((paddr_t)mem * SZ_1K) >> PAGE_SHIFT; >>> >>> rc = kernel_probe(kinfo, node); >>> if ( rc < 0 ) >>> return rc; >>> >>> + /* The domain type needs to be known before the first vCPU is >>> created. */ >>> set_domain_type(d, kinfo); >>> >>> + if ( vcpu_create(d, 0) == NULL ) >>> + return -ENOMEM; >> >> I don't understand the need for this, likely because I don't see why >> domain_vsxl() would need calling from underneath vcpu_create(). > > The call trace will be the following: > vcpu_create() -> arch_vcpu_create() -> vcpu_csr_init() -> > domain_vsxldomain_vsxl() > > unsigned int vsxl = domain_vsxl(v->domain); > > ... > > vcpu_guest_cpu_user_regs(v)->hstatus = > HSTATUS_SPV | HSTATUS_SPVP | MASK_INSR(vsxl, HSTATUS_VSXL); > > Without moving vcpu_create(d, 0) after set_domain_type(), domain_vsxl() > will return something wrong.
Question is - do you need to set ->hstatus this early? > I also thought about updating of VSXL for each vCPU in > construct_domain() where d->type is already known and then no changes in > common code are needed. But I think it is a little bit better just have > a change in common code. If the maintainers accept that change, it certainly may end up being easier. Jan
