All of lore.kernel.org
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: peter.maydell@linaro.org, quintela@redhat.com, mst@redhat.com,
	qemu-devel@nongnu.org, peterx@redhat.com,
	alex.williamson@redhat.com, leobras@redhat.com
Subject: Re: [PATCH] acpi: Bodge acpi_index migration
Date: Wed, 6 Apr 2022 17:59:39 +0200	[thread overview]
Message-ID: <20220406175939.39d9a277@redhat.com> (raw)
In-Reply-To: <Yk1fq+B9RD+9+4I3@work-vm>

On Wed, 6 Apr 2022 10:38:51 +0100
"Dr. David Alan Gilbert" <dgilbert@redhat.com> wrote:

> * Igor Mammedov (imammedo@redhat.com) wrote:
> > On Wed,  6 Apr 2022 09:35:31 +0100
> > "Dr. David Alan Gilbert (git)" <dgilbert@redhat.com> wrote:
> >   
> > > From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
> > > 
> > > The 'acpi_index' field is a statically configured field, which for
> > > some reason is migrated; this never makes much sense because it's
> > > command line static.  
> > 
> > that's true only for the field that's part of PCIDEvice,
> > however AcpiPciHpState::acpi_index is runtime state and _must_
> > be migrated if set, otherwise guest might get wrong index
> > if it's in process of querying it  
> 
> So this patch only changes the piix4.c version; I'm confused, is there
> a AcpiPciHpState::acpi_index that's runtime setable in there?

> > >          VMSTATE_PCI_HOTPLUG(acpi_pci_hotplug, PIIX4PMState,
                                    ^^^ AcpiPciHpState
> > >                              vmstate_test_use_acpi_hotplug_bridge,
> > > -                            vmstate_acpi_pcihp_use_acpi_index),

hw/acpi/pcihp.c:pci_write():
   s->acpi_index = object_property_get_uint(o, "acpi-index", NULL);

s->acpi_index is runtime value that is supposed to be migrated if it's set
to something other then 0

I may have botched VMSTATE_PCI_HOTPLUG, intent was to migrate
AcpiPciHpState::acpi_index if necessary. But I'm not sure how
if I used correct approach for to migrate an optional value
i.e.  maybe instead of VMSTATE_UINT32_TEST(pcihp.acpi_index, state, test_acpi_index)
I should've used subsection, because destination has no clue if
acpi_index would be transmitted over wire or not?
    
> > > However, on piix4 it's conditional, and the condition/test function
> > > ends up having the wrong pointer passed to it (it gets a PIIX4PMState
> > > not the AcpiPciHpState it was expecting, because VMSTATE_PCI_HOTPLUG
> > > is a macro and not another struct).  This means the field is randomly
> > > loaded/saved based on a random pointer.  In 6.x this random pointer
> > > randomly seems to get 0 for everyone (!); in 7.0rc it's getting junk
> > > and trying to load a field that the source didn't send.  The migration
> > > stream gets out of line and hits the section footer.  
> > 
> > I'm a bit confused by description,
> > do you have a reproducer for me to try?  
> 
> Yeh, see the linked gitlab case command line:
>   https://gitlab.com/qemu-project/qemu/-/issues/932
> 
> ./x86_64-softmmu/qemu-system-x86_64 -M pc-q35-6.2 -m 512 -device virtio-scsi-pci,id=scsihw0,bus=pcie.0,addr=0x5,acpi-index=3 -drive if=none,my.qcow2,format=qcow2,id=drive-scsi0,node-name=scsi0 -device 'scsi-hd,bus=scsihw0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0,id=scsi0'  -nographic
> 
> just migrating from a 6.2 to a head triggers this.

Over here any migration from qemu-6.2 to HEAD at 3d31fe4d662f13c7
fails even without acpi-index, as simple as this:

qemu-system-x86_64-6.2 -M pc-i440fx-6.2  -m 512 -vnc :0 -monitor stdio
(qemu) stop
(qemu) migrate "exec:gzip -c > STATEFILE.gz"

qemu-system-x86_64-7.0 -M pc-i440fx-6.2  -m 512 -vnc :0 -monitor stdio -incoming "exec: gzip -c -d STATEFILE.gz"

