From: Juan Quintela <quintela@redhat.com>
To: Greg Kurz <groug@kaod.org>
Cc: qemu-devel@nongnu.org,
"Stefan Berger" <stefanb@linux.vnet.ibm.com>,
"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
qemu-ppc@nongnu.org, "Nicholas Piggin" <npiggin@gmail.com>,
qemu-s390x@nongnu.org, "Gerd Hoffmann" <kraxel@redhat.com>,
"Corey Minyard" <cminyard@mvista.com>,
"Samuel Thibault" <samuel.thibault@ens-lyon.org>,
"Richard Henderson" <richard.henderson@linaro.org>,
"David Hildenbrand" <david@redhat.com>,
"Ilya Leoshkevich" <iii@linux.ibm.com>,
"Fabiano Rosas" <farosas@suse.de>,
"Eric Farman" <farman@linux.ibm.com>,
"Peter Xu" <peterx@redhat.com>,
"Harsh Prateek Bora" <harshpb@linux.ibm.com>,
"John Snow" <jsnow@redhat.com>,
qemu-block@nongnu.org,
"Mark Cave-Ayland" <mark.cave-ayland@ilande.co.uk>,
"Christian Borntraeger" <borntraeger@linux.ibm.com>,
"Marc-André Lureau" <marcandre.lureau@redhat.com>,
"Stefan Weil" <sw@weilnetz.de>,
qemu-arm@nongnu.org, "Jason Wang" <jasowang@redhat.com>,
"Corey Minyard" <minyard@acm.org>,
"Leonardo Bras" <leobras@redhat.com>,
"Thomas Huth" <thuth@redhat.com>,
"Peter Maydell" <peter.maydell@linaro.org>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Cédric Le Goater" <clg@kaod.org>,
"David Gibson" <david@gibson.dropbear.id.au>,
"Halil Pasic" <pasic@linux.ibm.com>,
"Daniel Henrique Barboza" <danielhb413@gmail.com>
Subject: Re: [PATCH 07/13] RFC migration: icp/server is a mess
Date: Fri, 20 Oct 2023 10:57:49 +0200 [thread overview]
Message-ID: <87fs251xiq.fsf@secure.mitica> (raw)
In-Reply-To: <20231020100626.57debfa4@bahia> (Greg Kurz's message of "Fri, 20 Oct 2023 10:06:26 +0200")
Greg Kurz <groug@kaod.org> wrote:
> On Fri, 20 Oct 2023 09:30:44 +0200
> Juan Quintela <quintela@redhat.com> wrote:
>
>> Greg Kurz <groug@kaod.org> wrote:
>> > On Thu, 19 Oct 2023 21:08:25 +0200
>> > Juan Quintela <quintela@redhat.com> wrote:
>> >
>> >> Current code does:
>> >> - register pre_2_10_vmstate_dummy_icp with "icp/server" and instance
>> >> dependinfg on cpu number
>> >> - for newer machines, it register vmstate_icp with "icp/server" name
>> >> and instance 0
>> >> - now it unregisters "icp/server" for the 1st instance.
>> >>
>> >> This is wrong at many levels:
>> >> - we shouldn't have two VMSTATEDescriptions with the same name
>> >> - In case this is the only solution that we can came with, it needs to
>> >> be:
>> >> * register pre_2_10_vmstate_dummy_icp
>> >> * unregister pre_2_10_vmstate_dummy_icp
>> >> * register real vmstate_icp
>> >>
>> >> As the initialization of this machine is already complex enough, I
>> >> need help from PPC maintainers to fix this.
>> >>
>> >> Volunteers?
>> >>
>> >> CC: Cedric Le Goater <clg@kaod.org>
>> >> CC: Daniel Henrique Barboza <danielhb413@gmail.com>
>> >> CC: David Gibson <david@gibson.dropbear.id.au>
>> >> CC: Greg Kurz <groug@kaod.org>
>> >>
>> >> Signed-off-by: Juan Quintela <quintela@redhat.com>
>> >> ---
>> >> hw/ppc/spapr.c | 7 ++++++-
>> >> 1 file changed, 6 insertions(+), 1 deletion(-)
>> >>
>> >> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
>> >> index cb840676d3..8531d13492 100644
>> >> --- a/hw/ppc/spapr.c
>> >> +++ b/hw/ppc/spapr.c
>> >> @@ -143,7 +143,12 @@ static bool pre_2_10_vmstate_dummy_icp_needed(void *opaque)
>> >> }
>> >>
>> >> static const VMStateDescription pre_2_10_vmstate_dummy_icp = {
>> >> - .name = "icp/server",
>> >> + /*
>> >> + * Hack ahead. We can't have two devices with the same name and
>> >> + * instance id. So I rename this to pass make check.
>> >> + * Real help from people who knows the hardware is needed.
>> >> + */
>> >> + .name = "pre-2.10-icp/server",
>> >> .version_id = 1,
>> >> .minimum_version_id = 1,
>> >> .needed = pre_2_10_vmstate_dummy_icp_needed,
>> >
>> > I guess this fix is acceptable as well and a lot simpler than
>> > reverting the hack actually. Outcome is the same : drop
>> > compat with pseries-2.9 and older.
>> >
>> > Reviewed-by: Greg Kurz <groug@kaod.org>
>>
>> I fully agree with you here.
>> The other options given on this thread is deprecate that machines, but I
>> would like to have this series sooner than 2 releases.
>
> Yeah and, especially, the deprecation of all these machine types is
> itself a massive chunk of work as it will call to identify and
> remove other related workarounds as well. Given that pretty much
> everyone working in PPC/PAPR moved away, can the community handle
> such a big change ?
>
>> And what ppc is
>> doing here is (and has always been) a hack and an abuse about how
>> vmstate registrations is supposed to work.
>>
>
> Sorry again... We should have involved migration experts at the time. :-)
I would have told you that this can't be done O:-)
Sent another version with a vmstate hack to accomodate this. You don't
have to deprecate the machines due to migration O:-)
And now that I have ppc gurus attention, could you comment in the other
question:
./hw/ppc/spapr_iommu.c
static void spapr_tce_table_realize(DeviceState *dev, Error **errp)
{
...
vmstate_register(VMSTATE_IF(tcet), tcet->liobn, &vmstate_spapr_tce_table,
tcet);
}
./include/hw/ppc/spapr.h
struct SpaprTceTable {
...
uint32_t liobn;
....
};
./include/migration.h
static inline int vmstate_register(VMStateIf *obj, int instance_id,
const VMStateDescription *vmsd,
void *opaque);
liobn is an uint32_t and insntance_id is an int.
For this series, I started with this:
static inline int vmstate_register(VMStateIf *obj, int instance_id,
const VMStateDescription *vmsd,
void *opaque)
{
if (instance_id < 0) {
error_report("vmstate_register: Invalid device: %s instance_id: %d",
vmsd->name, instance_id);
return -1;
}
return vmstate_register_with_alias_id(obj, instance_id, vmsd,
opaque, -1, 0, NULL);
}
And it failed on this. So I change the test to
if (instance_id == VM_INSTANCE_ID_ANY) {
....
}
But we are still having troubles with signs here.
Posible actions:
- Look the other side and hope that liobn is never -1.
(if it is -1, it would become 0, so not really a big trouble).
- change vmstate type to uint32_t and make VM_INSTANCE_ID_ANY to UINT32_MAX
(exact same problem if liobn happens to be UINT32_MAX)
I have no clue what are the valid values of liobn. So I am leaning to
just look the other way and do nothing.
Advise?
Thanks, Juan.
next prev parent reply other threads:[~2023-10-20 8:58 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-19 19:08 [PATCH 00/13] migration: Check for duplicates on vmstate_register() Juan Quintela
2023-10-19 19:08 ` [PATCH 01/13] migration: Create vmstate_register_any() Juan Quintela
2023-10-19 20:18 ` Stefan Berger
2023-10-19 19:08 ` [PATCH 02/13] migration: Use vmstate_register_any() Juan Quintela
2023-10-19 20:18 ` Stefan Berger
2023-10-19 19:08 ` [PATCH 03/13] migration: Use vmstate_register_any() for isa-ide Juan Quintela
2023-10-19 20:19 ` Stefan Berger
2023-10-19 19:08 ` [PATCH 04/13] migration: Use vmstate_register_any() for ipmi-bt* Juan Quintela
2023-10-19 20:20 ` Stefan Berger
2023-10-19 19:08 ` [PATCH 05/13] migration: Use VMSTATE_INSTANCE_ID_ANY for slirp Juan Quintela
2023-10-19 20:29 ` Stefan Berger
2023-10-19 19:08 ` [PATCH 06/13] migration: Use VMSTATE_INSTANCE_ID_ANY for s390 devices Juan Quintela
2023-10-19 20:30 ` Stefan Berger
2023-10-19 19:08 ` [PATCH 07/13] RFC migration: icp/server is a mess Juan Quintela
2023-10-19 20:49 ` Greg Kurz
2023-10-19 21:15 ` Cédric Le Goater
2023-10-20 5:10 ` Thomas Huth
2023-10-20 7:39 ` Cédric Le Goater
2023-10-19 21:39 ` Greg Kurz
2023-10-20 7:30 ` Juan Quintela
2023-10-20 8:06 ` Greg Kurz
2023-10-20 8:12 ` Thomas Huth
2023-10-20 8:57 ` Juan Quintela [this message]
2023-10-20 7:49 ` Nicholas Piggin
2023-10-20 8:33 ` Juan Quintela
2023-10-20 8:33 ` Greg Kurz
2023-10-20 10:21 ` Nicholas Piggin
2023-10-19 19:08 ` [PATCH 08/13] migration: vmstate_register() check that instance_id is valid Juan Quintela
2023-10-19 19:08 ` [PATCH 09/13] migration: Check in savevm_state_handler_insert for dups Juan Quintela
2023-10-19 19:08 ` [PATCH 10/13] migration: Improve example and documentation of vmstate_register() Juan Quintela
2023-10-19 20:38 ` Stefan Berger
2023-10-20 9:03 ` Juan Quintela
2023-10-19 19:08 ` [PATCH 11/13] migration: Use vmstate_register_any() for audio Juan Quintela
2023-10-19 20:39 ` Stefan Berger
2023-10-19 19:08 ` [PATCH 12/13] migration: Use vmstate_register_any() for eeprom93xx Juan Quintela
2023-10-19 20:39 ` Stefan Berger
2023-10-19 19:08 ` [PATCH 13/13] migration: Use vmstate_register_any() for vmware_vga Juan Quintela
2023-10-19 20:42 ` Stefan Berger
2023-10-20 7:33 ` Juan Quintela
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=87fs251xiq.fsf@secure.mitica \
--to=quintela@redhat.com \
--cc=borntraeger@linux.ibm.com \
--cc=clg@kaod.org \
--cc=cminyard@mvista.com \
--cc=danielhb413@gmail.com \
--cc=david@gibson.dropbear.id.au \
--cc=david@redhat.com \
--cc=farman@linux.ibm.com \
--cc=farosas@suse.de \
--cc=groug@kaod.org \
--cc=harshpb@linux.ibm.com \
--cc=iii@linux.ibm.com \
--cc=jasowang@redhat.com \
--cc=jsnow@redhat.com \
--cc=kraxel@redhat.com \
--cc=leobras@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=marcel.apfelbaum@gmail.com \
--cc=mark.cave-ayland@ilande.co.uk \
--cc=minyard@acm.org \
--cc=mst@redhat.com \
--cc=npiggin@gmail.com \
--cc=pasic@linux.ibm.com \
--cc=peter.maydell@linaro.org \
--cc=peterx@redhat.com \
--cc=qemu-arm@nongnu.org \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=qemu-s390x@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=samuel.thibault@ens-lyon.org \
--cc=stefanb@linux.vnet.ibm.com \
--cc=sw@weilnetz.de \
--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).