From: Shalini Chellathurai Saroja <shalini@linux.ibm.com>
To: Thomas Huth <thuth@redhat.com>
Cc: qemu-s390x mailing list <qemu-s390x@nongnu.org>,
qemu-devel mailing list <qemu-devel@nongnu.org>,
Nina Schoetterl-Glausch <nsg@linux.ibm.com>,
Hendrik Brueckner <brueckner@linux.ibm.com>,
"<Shalini Chellathurai Saroja" <shalini@linux.ibm.com>
Subject: Re: [PATCH qemu v2 3/3] hw/s390x: support migration of CPI values
Date: Fri, 07 Mar 2025 09:04:52 +0100 [thread overview]
Message-ID: <77054e690f8bb6ddf84bb869d00fe6e9@linux.ibm.com> (raw)
In-Reply-To: <020b1851-1249-446f-844c-2bc598128446@redhat.com>
On 2025-03-06 16:08, Thomas Huth wrote:
> On 06/03/2025 15.10, shalini wrote:
>> On 2025-03-05 19:33, Thomas Huth wrote:
>>> On 24/02/2025 13.04, Shalini Chellathurai Saroja wrote:
>>>> Register Control-Program Identification data with the live
>>>> migration infrastructure.
>>>>
>>>> Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.ibm.com>
>>>> Reviewed-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com>
>>>> ---
>>>> hw/s390x/s390-virtio-ccw.c | 17 +++++++++++++++++
>>>> 1 file changed, 17 insertions(+)
>>>>
>>>> diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
>>>> index 13ea8db1b0..4d0838d037 100644
>>>> --- a/hw/s390x/s390-virtio-ccw.c
>>>> +++ b/hw/s390x/s390-virtio-ccw.c
>>>> @@ -260,6 +260,20 @@ static void s390_create_sclpconsole(SCLPDevice
>>>> *sclp,
>>>> qdev_realize_and_unref(dev, ev_fac_bus, &error_fatal);
>>>> }
>>>> +static const VMStateDescription vmstate_control_program_id = {
>>>> + .name = "s390_control_program_id",
>>>> + .version_id = 0,
>>>> + .minimum_version_id = 0,
>>>> + .fields = (const VMStateField[]) {
>>>> + VMSTATE_UINT8_ARRAY(system_type, ControlProgramId, 8),
>>>> + VMSTATE_UINT8_ARRAY(system_name, ControlProgramId, 8),
>>>> + VMSTATE_UINT64(system_level, ControlProgramId),
>>>> + VMSTATE_UINT8_ARRAY(sysplex_name, ControlProgramId, 8),
>>>> + VMSTATE_UINT64(timestamp, ControlProgramId),
>>>> + VMSTATE_END_OF_LIST()
>>>> + }
>>>> +};
>>>> +
>>>> static void ccw_init(MachineState *machine)
>>>> {
>>>> MachineClass *mc = MACHINE_GET_CLASS(machine);
>>>> @@ -308,6 +322,9 @@ static void ccw_init(MachineState *machine)
>>>> ret = css_create_css_image(VIRTUAL_CSSID, true);
>>>> assert(ret == 0);
>>>> + /* register CPI values */
>>>> + vmstate_register_any(NULL, &vmstate_control_program_id,
>>>> &ms->cpi);
>>>
>>> Hi again,
>>>
>>> after looking at this for a while, I think it might be cleaner to
>>> store the state in the TYPE_SCLP_CPI device instead of storing it in
>>> the machine state. Then you can also use dc->vmsd there instead of
>>> using the legacy vmstate_register_any() function.
>>>
>>
>> Hello Thomas,
>>
>> The SCLP event type CPI is used to transfer the data mentioned below
>> from guest operating system to QEMU. The job of the CPI event is
>> complete, when this transfer is done.
>>
>> The received data must be saved in the QEMU object model, so that it
>> is possible for the user to retrieve the data via QMP. The received
>> data provides information about the guest virtual machine.
>>
>> System type - Operating system of the guest (eg: LINUX)
>> System name - Hostname provided to the guest (eg: TESTVM)
>> System level - Kernel version of the guest operating system (eg:
>> 0x50e00)
>> Sysplex name - Sysplex refers to a cluster of logical partitions that
>> communicates and co-operates with each other. Sysplex name is the name
>> of the cluster which the guest belongs to(If any).(eg: PLEX)
>>
>> In my perspective, I believe that the s390 machine state is
>> appropriate for storing the data about the guest virtual machine.
>> Please do let me know if you still want to change this?, thank you.
>
> Hi Shalini,
>
> yes, please change this patch to put the migration state into the
> SCLP_CPI device.
>
> vmstate_register_any() is a legacy function, see its description in
> include/migration/vmstate.h ... so if anyhow possible, this should be
> avoided in new code.
>
> You introduced a new device in patch 2 which will be handling the
> related data. Devices are the right place for storing migration data
> in new QEMU code, so I think this really should go into dc->vmsd of
> TYPE_SCLP_CPI.
>
> For retrieving the information, the user should then just get the
> property from /machine/sclp/s390-sclp-event-facility/sclpcpi instead
> of /machine. This should be fine since it is a well-defined location,
> too.
>
Good Morning Thomas,
Thank you very much for the explanation. I will change this.
> Thanks!
> Thomas
--
Mit freundlichen Grüßen / Kind regards
Shalini Chellathurai Saroja
Software Developer
Linux on IBM Z & KVM Development
IBM Deutschland Research & Development GmbH
Dept 1419, Schoenaicher Str. 220, 71032 Boeblingen
Vorsitzender des Aufsichtsrats: Wolfgang Wendt
Geschäftsführung: David Faller
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht
Stuttgart, HRB 243294
next prev parent reply other threads:[~2025-03-07 8:32 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-24 12:04 [PATCH qemu v2 1/3] hw/s390x: add CPI identifiers to QOM Shalini Chellathurai Saroja
2025-02-24 12:04 ` [PATCH qemu v2 2/3] hw/s390x: add SCLP event type CPI Shalini Chellathurai Saroja
2025-03-05 18:04 ` Thomas Huth
2025-03-05 19:00 ` Nina Schoetterl-Glausch
2025-03-06 8:07 ` shalini
2025-03-06 8:04 ` shalini
2025-02-24 12:04 ` [PATCH qemu v2 3/3] hw/s390x: support migration of CPI values Shalini Chellathurai Saroja
2025-03-05 18:33 ` Thomas Huth
2025-03-06 14:10 ` shalini
2025-03-06 15:08 ` Thomas Huth
2025-03-07 8:04 ` Shalini Chellathurai Saroja [this message]
2025-03-07 15:29 ` Shalini Chellathurai Saroja
2025-03-05 15:56 ` [PATCH qemu v2 1/3] hw/s390x: add CPI identifiers to QOM Thomas Huth
2025-03-06 12:23 ` shalini
2025-03-06 14:55 ` Thomas Huth
2025-03-06 15:44 ` Nina Schoetterl-Glausch
2025-03-06 16:05 ` Daniel P. Berrangé
2025-03-10 15:16 ` Shalini Chellathurai Saroja
2025-03-05 16:06 ` Daniel P. Berrangé
2025-03-06 13:55 ` shalini
2025-03-06 15:06 ` Daniel P. Berrangé
2025-03-06 15:36 ` Nina Schoetterl-Glausch
2025-03-07 15:22 ` Shalini Chellathurai Saroja
2025-03-05 18:05 ` Thomas Huth
2025-03-06 13:57 ` shalini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=77054e690f8bb6ddf84bb869d00fe6e9@linux.ibm.com \
--to=shalini@linux.ibm.com \
--cc=brueckner@linux.ibm.com \
--cc=nsg@linux.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-s390x@nongnu.org \
--cc=thuth@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).