|
[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 |