qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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).