[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |