From: Igor Mammedov <imammedo@redhat.com>
To: "Dr. David Alan Gilbert (git)" <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 11:34:46 +0200 [thread overview]
Message-ID: <20220406113446.73ab4e1b@redhat.com> (raw)
In-Reply-To: <20220406083531.10217-1-dgilbert@redhat.com>
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
> 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?
> 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), \
next prev parent reply other threads:[~2022-04-06 9:36 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 [this message]
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
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=20220406113446.73ab4e1b@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 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).