[PATCH for-7.1 0/4] use dc->vmsd with spapr devices vmstate

Daniel Henrique Barboza posted 4 patches 2 years, 1 month ago
Test checkpatch passed
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/qemu tags/patchew/20220322183854.196063-1-danielhb413@gmail.com
Maintainers: "Cédric Le Goater" <clg@kaod.org>, Daniel Henrique Barboza <danielhb413@gmail.com>, David Gibson <david@gibson.dropbear.id.au>, Greg Kurz <groug@kaod.org>
There is a newer version of this series
hw/ppc/spapr_drc.c    | 13 ++++++-------
hw/ppc/spapr_iommu.c  |  7 +++----
hw/ppc/spapr_nvdimm.c | 11 ++---------
3 files changed, 11 insertions(+), 20 deletions(-)
[PATCH for-7.1 0/4] use dc->vmsd with spapr devices vmstate
Posted by Daniel Henrique Barboza 2 years, 1 month ago
Hi,

This short series converts some spapr devices to use the dc->vmsd
interface to register the vmstate. For most of them it was needed
to use qdev_set_legacy_instance_id() to keep compatibility with the
instance_id being used for awhile.

Although no functional changes were made the resulting code is a bit
shorter and maintainable. After these patches there are only 3 places
where vmstate_register() APIs are being used.

No behavior changes were detected when testing migration scenarios with
hotplug/unplug of devices.

Daniel Henrique Barboza (4):
  hw/ppc: use qdev to register logical DRC vmstates
  hw/ppc: use qdev to register physical DRC vmstates
  hw/ppc: use qdev to register spapr_iommu tcet vmstate
  hw/ppc: use qdev to register spapr_nvdimm vmsd

 hw/ppc/spapr_drc.c    | 13 ++++++-------
 hw/ppc/spapr_iommu.c  |  7 +++----
 hw/ppc/spapr_nvdimm.c | 11 ++---------
 3 files changed, 11 insertions(+), 20 deletions(-)

-- 
2.35.1
Re: [PATCH for-7.1 0/4] use dc->vmsd with spapr devices vmstate
Posted by David Gibson 2 years, 1 month ago
On Tue, Mar 22, 2022 at 03:38:50PM -0300, Daniel Henrique Barboza wrote:
> Hi,
> 
> This short series converts some spapr devices to use the dc->vmsd
> interface to register the vmstate. For most of them it was needed
> to use qdev_set_legacy_instance_id() to keep compatibility with the
> instance_id being used for awhile.
> 
> Although no functional changes were made the resulting code is a bit
> shorter and maintainable. After these patches there are only 3 places
> where vmstate_register() APIs are being used.
> 
> No behavior changes were detected when testing migration scenarios with
> hotplug/unplug of devices.

Looks good tome.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson
Re: [PATCH for-7.1 0/4] use dc->vmsd with spapr devices vmstate
Posted by Daniel Henrique Barboza 2 years, 1 month ago

On 3/22/22 22:49, David Gibson wrote:
> On Tue, Mar 22, 2022 at 03:38:50PM -0300, Daniel Henrique Barboza wrote:
>> Hi,
>>
>> This short series converts some spapr devices to use the dc->vmsd
>> interface to register the vmstate. For most of them it was needed
>> to use qdev_set_legacy_instance_id() to keep compatibility with the
>> instance_id being used for awhile.
>>
>> Although no functional changes were made the resulting code is a bit
>> shorter and maintainable. After these patches there are only 3 places
>> where vmstate_register() APIs are being used.
>>
>> No behavior changes were detected when testing migration scenarios with
>> hotplug/unplug of devices.
> 
> Looks good tome.

It looked good to me until, after further testing, I noticed that patch 03
breaks backward migration:

qemu_loadvm_state_section_startfull 560 (spapr_iommu) 0 2
qemu-system-ppc64: Unknown savevm section or instance 'spapr_iommu' 0. Make sure
that your current VM setup matches your saved VM setup, including any hotplugged devices

qemu-system-ppc64: load of migration failed: Invalid argument

I made a follow-up in the instance_id discussion [1] about it. For now patches 1-3 are
compromised. Only patch 04 is worth considering because the spapr_nvdimm device isn't
setting a custom instance_id.


[1] https://lists.gnu.org/archive/html/qemu-devel/2022-03/msg05942.html



Thanks,


Daniel

>