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

RE: [PATCH 2/2] viridian: allow vCPU hotplug for Windows VMs



> -----Original Message-----
> From: Igor Druzhinin <igor.druzhinin@xxxxxxxxxx>
> Sent: 08 January 2021 11:36
> To: paul@xxxxxxx; xen-devel@xxxxxxxxxxxxxxxxxxxx
> Cc: wl@xxxxxxx; iwj@xxxxxxxxxxxxxx; anthony.perard@xxxxxxxxxx; 
> andrew.cooper3@xxxxxxxxxx;
> george.dunlap@xxxxxxxxxx; jbeulich@xxxxxxxx; julien@xxxxxxx; 
> sstabellini@xxxxxxxxxx;
> roger.pau@xxxxxxxxxx
> Subject: Re: [PATCH 2/2] viridian: allow vCPU hotplug for Windows VMs
> 
> On 08/01/2021 11:33, Paul Durrant wrote:
> >> -----Original Message-----
> >> From: Igor Druzhinin <igor.druzhinin@xxxxxxxxxx>
> >> Sent: 08 January 2021 11:30
> >> To: paul@xxxxxxx; xen-devel@xxxxxxxxxxxxxxxxxxxx
> >> Cc: wl@xxxxxxx; iwj@xxxxxxxxxxxxxx; anthony.perard@xxxxxxxxxx; 
> >> andrew.cooper3@xxxxxxxxxx;
> >> george.dunlap@xxxxxxxxxx; jbeulich@xxxxxxxx; julien@xxxxxxx; 
> >> sstabellini@xxxxxxxxxx;
> >> roger.pau@xxxxxxxxxx
> >> Subject: Re: [PATCH 2/2] viridian: allow vCPU hotplug for Windows VMs
> >>
> >> On 08/01/2021 08:38, Paul Durrant wrote:
> >>>> -----Original Message-----
> >>>> From: Igor Druzhinin <igor.druzhinin@xxxxxxxxxx>
> >>>> Sent: 08 January 2021 00:47
> >>>> To: xen-devel@xxxxxxxxxxxxxxxxxxxx
> >>>> Cc: paul@xxxxxxx; wl@xxxxxxx; iwj@xxxxxxxxxxxxxx; 
> >>>> anthony.perard@xxxxxxxxxx;
> >>>> andrew.cooper3@xxxxxxxxxx; george.dunlap@xxxxxxxxxx; jbeulich@xxxxxxxx; 
> >>>> julien@xxxxxxx;
> >>>> sstabellini@xxxxxxxxxx; roger.pau@xxxxxxxxxx; Igor Druzhinin 
> >>>> <igor.druzhinin@xxxxxxxxxx>
> >>>> Subject: [PATCH 2/2] viridian: allow vCPU hotplug for Windows VMs
> >>>>
> >>>> If Viridian extensions are enabled, Windows wouldn't currently allow
> >>>> a hotplugged vCPU to be brought up dynamically. We need to expose a 
> >>>> special
> >>>> bit to let the guest know we allow it. It appears we can just start 
> >>>> exposing
> >>>> it without worrying too much about compatibility - see relevant QEMU
> >>>> discussion here:
> >>>>
> >>>> https://patchwork.kernel.org/project/qemu-devel/patch/1455364815-19586-1-git-send-email-
> >>>> den@xxxxxxxxxx/
> >>>
> >>> I don't think that discussion really confirmed it was safe... just that 
> >>> empirically it appeared to
> >> be so. I think we should err on
> >>> the side of caution and have this behind a feature flag (but I'm happy 
> >>> for it to default to on).
> >>
> >> QEMU was having this code since 2016 and nobody complained is good
> >> enough for me - but if you insist we need an option - ok, I will add one.
> >>
> >
> > Given that it has not yet been in a release, perhaps you could just guard 
> > this and the
> implementation of leaf 0x40000005 using HVMPV_ex_processor_masks?
> 
> That looks sloppy and confusing to me - let's have a separate option instead.
> 

Yes, for this I guess it is really a separate thing. Using 
HVMPV_ex_processor_masks to control the presence of leaf 0x40000005 seems 
reasonable (since it's all about being able to use >64 vcpus). Perhaps a new 
HVMPV_cpu_hotplug for this one?

  Paul

> Igor




 


Rackspace

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