Re: [Xen-devel] PVH VCPU hotplug support v7?

[Roger Pau Monné]

On Mon, Jul 31, 2017 at 12:18:28PM -0400, Boris Ostrovsky wrote:
> On 07/31/2017 11:36 AM, Ross Lagerwall wrote:
> > On 07/31/2017 03:29 PM, Boris Ostrovsky wrote:
> >> On 07/31/2017 10:12 AM, Andrew Cooper wrote:
> >>> On 31/07/17 14:55, Boris Ostrovsky wrote:
>  On 07/31/2017 09:20 AM, Ross Lagerwall wrote:
> > Hi Boris,
> >
> > I've modified your PVH VCPU hotplug support v6 patch series [1] to
> > support HVM guests running _with_ a device model for XenServer's
> > purposes. This is useful because it moves the vCPU hotplug handling
> > out of QEMU and allows it to mostly be shared with PVH. It will also
> > allow unplugging vCPUs (libxl currently only does cpu-add for
> > upstream
> > qemu).
> >
> > Are you still planning on continuing with that patch series since
> > your
> > commit to Linux [2]?
>  This series has been put on hold until we figure out what to do with
>  hotplug for PVH dom0. (The problem was the "dual" view by dom0 of APCI
>  CPU namespace --- on hotplug event dom0 has to somehow figure out
>  whether the event was due to (dis)appearance of a physical or
>  virtual CPU).
> 
>  I don't think this has been dealt with yet (copying Roger).
> >>>  From the point of view of unblocking several pieces of work, it
> >>> would be
> >>> fine for this logic to be behind an emulation flag, just like
> >>> LAPIC/etc.
> >>
> >> The (I think) last message discussing this series was
> >>
> >> https://lists.xenproject.org/archives/html/xen-devel/2017-01/msg00143.html
> >>
> >>
> >> Are you suggesting extracting pieces that would move hotplug support for
> >> HVM guests from qemu to hypervisor/toolstack but leave all PVH-specific
> >> code out? (The feature flag is part of this series ---
> >> https://lists.xenproject.org/archives/html/xen-devel/2017-01/msg00059.html)
> >>
> >>
> >
> > I think(?) Andrew was suggesting to have an emulation flag such that
> > hotplug support is moved into the hypervisor for HVM guests _and_ PVH
> > guests except for PVH dom0.
>
> That (different handling for PVH dom0 vs. domU) was exactly what Jan was
> objecting to. (I'll add him too).

I think it should be fine to move the vCPU hotplug out of QEMU into
Xen, but I'm not sure we should enable it for PVH DomU guests, not
until we know exactly if we can also use ACPI vCPU hotplug for Dom0.

In any case, if we ever support ACPI vCPU hotplug for PVH the code
must reside in the hypervisor.

FWIW, I posted my proposal to the ACPI working group, and I didn't get
any Nacks, but it's still a little bit down the road for me to
actually try to implement it.

Roger.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] PVH VCPU hotplug support v7?

[Boris Ostrovsky]

On 07/31/2017 11:36 AM, Ross Lagerwall wrote:
> On 07/31/2017 03:29 PM, Boris Ostrovsky wrote:
>> On 07/31/2017 10:12 AM, Andrew Cooper wrote:
>>> On 31/07/17 14:55, Boris Ostrovsky wrote:
 On 07/31/2017 09:20 AM, Ross Lagerwall wrote:
> Hi Boris,
>
> I've modified your PVH VCPU hotplug support v6 patch series [1] to
> support HVM guests running _with_ a device model for XenServer's
> purposes. This is useful because it moves the vCPU hotplug handling
> out of QEMU and allows it to mostly be shared with PVH. It will also
> allow unplugging vCPUs (libxl currently only does cpu-add for
> upstream
> qemu).
>
> Are you still planning on continuing with that patch series since
> your
> commit to Linux [2]?
 This series has been put on hold until we figure out what to do with
 hotplug for PVH dom0. (The problem was the "dual" view by dom0 of APCI
 CPU namespace --- on hotplug event dom0 has to somehow figure out
 whether the event was due to (dis)appearance of a physical or
 virtual CPU).

 I don't think this has been dealt with yet (copying Roger).
>>>  From the point of view of unblocking several pieces of work, it
>>> would be
>>> fine for this logic to be behind an emulation flag, just like
>>> LAPIC/etc.
>>
>> The (I think) last message discussing this series was
>>
>> https://lists.xenproject.org/archives/html/xen-devel/2017-01/msg00143.html
>>
>>
>> Are you suggesting extracting pieces that would move hotplug support for
>> HVM guests from qemu to hypervisor/toolstack but leave all PVH-specific
>> code out? (The feature flag is part of this series ---
>> https://lists.xenproject.org/archives/html/xen-devel/2017-01/msg00059.html)
>>
>>
>
> I think(?) Andrew was suggesting to have an emulation flag such that
> hotplug support is moved into the hypervisor for HVM guests _and_ PVH
> guests except for PVH dom0.

That (different handling for PVH dom0 vs. domU) was exactly what Jan was
objecting to. (I'll add him too).

-boris

>
> I don't know what work this unblocks that he was referring to.
>


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] PVH VCPU hotplug support v7?

[Ross Lagerwall]

On 07/31/2017 03:29 PM, Boris Ostrovsky wrote:

On 07/31/2017 10:12 AM, Andrew Cooper wrote:

On 31/07/17 14:55, Boris Ostrovsky wrote:

On 07/31/2017 09:20 AM, Ross Lagerwall wrote:

Hi Boris,

I've modified your PVH VCPU hotplug support v6 patch series [1] to
support HVM guests running _with_ a device model for XenServer's
purposes. This is useful because it moves the vCPU hotplug handling
out of QEMU and allows it to mostly be shared with PVH. It will also
allow unplugging vCPUs (libxl currently only does cpu-add for upstream
qemu).

Are you still planning on continuing with that patch series since your
commit to Linux [2]?

This series has been put on hold until we figure out what to do with
hotplug for PVH dom0. (The problem was the "dual" view by dom0 of APCI
CPU namespace --- on hotplug event dom0 has to somehow figure out
whether the event was due to (dis)appearance of a physical or virtual CPU).

I don't think this has been dealt with yet (copying Roger).

 From the point of view of unblocking several pieces of work, it would be
fine for this logic to be behind an emulation flag, just like LAPIC/etc.


The (I think) last message discussing this series was

https://lists.xenproject.org/archives/html/xen-devel/2017-01/msg00143.html

Are you suggesting extracting pieces that would move hotplug support for
HVM guests from qemu to hypervisor/toolstack but leave all PVH-specific
code out? (The feature flag is part of this series ---
https://lists.xenproject.org/archives/html/xen-devel/2017-01/msg00059.html)



I think(?) Andrew was suggesting to have an emulation flag such that 
hotplug support is moved into the hypervisor for HVM guests _and_ PVH 
guests except for PVH dom0.


I don't know what work this unblocks that he was referring to.

--
Ross Lagerwall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] PVH VCPU hotplug support v7?

[Boris Ostrovsky]

On 07/31/2017 10:12 AM, Andrew Cooper wrote:
> On 31/07/17 14:55, Boris Ostrovsky wrote:
>> On 07/31/2017 09:20 AM, Ross Lagerwall wrote:
>>> Hi Boris,
>>>
>>> I've modified your PVH VCPU hotplug support v6 patch series [1] to
>>> support HVM guests running _with_ a device model for XenServer's
>>> purposes. This is useful because it moves the vCPU hotplug handling
>>> out of QEMU and allows it to mostly be shared with PVH. It will also
>>> allow unplugging vCPUs (libxl currently only does cpu-add for upstream
>>> qemu).
>>>
>>> Are you still planning on continuing with that patch series since your
>>> commit to Linux [2]?
>> This series has been put on hold until we figure out what to do with
>> hotplug for PVH dom0. (The problem was the "dual" view by dom0 of APCI
>> CPU namespace --- on hotplug event dom0 has to somehow figure out
>> whether the event was due to (dis)appearance of a physical or virtual CPU).
>>
>> I don't think this has been dealt with yet (copying Roger).
> From the point of view of unblocking several pieces of work, it would be
> fine for this logic to be behind an emulation flag, just like LAPIC/etc.

The (I think) last message discussing this series was

https://lists.xenproject.org/archives/html/xen-devel/2017-01/msg00143.html

Are you suggesting extracting pieces that would move hotplug support for
HVM guests from qemu to hypervisor/toolstack but leave all PVH-specific
code out? (The feature flag is part of this series --- 
https://lists.xenproject.org/archives/html/xen-devel/2017-01/msg00059.html)

-boris

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] PVH VCPU hotplug support v7?

[Andrew Cooper]

On 31/07/17 14:55, Boris Ostrovsky wrote:
> On 07/31/2017 09:20 AM, Ross Lagerwall wrote:
>> Hi Boris,
>>
>> I've modified your PVH VCPU hotplug support v6 patch series [1] to
>> support HVM guests running _with_ a device model for XenServer's
>> purposes. This is useful because it moves the vCPU hotplug handling
>> out of QEMU and allows it to mostly be shared with PVH. It will also
>> allow unplugging vCPUs (libxl currently only does cpu-add for upstream
>> qemu).
>>
>> Are you still planning on continuing with that patch series since your
>> commit to Linux [2]?
> This series has been put on hold until we figure out what to do with
> hotplug for PVH dom0. (The problem was the "dual" view by dom0 of APCI
> CPU namespace --- on hotplug event dom0 has to somehow figure out
> whether the event was due to (dis)appearance of a physical or virtual CPU).
>
> I don't think this has been dealt with yet (copying Roger).

From the point of view of unblocking several pieces of work, it would be
fine for this logic to be behind an emulation flag, just like LAPIC/etc.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] PVH VCPU hotplug support v7?

[Boris Ostrovsky]

On 07/31/2017 09:20 AM, Ross Lagerwall wrote:
> Hi Boris,
>
> I've modified your PVH VCPU hotplug support v6 patch series [1] to
> support HVM guests running _with_ a device model for XenServer's
> purposes. This is useful because it moves the vCPU hotplug handling
> out of QEMU and allows it to mostly be shared with PVH. It will also
> allow unplugging vCPUs (libxl currently only does cpu-add for upstream
> qemu).
>
> Are you still planning on continuing with that patch series since your
> commit to Linux [2]?

This series has been put on hold until we figure out what to do with
hotplug for PVH dom0. (The problem was the "dual" view by dom0 of APCI
CPU namespace --- on hotplug event dom0 has to somehow figure out
whether the event was due to (dis)appearance of a physical or virtual CPU).

I don't think this has been dealt with yet (copying Roger).

-boris


>
> [1]
> https://lists.xenproject.org/archives/html/xen-devel/2017-01/msg00060.html
>
> [2]:
> commit 2a7197f02dddf1f9cee300bd12512375ed56524a
> Author: Boris Ostrovsky 
> Date:   Mon Feb 6 10:58:05 2017 -0500
>
> xen/pvh: Enable CPU hotplug
>
> PVH guests don't (yet) receive ACPI hotplug interrupts and therefore
> need to monitor xenstore for CPU hotplug event.
>
> Signed-off-by: Boris Ostrovsky 
> Reviewed-by: Juergen Gross 
>
> Thanks,


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] PVH VCPU hotplug support v7?

[Ross Lagerwall]

Hi Boris,

I've modified your PVH VCPU hotplug support v6 patch series [1] to 
support HVM guests running _with_ a device model for XenServer's 
purposes. This is useful because it moves the vCPU hotplug handling out 
of QEMU and allows it to mostly be shared with PVH. It will also allow 
unplugging vCPUs (libxl currently only does cpu-add for upstream qemu).


Are you still planning on continuing with that patch series since your 
commit to Linux [2]?


[1] 
https://lists.xenproject.org/archives/html/xen-devel/2017-01/msg00060.html


[2]:
commit 2a7197f02dddf1f9cee300bd12512375ed56524a
Author: Boris Ostrovsky 
Date:   Mon Feb 6 10:58:05 2017 -0500

xen/pvh: Enable CPU hotplug

PVH guests don't (yet) receive ACPI hotplug interrupts and therefore
need to monitor xenstore for CPU hotplug event.

Signed-off-by: Boris Ostrovsky 
Reviewed-by: Juergen Gross 

Thanks,
--
Ross Lagerwall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel