On Tue, 16 Jul 2024 11:43:00 +0000 Salil Mehta <salil.me...@huawei.com> wrote:
> Hi Igor, > > > From: Igor Mammedov <imamm...@redhat.com> > > Sent: Tuesday, July 16, 2024 10:52 AM > > To: Salil Mehta <salil.me...@opnsrc.net> > > > > On Tue, 16 Jul 2024 03:38:29 +0000 > > Salil Mehta <salil.me...@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.me...@huawei.com> wrote: > > > > > > > >>> From: qemu-arm-bounces+salil.mehta=huawei....@nongnu.org <qemu- > > > >>> arm-bounces+salil.mehta=huawei....@nongnu.org> On Behalf Of Salil > > > >>> Mehta via > > > >>> Sent: Monday, July 15, 2024 3:14 PM > > > >>> To: Igor Mammedov <imamm...@redhat.com> > > > >>> > > > >>> Hi Igor, > > > >>> > > > >>> > From: Igor Mammedov <imamm...@redhat.com> > > > >>> > Sent: Monday, July 15, 2024 2:55 PM > > > >>> > To: Salil Mehta <salil.me...@huawei.com> > > > >>> > > > > >>> > On Sat, 13 Jul 2024 19:25:09 +0100 > > > >>> > Salil Mehta <salil.me...@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. >
