qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	qemu-devel@nongnu.org, f4bug@amsat.org, aurelien@aurel32.net,
	jiaxun.yang@flygoat.com, ani@anisinha.ca, mst@redhat.com
Subject: Re: [PATCH for-7.1] hw/mips/malta: turn off x86 specific features of PIIX4_PM
Date: Fri, 29 Jul 2022 11:57:53 +0200	[thread overview]
Message-ID: <20220729115753.60d99772@redhat.com> (raw)
In-Reply-To: <CAFEAcA-H=P44_e9qbKiGiCXjs9JPCmhEK5qp23TLX229G=Y6rg@mail.gmail.com>

On Thu, 28 Jul 2022 16:12:34 +0100
Peter Maydell <peter.maydell@linaro.org> wrote:

> On Thu, 28 Jul 2022 at 16:09, Dr. David Alan Gilbert
> <dgilbert@redhat.com> wrote:
> >
> > * Igor Mammedov (imammedo@redhat.com) wrote:  
> > > On Thu, 28 Jul 2022 15:44:20 +0100
> > > "Dr. David Alan Gilbert" <dgilbert@redhat.com> wrote:
> > >  
> > > > * Igor Mammedov (imammedo@redhat.com) wrote:  
> > > > > QEMU crashes trying to save VMSTATE when only MIPS target are compiled in
> > > > >   $ qemu-system-mips -monitor stdio
> > > > >   (qemu) migrate "exec:gzip -c > STATEFILE.gz"
> > > > >   Segmentation fault (core dumped)
> > > > >
> > > > > It happens due to PIIX4_PM trying to parse hotplug vmstate structures
> > > > > which are valid only for x86 and not for MIPS (as it requires ACPI
> > > > > tables support which is not existent for ithe later)
> > > > >
> > > > > Issue was probably exposed by trying to cleanup/compile out unused
> > > > > ACPI bits from MIPS target (but forgetting about migration bits).
> > > > >
> > > > > Disable compiled out features using compat properties as the least
> > > > > risky way to deal with issue.  
> > > >
> > > > Isn't the problem partially due to a 'stub' vmsd which isn't terminated?  
> > >
> > > Not sure what "'stub' vmsd" is, can you explain?  
> >
> > In hw/acpi/acpi-pci-hotplug-stub.c there is :
> > const VMStateDescription vmstate_acpi_pcihp_pci_status;
I think that one is there only for linking purposes and not meant
to be actually used.

> > this seg happens when the migration code walks into that - this should
> > always get populated with some of the minimal fields, in particular the
> > .name and .fields array terminated with VMSTATE_END_OF_LIST().  
> 
> Either:
>  (1) we should be sure the vmstate struct does not get used if the
>      compile-time config has ended up with the stub
> or

>  (2) it needs to actually match the real vmstate struct, otherwise
>      migration between a QEMU built with a config that just got the
>      stub version and a QEMU built with a config that got the full
>      version will break
>
> This patch does the former. Segfaulting if we got something wrong
> and tried to use the vmstate when we weren't expecting to is
> arguably better than producing an incompatible migration stream.

> (Better still would be if we caught this on machine startup rather
> than only when savevm was invoked.)
Theoretically possible with a bunch of mips and x86 stubs, but ...
we typically don't do this kind of checks for migration sake
as that complicates things a lot in general.
i.e. it's common to let migration fail in case of incompatible
migration stream. It's not exactly friendly to user but it's
graceful failure (assuming code is correct and not crashes QEMU)
 
> thanks
> -- PMM
> 



  reply	other threads:[~2022-07-29 10:00 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-28 11:50 [PATCH for-7.1] hw/mips/malta: turn off x86 specific features of PIIX4_PM Igor Mammedov
2022-07-28 12:29 ` Peter Maydell
2022-07-28 13:16   ` Igor Mammedov
2022-08-02  6:34     ` Philippe Mathieu-Daudé via
2022-08-03 17:26       ` Bernhard Beschow
2022-08-03 18:00         ` Peter Maydell
2022-08-04 21:32           ` BB
2022-08-08 12:15         ` Igor Mammedov
2022-08-08 17:57           ` BB
2022-08-08 18:02             ` Peter Maydell
2022-08-08 21:28               ` BB
2022-08-09  7:27             ` Igor Mammedov
2022-07-28 18:50   ` Ani Sinha
2022-07-28 14:44 ` Dr. David Alan Gilbert
2022-07-28 14:54   ` Igor Mammedov
2022-07-28 15:09     ` Dr. David Alan Gilbert
2022-07-28 15:12       ` Peter Maydell
2022-07-29  9:57         ` Igor Mammedov [this message]
2022-07-29 10:17           ` Peter Maydell
2022-08-01  9:17             ` Dr. David Alan Gilbert
2022-08-01  9:43               ` Peter Maydell
2022-07-28 15:04   ` Peter Maydell
2022-07-28 18:48     ` Ani Sinha
2022-07-29  8:09     ` Igor Mammedov
2022-08-03 22:00 ` Michael S. Tsirkin
2022-08-04  6:44   ` Ani Sinha
2022-08-08 21:24 ` Philippe Mathieu-Daudé via

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=20220729115753.60d99772@redhat.com \
    --to=imammedo@redhat.com \
    --cc=ani@anisinha.ca \
    --cc=aurelien@aurel32.net \
    --cc=dgilbert@redhat.com \
    --cc=f4bug@amsat.org \
    --cc=jiaxun.yang@flygoat.com \
    --cc=mst@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /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).