Re: [PATCH V15 0/7] Add architecture agnostic code to support vCPU Hotplug

[Igor Mammedov <imammedo@redhat.com>]

On Tue, 16 Jul 2024 11:43:00 +0000
Salil Mehta <salil.mehta@huawei.com> wrote:

> Hi Igor,
> 
> >  From: Igor Mammedov <imammedo@redhat.com>
> >  Sent: Tuesday, July 16, 2024 10:52 AM
> >  To: Salil Mehta <salil.mehta@opnsrc.net>
> >  
> >  On Tue, 16 Jul 2024 03:38:29 +0000
> >  Salil Mehta <salil.mehta@opnsrc.net> wrote:
> >    
> >  > Hi Igor,
> >  >
> >  > On 15/07/2024 15:11, Igor Mammedov wrote:  
> >  > > On Mon, 15 Jul 2024 14:19:12 +0000
> >  > > Salil Mehta <salil.mehta@huawei.com> wrote:
> >  > >  
> >  > >>>   From: qemu-arm-bounces+salil.mehta=huawei.com@nongnu.org  <qemu-
> >  > >>>   arm-bounces+salil.mehta=huawei.com@nongnu.org> On Behalf Of  Salil
> >  > >>>   Mehta via
> >  > >>>   Sent: Monday, July 15, 2024 3:14 PM
> >  > >>>   To: Igor Mammedov <imammedo@redhat.com>
> >  > >>>
> >  > >>>   Hi Igor,
> >  > >>>  
> >  > >>>   >  From: Igor Mammedov <imammedo@redhat.com>
> >  > >>>   >  Sent: Monday, July 15, 2024 2:55 PM
> >  > >>>   >  To: Salil Mehta <salil.mehta@huawei.com>
> >  > >>>   >
> >  > >>>   >  On Sat, 13 Jul 2024 19:25:09 +0100
> >  > >>>   >  Salil Mehta <salil.mehta@huawei.com> wrote:
> >  > >>>   >  
> >  > >>>   >  > [Note: References are present at the last after the revision  
> >  > >>>   > history]  >  > Virtual CPU hotplug support is being added across
> >  > >>>   > various architectures  [1][3].  
> >  > >>>   >  > This series adds various code bits common across all architectures:
> >  > >>>   >  >
> >  > >>>   >  > 1. vCPU creation and Parking code refactor [Patch 1] 2. Update ACPI
> >  > >>>   > > GED framework to support vCPU Hotplug [Patch 2,3] 3. ACPI CPUs AML
> >  > >>>   > > code change [Patch 4,5] 4. Helper functions to support unrealization
> >  > >>>   > > of CPU objects [Patch 6,7]  
> >  > >>>   >
> >  > >>>   >  with patch 1 and 3 fixed should be good to go.
> >  > >>>   >
> >  > >>>   >  Salil,
> >  > >>>   >  Can you remind me what happened to migration part of this?
> >  > >>>   >  Ideally it should be a part of of this series as it should be common
> >  > >>>   > for  everything that uses GED and should be a conditional part of
> >  > >>>   > GED's  VMSTATE.
> >  > >>>   >
> >  > >>>   >  If this series is just a common base and no actual hotplug on top of
> >  > >>>   > it is  merged in this release (provided patch 13 is fixed), I'm fine
> >  > >>>   > with migration  bits being a separate series on top.
> >  > >>>   >
> >  > >>>   >  However if some machine would be introducing cpu hotplug in the same
> >  > >>>   > release, then the migration part should be merged before it or be a
> >  > >>>   > part  that cpu hotplug series.  
> >  > >>>
> >  > >>>   We have tested Live/Pseudo Migration and it seem to work with the
> >  > >>>   changes part of the architecture specific patch-set.  
> >  > >
> >  > > have you tested, migration from new QEMU to an older one (that doesn't have cpuhotplug builtin)?  
> >  >
> >  >
> >  > Just curious, how can we detect at source Qemu what version of the
> >  > Qemu destination is running. We require some sort of compatibility
> >  > check but then this is a problem not specific to CPU Hotplug?  
> >  
> >  it's usually managed by version machine types + compat settings for
> >  machine/device.  
> 
> Ok. it looks to be a static checking at the source. I'm sure there must be
> a way to dynamically do the same by negotiating the features i.e. only
> enabling the common subset at the destination. I quickly skimmed the
> migration code and I cannot find any thing like this being done as of now.
> And this problem looks to be a pandoras box to me. 
no dynamic negotiating as far as I'm aware.

We've managed to survive so far with static compat knobs
(with an occasional disaster along the way)

...
> 
> Thanks
> Salil.
>