From: Marcello Sylvester Bauer <marcello.bauer@9elements.com>
To: qemu-devel@nongnu.org
Cc: eesposit@redhat.com, alex.williamson@redhat.com,
richard.henderson@linaro.org, pbonzini@redhat.com,
eduardo@habkost.net, marcel.apfelbaum@gmail.com,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
wangyanan55@huawei.com
Subject: KVM internal error due to non-atomic memslot updates by pci_update_vga()
Date: Thu, 7 Mar 2024 15:48:15 +0100 [thread overview]
Message-ID: <83d42ca1-1656-4581-a056-bb0197c0ba09@9elements.com> (raw)
[-- Attachment #1.1.1: Type: text/plain, Size: 1713 bytes --]
Greetings,
I'm facing a problem with KVM memslot updates in pci_update_vga() and
I'm looking for a possible solution to prevent this error.
Background:
Over the past few weeks, we have been investigating a bug where QEMU
Windows 10 VMs using VT-d Intel GPU passthrough suddenly crash due to an
internal KVM error. In order for this bug to occur, Windows is set to
automatically turn off the display when idle. The reason for this bug is
that the Windows Intel GPU driver disables VGA and therefore disables
the QEMU memory region "vfio-vga-mmio@0xa0000". This change results in a
non-atomic KVM memslot update (0x0-0xa000 -> 0x0-0xc000). Accessing this
memory during this operation will cause a page fault and result in a
KVM_EXIT_MMIO. While QEMU can provide the data, KVM is required to
emulate the instruction, which in our case failed due to lack of support
for the MOVSD instruction. I'm currently working on a kvm patch set to
implement the missing instructions on the kernel side. But it would be
great to prevent this race condition in QEMU as well.
Now to my general question:
Besides disabling VGA, what can we do in QEMU to avoid this?
Will the patch set "KVM: allow listener to stop all vcpus before" [1] be
enough to prevent this bug or are additional changes needed?
There are even efforts to implement atomic memslot updates on the kernel
side, but it does not look like this change will be adopted. [2]
Any thoughts and suggestions are welcome.
Thanks.
Marcello
---
[1](https://patchwork.kernel.org/project/kvm/cover/20221111154758.1372674-1-eesposit@redhat.com/)
[2](https://lore.kernel.org/lkml/20220909104506.738478-1-eesposit@redhat.com/)
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 10181 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
reply other threads:[~2024-03-07 17:30 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=83d42ca1-1656-4581-a056-bb0197c0ba09@9elements.com \
--to=marcello.bauer@9elements.com \
--cc=alex.williamson@redhat.com \
--cc=eduardo@habkost.net \
--cc=eesposit@redhat.com \
--cc=marcel.apfelbaum@gmail.com \
--cc=pbonzini@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.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).