From: Juan Quintela <quintela@redhat.com>
To: Fiona Ebner <f.ebner@proxmox.com>
Cc: "Leonardo Bras" <leobras@redhat.com>,
"Eduardo Habkost" <eduardo@habkost.net>,
"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Yanan Wang" <wangyanan55@huawei.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Peter Xu" <peterx@redhat.com>,
qemu-devel@nongnu.org
Subject: Re: [PATCH v1 1/1] hw/pci: Disable PCI_ERR_UNCOR_MASK register for machine type < 8.0
Date: Thu, 11 May 2023 10:40:14 +0200 [thread overview]
Message-ID: <87jzxf5ki9.fsf@secure.mitica> (raw)
In-Reply-To: <7f308149-5495-d415-5e51-1fa15fc20f84@proxmox.com> (Fiona Ebner's message of "Thu, 11 May 2023 10:27:35 +0200")
Fiona Ebner <f.ebner@proxmox.com> wrote:
> Am 03.05.23 um 02:27 schrieb Leonardo Bras:
>> Since it's implementation on v8.0.0-rc0, having the PCI_ERR_UNCOR_MASK
>> set for machine types < 8.0 will cause migration to fail if the target
>> QEMU version is < 8.0.0 :
>>
>> qemu-system-x86_64: get_pci_config_device: Bad config data: i=0x10a read: 40 device: 0 cmask: ff wmask: 0 w1cmask:0
>> qemu-system-x86_64: Failed to load PCIDevice:config
>> qemu-system-x86_64: Failed to load e1000e:parent_obj
>> qemu-system-x86_64: error while loading state for instance 0x0 of device '0000:00:02.0/e1000e'
>> qemu-system-x86_64: load of migration failed: Invalid argument
>>
>> The above test migrated a 7.2 machine type from QEMU master to QEMU 7.2.0,
>> with this cmdline:
>>
>> ./qemu-system-x86_64 -M pc-q35-7.2 [-incoming XXX]
>>
>> In order to fix this, property x-pcie-err-unc-mask was introduced to
>> control when PCI_ERR_UNCOR_MASK is enabled. This property is enabled by
>> default, but is disabled if machine type <= 7.2.
>>
>> Fixes: 010746ae1d ("hw/pci/aer: Implement PCI_ERR_UNCOR_MASK register")
>> Suggested-by: Michael S. Tsirkin <mst@redhat.com>
>> Signed-off-by: Leonardo Bras <leobras@redhat.com>
>
> Thank you for the patch!
>
> Closes: https://gitlab.com/qemu-project/qemu/-/issues/1576
>
> AFAICT, this breaks (forward) migration from 8.0 to 8.0 + this patch
> when using machine type <= 7.2. That is because after this patch, when
> using machine type <= 7.2, the wmask for the register is not set and
> when 8.0 sends a nonzero value for the register, the error condition in
> get_pci_config_device() will trigger again.
I think that works correctly.
See https://lists.gnu.org/archive/html/qemu-devel/2023-05/msg02733.html
What we have (before this patch) (using abbrevs as in the doc before)
Current state:
(1) qemu-8.0 -M pc-8.0 -> qemu-8.0 -M pc-8.0 works
not affected by the patch
(2) qemu-7.2 -M pc-7.2 -> qemu-8.0 -M pc-8.0 works
works well because 7.2 don't change that field
(3) qemu-8.0 -M pc-7.2 -> qemu-7.2 -M pc-7.2 fails
With the patch we fixed 3, so once it is in stable, 1 and 2 continue as
usual and for (3) we will have:
(3) qemu-8.0.1 -M pc-7.2 -> qemu-7.2 -M pc-7.2 works
If what you mean is that:
(3) qemu-8.0 -M pc-7.2 -> qemu-8.0.1 -M pc-7.2 works
Will fail, that is true, but I can think a "sane" way to fix this.
> Is it necessary to also handle that? Maybe by special casing the error
> condition in get_pci_config_device() to be prepared to accept such a
> stream from 8.0?
Well, we can do that, but it is to the pci maintainers to decide if that
is "sane".
> If that is considered not worth it, consider this:
>
> Tested-by: Fiona Ebner <f.ebner@proxmox.com>
>
> Best Regards,
> Fiona
Later, Juan.
next prev parent reply other threads:[~2023-05-11 8:41 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-03 0:27 [PATCH v1 1/1] hw/pci: Disable PCI_ERR_UNCOR_MASK register for machine type < 8.0 Leonardo Bras
2023-05-03 9:32 ` Jonathan Cameron via
2023-05-03 15:54 ` Leonardo Bras Soares Passos
2023-05-03 15:10 ` Peter Xu
2023-05-03 17:04 ` Juan Quintela
2023-05-09 14:01 ` Peter Xu
2023-05-09 15:23 ` Michael S. Tsirkin
2023-05-09 15:32 ` Juan Quintela
2023-05-10 16:29 ` Michael Tokarev
2023-05-10 16:33 ` Michael S. Tsirkin
2023-05-10 16:42 ` Juan Quintela
2023-05-11 8:27 ` Fiona Ebner
2023-05-11 8:40 ` Juan Quintela [this message]
2023-05-18 7:34 ` Michael Tokarev
2023-05-18 11:33 ` Juan Quintela
2023-05-18 13:27 ` Peter Xu
2023-05-18 15:10 ` Michael S. Tsirkin
2023-05-18 15:27 ` Juan Quintela
2023-05-18 15:20 ` Juan Quintela
2023-05-11 10:48 ` Michael S. Tsirkin
2023-05-11 11:43 ` Juan Quintela
2023-05-11 12:20 ` Michael S. Tsirkin
2023-05-22 15:25 ` Jiri Denemark
2023-05-26 7:55 ` Juan Quintela
2023-05-28 6:39 ` Michael S. Tsirkin
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=87jzxf5ki9.fsf@secure.mitica \
--to=quintela@redhat.com \
--cc=eduardo@habkost.net \
--cc=f.ebner@proxmox.com \
--cc=leobras@redhat.com \
--cc=marcel.apfelbaum@gmail.com \
--cc=mst@redhat.com \
--cc=peterx@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=wangyanan55@huawei.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).