Re: [Qemu-devel] [PATCH v2 17/19] s390x: CPU hot unplug via device_del cannot work

[Christian Borntraeger]

On 09/05/2017 02:01 PM, David Hildenbrand wrote:
> On 05.09.2017 11:14, Christian Borntraeger wrote:
>> On 09/04/2017 05:43 PM, David Hildenbrand wrote:
>>> device_del on a CPU will currently do nothing. Let's emmit an error
>>> telling that this is will never work (there is no architecture support
>>> on s390x). Error message copied from ppc.
>>>
>>> (qemu) device_del cpu1
>>> device_del cpu1
>>> CPU hot unplug not supported on this machine
>>
>> Given the fact that I get the question about unplug _every_ time when I give 
>> a presentation
>> about KVM on z, I will try to get some architecture folks look at this. 
>> Maybe we can define
>> something very simple like "if the CPU is in the stopped state we can remove 
>> this and just
>> piggy back on the existing sclp EVENT_QUAL_CPU_CHANGE notification".
>>
>> So maybe add  "currently"
> 
> Unfortunately it might not be that easy.
> 
> We would have to find a way that existing OS's don't break. If a guest
> OS is not prepared for CPUs to get removed, we might run into
> inconsistencies when simply deleting CPUs that are in the STOPPED state.

Yes, this needs to be validated across all things.
> 
> Especially, these CPUs would still show up in the guest as "offline".
> Wonder what would then happen trying to "online" these.

The main use case seems to be, that the admin does not want to allow a guest
to online back a guest CPU if it was taken away from the configuration. 
So maybe we could simply fail a SIGP START for those.

Or we might go one level below and only allow an unplug if the CPU is in
the deconfigured state and we would then have to forbid the configuration
step. Right now SCLP_CMDW_(DE)CONFIGURE_CPU seems to be unimplemented in
QEMU.

Anyway, we need some architecture agreement here first (something that is
also ok with LPAR and z/VM).


> But yes, I can add "currently".
>