On 02.02.2026 17:14, Mykyta Poturai wrote: > With introduction of GICv4 the size of struct vcpu can again be more > than one page. Modify struct vcpu allocation to request enough pages > again. > > Don't reintroduce the MAX_PAGES_PER_VCPU check. > As per commit b77d774d8274183c2252f5fbc9fa3b3b7022ba06 >> It turns out that beyond efficiency, maybe, there is no real technical >> reason this struct has to fit in one page > > Since there is no technical reason to limit struct vcpu size to one page, > there also seems to be little reason the fiddle with 1 or 2 page limits.
Before writing this, did you check the recent discussion around the Arm side change going back to a single page, and the moving of this code to common/? Any ... > --- a/xen/common/domain.c > +++ b/xen/common/domain.c > @@ -342,18 +342,24 @@ static struct vcpu *alloc_vcpu_struct(const struct > domain *d) > # define arch_vcpu_struct_memflags(d) ((void)(d), 0) > #endif > struct vcpu *v; > + unsigned int order = get_order_from_bytes(sizeof(*v)); > > - BUILD_BUG_ON(sizeof(*v) > PAGE_SIZE); > - v = alloc_xenheap_pages(0, arch_vcpu_struct_memflags(d)); > + v = alloc_xenheap_pages(order, arch_vcpu_struct_memflags(d)); ... non-order-0 allocation is at risk of failing despite there being ample memory available, if there's heavy fragmentation. I'm sorry, but without a much better justification this gets a NAK from me. Jan
