All of lore.kernel.org
 help / color / mirror / Atom feed
From: Juan Quintela <quintela@redhat.com>
To: Fiona Ebner <f.ebner@proxmox.com>
Cc: QEMU Developers <qemu-devel@nongnu.org>,
	 Peter Xu <peterx@redhat.com>,
	leobras@redhat.com,  Jonathan.Cameron@huawei.com,
	 dave.jiang@intel.com, fan.ni@samsung.com,
	 "Michael S . Tsirkin" <mst@redhat.com>,
	 Thomas Lamprecht <t.lamprecht@proxmox.com>
Subject: Re: Question about issue #1576: Migration from v8.0.0-rc2 to v7.2.0 with pcie-root-port device fails
Date: Wed, 10 May 2023 14:19:31 +0200	[thread overview]
Message-ID: <87mt2c8jl8.fsf@secure.mitica> (raw)
In-Reply-To: <13090490-af78-042d-dd3e-ca9a45d20bdf@proxmox.com> (Fiona Ebner's message of "Wed, 10 May 2023 11:31:09 +0200")

Fiona Ebner <f.ebner@proxmox.com> wrote:
> Hi,
> I'm trying to fix issue #1576 [0], but having a bit of a hard time.
>
> The issue was introduced by commit 010746ae1d ("hw/pci/aer: Implement
> PCI_ERR_UNCOR_MASK register") and the migration error is:
>> qemu-system-x86_64: get_pci_config_device: Bad config data: i=0x10a read: 40 device: 0 cmask: ff wmask: 0 w1cmask:0
>
> Since there is no dedicated subsection for the new register, but it's
> just part of the existing buffer sent along with the device, the
> approach described in docs/devel/migration.rst, "Connecting subsections
> to properties" doesn't seem to work here.
>
> AFAIU, it would be necessary to unset the new register in the buffer
> before sending for older machine types (before the patch, its value was
> 0). Then older QEMU versions should accept the migration stream again.
> Migration between >8.0 and >= 8.0 when using an older machine type would
> be softly broken, because the register value is reset to 0, but not be a
> hard error, because it's the same situation as forward migration from
> 7.2 (the error condition in get_pci_config_device() doesn't trigger,
> because versions with commit 010746ae1d set the wmask for the new
> register during device initialization).
>
> Is there a good way to unset the register conditionally based on machine
> type during save? Is there any fix for a similar issue in the past I can
> look at?
>
> Or will this be a WONTFIX, because it's just backwards migration and
> QEMU 8.0 has already been released?
>
> [0]: https://gitlab.com/qemu-project/qemu/-/issues/1576

There is a patch on list from Leonardo:

https://lists.gnu.org/archive/html/qemu-devel/2023-05/msg00350.html

Or I am missing something?

Later, Juan.



      reply	other threads:[~2023-05-10 12:19 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-10  9:31 Question about issue #1576: Migration from v8.0.0-rc2 to v7.2.0 with pcie-root-port device fails Fiona Ebner
2023-05-10 12:19 ` Juan Quintela [this message]

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=87mt2c8jl8.fsf@secure.mitica \
    --to=quintela@redhat.com \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=dave.jiang@intel.com \
    --cc=f.ebner@proxmox.com \
    --cc=fan.ni@samsung.com \
    --cc=leobras@redhat.com \
    --cc=mst@redhat.com \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=t.lamprecht@proxmox.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.