[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v2 17/19] s390x: CPU hot unplug via device_del c
From: |
Cornelia Huck |
Subject: |
Re: [Qemu-devel] [PATCH v2 17/19] s390x: CPU hot unplug via device_del cannot work |
Date: |
Tue, 5 Sep 2017 14:54:17 +0200 |
On Tue, 5 Sep 2017 14:14:21 +0200
Christian Borntraeger <address@hidden> wrote:
> 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.
Having the cpu in the unconfigured state as a requirement also makes
this less likely to break for older OSs, I guess.
> Right now SCLP_CMDW_(DE)CONFIGURE_CPU seems to be unimplemented in
> QEMU.
Sounds like something we'd like to have in the future?
(Btw, what does cpuplugd trigger? Offline/online or
deconfigure/configure?)
>
> Anyway, we need some architecture agreement here first (something that is
> also ok with LPAR and z/VM).
Certainly.
> > But yes, I can add "currently".
Yes, that makes sense.
- [Qemu-devel] [PATCH v2 15/19] s390x: print CPU definitions in sorted order, (continued)
Re: [Qemu-devel] [PATCH v2 17/19] s390x: CPU hot unplug via device_del cannot work, Matthew Rosato, 2017/09/06
[Qemu-devel] [PATCH v2 18/19] s390x: implement query-hotpluggable-cpus, David Hildenbrand, 2017/09/04
[Qemu-devel] [PATCH v2 19/19] s390x: get rid of cpu_s390x_create(), David Hildenbrand, 2017/09/04
Re: [Qemu-devel] [PATCH v2 00/19] s390x cleanups and CPU hotplug via device_add, Christian Borntraeger, 2017/09/05