[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH RFC v1 66/74] xen/shim: allow DomU to have as many vcpus as available



On Tue, Jan 09, 2018 at 03:59:33AM -0700, Jan Beulich wrote:
> >>> On 04.01.18 at 14:06, <wei.liu2@xxxxxxxxxx> wrote:
> > From: Roger Pau Monne <roger.pau@xxxxxxxxxx>
> > 
> > Since the shim VCPUOP_{up/down} hypercall is wired to the plug/unplug
> > of CPUs to the shim itself, start the shim DomU with only the BSP
> > online, and let the guest bring up other CPUs as it needs them.
> > 
> > Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> 
> What are the ramifications of not making this change? Shouldn't
> the shim's pCPU count (pCPU as viewed from its own perspective)
> simply always match its client's vCPU count?

Yes, that's the point of this change. By default Dom0 will get a many
vCPUs as online pCPUs. ÇIn the shim case the number of online pCPUs is
always 1, and thus we need to set max_vcpus to match the number of
possible pCPUs.

> > --- a/xen/arch/x86/pv/dom0_build.c
> > +++ b/xen/arch/x86/pv/dom0_build.c
> > @@ -695,7 +695,8 @@ int __init dom0_construct_pv(struct domain *d,
> >      for ( i = 0; i < XEN_LEGACY_MAX_VCPUS; i++ )
> >          shared_info(d, vcpu_info[i].evtchn_upcall_mask) = 1;
> >  
> > -    printk("Dom0 has maximum %u VCPUs\n", d->max_vcpus);
> > +    printk("%s has maximum %u VCPUs\n", pv_shim ? "DomU" : "Dom0",
> 
> "Dom%c ..." perhaps?

We could even use Dom%u and d->domain_id. That would remove the
dependency on pv_shim.

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.