(qemu) qemu-system-x86_64-7.0: Missing section footer for 0000:00:01.3/piix4_pm
qemu-system-x86_64-7.0: load of migration failed: Invalid argument


Like you pointed out in gitlab issue, vmstate_acpi_pcihp_use_acpi_index
is broken. Following applied to HEAD should fix immediate issue on destination
reading random value:

diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
index f0b5fac44a..c97db491c8 100644
--- a/hw/acpi/piix4.c
+++ b/hw/acpi/piix4.c
@@ -269,6 +269,11 @@ static bool piix4_vmstate_need_smbus(void *opaque, int version_id)
     return pm_smbus_vmstate_needed();
 }
 
+static bool vmstate_piix4_need_acpi_index(void *opaque, int version_id)
+{
+    PIIX4PMState *s = PIIX4_PM(opaque);
+    return vmstate_acpi_pcihp_use_acpi_index(&(s->acpi_pci_hotplug), version_id);
+}
 /* qemu-kvm 1.2 uses version 3 but advertised as 2
  * To support incoming qemu-kvm 1.2 migration, change version_id
  * and minimum_version_id to 2 below (which breaks migration from
@@ -299,7 +304,7 @@ static const VMStateDescription vmstate_acpi = {
             struct AcpiPciHpPciStatus),
         VMSTATE_PCI_HOTPLUG(acpi_pci_hotplug, PIIX4PMState,
                             vmstate_test_use_acpi_hotplug_bridge,
-                            vmstate_acpi_pcihp_use_acpi_index),
+                            vmstate_piix4_need_acpi_index),
         VMSTATE_END_OF_LIST()
     },
     .subsections = (const VMStateDescription*[]) {


> Dave
> 
> > > The bodge is on piix4 never to load the field:
> > >   a) Most 6.x builds never send it, so most of the time the migration
> > >     will work.
> > >   b) We can backport this fix to 6.x to remove the boobytrap.
> > >   c) It should never have made a difference anyway since the acpi-index
> > >     is command line configured and should be correct on the destination
> > >     anyway
> > >   d) ich9 is still sending/receiving this (unconditionally all the time)
> > >     but due to (c) should never notice.  We could follow up to make it
> > >     skip.
> > > 
> > > It worries me just when (a) actually happens.
> > > 
> > > Fixes: b32bd76 ("pci: introduce acpi-index property for PCI device")
> > > Resolves: https://gitlab.com/qemu-project/qemu/-/issues/932
> > > 
> > > Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
> > > ---
> > >  hw/acpi/acpi-pci-hotplug-stub.c |  4 ----
> > >  hw/acpi/pcihp.c                 |  6 ------
> > >  hw/acpi/piix4.c                 | 11 ++++++++++-
> > >  include/hw/acpi/pcihp.h         |  2 --
> > >  4 files changed, 10 insertions(+), 13 deletions(-)
> > > 
> > > diff --git a/hw/acpi/acpi-pci-hotplug-stub.c b/hw/acpi/acpi-pci-hotplug-stub.c
> > > index 734e4c5986..a43f6dafc9 100644
> > > --- a/hw/acpi/acpi-pci-hotplug-stub.c
> > > +++ b/hw/acpi/acpi-pci-hotplug-stub.c
> > > @@ -41,7 +41,3 @@ void acpi_pcihp_reset(AcpiPciHpState *s, bool acpihp_root_off)
> > >      return;
> > >  }
> > >  
> > > -bool vmstate_acpi_pcihp_use_acpi_index(void *opaque, int version_id)
> > > -{
> > > -    return false;
> > > -}
> > > diff --git a/hw/acpi/pcihp.c b/hw/acpi/pcihp.c
> > > index 6351bd3424..bf65bbea49 100644
> > > --- a/hw/acpi/pcihp.c
> > > +++ b/hw/acpi/pcihp.c
> > > @@ -554,12 +554,6 @@ void acpi_pcihp_init(Object *owner, AcpiPciHpState *s, PCIBus *root_bus,
> > >                                     OBJ_PROP_FLAG_READ);
> > >  }
> > >  
> > > -bool vmstate_acpi_pcihp_use_acpi_index(void *opaque, int version_id)
> > > -{
> > > -     AcpiPciHpState *s = opaque;
> > > -     return s->acpi_index;
> > > -}
> > > -
> > >  const VMStateDescription vmstate_acpi_pcihp_pci_status = {
> > >      .name = "acpi_pcihp_pci_status",
> > >      .version_id = 1,
> > > diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
> > > index cc37fa3416..48aeedd5f0 100644
> > > --- a/hw/acpi/piix4.c
> > > +++ b/hw/acpi/piix4.c
> > > @@ -267,6 +267,15 @@ static bool piix4_vmstate_need_smbus(void *opaque, int version_id)
> > >      return pm_smbus_vmstate_needed();
> > >  }
> > >  
> > > +/*
> > > + * This is a fudge to turn off the acpi_index field, whose
> > > + * test was always broken on piix4.
> > > + */
> > > +static bool vmstate_test_never(void *opaque, int version_id)
> > > +{
> > > +    return false;
> > > +}
> > > +
> > >  /* qemu-kvm 1.2 uses version 3 but advertised as 2
> > >   * To support incoming qemu-kvm 1.2 migration, change version_id
> > >   * and minimum_version_id to 2 below (which breaks migration from
> > > @@ -297,7 +306,7 @@ static const VMStateDescription vmstate_acpi = {
> > >              struct AcpiPciHpPciStatus),
> > >          VMSTATE_PCI_HOTPLUG(acpi_pci_hotplug, PIIX4PMState,
> > >                              vmstate_test_use_acpi_hotplug_bridge,
> > > -                            vmstate_acpi_pcihp_use_acpi_index),
> > > +                            vmstate_test_never),
> > >          VMSTATE_END_OF_LIST()
> > >      },
> > >      .subsections = (const VMStateDescription*[]) {
> > > diff --git a/include/hw/acpi/pcihp.h b/include/hw/acpi/pcihp.h
> > > index af1a169fc3..7e268c2c9c 100644
> > > --- a/include/hw/acpi/pcihp.h
> > > +++ b/include/hw/acpi/pcihp.h
> > > @@ -73,8 +73,6 @@ void acpi_pcihp_reset(AcpiPciHpState *s, bool acpihp_root_off);
> > >  
> > >  extern const VMStateDescription vmstate_acpi_pcihp_pci_status;
> > >  
> > > -bool vmstate_acpi_pcihp_use_acpi_index(void *opaque, int version_id);
> > > -
> > >  #define VMSTATE_PCI_HOTPLUG(pcihp, state, test_pcihp, test_acpi_index) \
> > >          VMSTATE_UINT32_TEST(pcihp.hotplug_select, state, \
> > >                              test_pcihp), \  
> >   



  parent reply	other threads:[~2022-04-06 16:02 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-06  8:35 [PATCH] acpi: Bodge acpi_index migration Dr. David Alan Gilbert (git)
2022-04-06  9:34 ` Igor Mammedov
2022-04-06  9:38   ` Dr. David Alan Gilbert
2022-04-06  9:44     ` Dr. David Alan Gilbert
2022-04-06 15:32       ` Michael S. Tsirkin
2022-04-06 15:59     ` Igor Mammedov [this message]
2022-04-06 16:11       ` Dr. David Alan Gilbert
2022-04-06 16:52         ` Igor Mammedov
2022-04-06 17:36           ` Dr. David Alan Gilbert
2022-04-06 18:02             ` Igor Mammedov
  -- strict thread matches above, loose matches on Subject: below --
2022-04-06  8:25 Dr. David Alan Gilbert (git)
2022-04-06  8:27 ` Dr. David Alan Gilbert
2022-04-05 19:06 Dr. David Alan Gilbert (git)
2022-04-05 21:02 ` Alex Williamson
2022-04-06  8:53   ` Dr. David Alan Gilbert
2022-04-05 21:12 ` Michael S. Tsirkin
2022-04-06  8:14   ` Dr. David Alan Gilbert
2022-04-06  8:38   ` Dr. David Alan Gilbert
2022-04-06  6:38 ` Fabian Ebner
2022-04-06  6:45 ` Marc-André Lureau

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=20220406175939.39d9a277@redhat.com \
    --to=imammedo@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=leobras@redhat.com \
    --cc=mst@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.