From: Sean Christopherson <seanjc@google.com>
To: Maxim Levitsky <mlevitsk@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Wanpeng Li <wanpengli@tencent.com>,
Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
Oliver Upton <oupton@google.com>, Peter Shier <pshier@google.com>
Subject: Re: [PATCH 00/21] KVM: x86: Event/exception fixes and cleanups
Date: Mon, 28 Mar 2022 17:50:51 +0000 [thread overview]
Message-ID: <YkH1e2kyFlQN3Hl9@google.com> (raw)
In-Reply-To: <e605082ac8361c1932bfddfe2055660c7cea5f2b.camel@redhat.com>
On Sun, Mar 27, 2022, Maxim Levitsky wrote:
> Other than that I am actually very happy that you posted this patch series,
> as this gives more chance that this long standing issue will be fixed,
> and if your patches are better/simpler/less invasive to KVM and still address the issue,
> I fully support using them instead of mine.
I highly doubt they're simpler or less invasive, but I do hope that the approach
wil be easier to maintain.
> Totally agree with you about your thoughts about splitting pending/injected exception,
> I also can't say I liked my approach that much, for the same reasons you mentioned.
>
> It is also the main reason I put the whole thing on the backlog lately,
> because I was feeling that I am changing too much of the KVM,
> for a relatively theoretical issue.
>
>
> I will review your patches, compare them to mine, and check if you or I missed something.
>
> PS:
>
> Back then, I also did an extensive review on few cases when qemu injects exceptions itself,
> which it does thankfully rarely. There are several (theoretical) issues there.
> I don't remember those details, I need to refresh my memory.
>
> AFAIK, qemu injects #MC sometimes when it gets it from the kernel in form of a signal,
> if I recall this correctly, and it also reflects back #DB, when guest debug was enabled
> (and that is the reason for some work I did in this area, like the KVM_GUESTDBG_BLOCKIRQ thing)
>
> Qemu does this without considering nested and/or pending exception/etc.
> It just kind of abuses the KVM_SET_VCPU_EVENTS for that.
I wouldn't call that abuse, the ioctl() isn't just for migration. Not checking for
a pending exception is firmly a userspace bug and not something KVM should try to
fix.
For #DB, I suspect it's a non-issue. The exit is synchronous, so unless userspace
is deferring the reflection, which would be architecturally wrong in and of itself,
there can never be another pending exception.
For #MC, I think the correct behavior would be to defer the synthesized #MC if there's
a pending exception and resume the guest until the exception is injected. E.g. if a
different task encounters the real #MC, the synthesized #MC will be fully asynchronous
and may be coincident with a pending exception that is unrelated to the #MC. That
would require to userspace to enable KVM_CAP_EXCEPTION_PAYLOAD, otherwise userspace
won't be able to differentiate between a pending and injected exception, e.g. if the
#MC occurs during exception vectoring, userspace should override the injected exception
and synthesize #MC, otherwise it would likely soft hang the guest.
next prev parent reply other threads:[~2022-03-28 17:50 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-11 3:27 [PATCH 00/21] KVM: x86: Event/exception fixes and cleanups Sean Christopherson
2022-03-11 3:27 ` [PATCH 01/21] KVM: x86: Return immediately from x86_emulate_instruction() on code #DB Sean Christopherson
2022-03-11 3:27 ` [PATCH 02/21] KVM: nVMX: Unconditionally purge queued/injected events on nested "exit" Sean Christopherson
2022-03-11 3:27 ` [PATCH 03/21] KVM: VMX: Drop bits 31:16 when shoving exception error code into VMCS Sean Christopherson
2022-03-11 3:27 ` [PATCH 04/21] KVM: x86: Don't check for code breakpoints when emulating on exception Sean Christopherson
2022-03-11 3:27 ` [PATCH 05/21] KVM: nVMX: Treat General Detect #DB (DR7.GD=1) as fault-like Sean Christopherson
2022-03-11 3:27 ` [PATCH 06/21] KVM: nVMX: Prioritize TSS T-flag #DBs over Monitor Trap Flag Sean Christopherson
2022-03-11 3:27 ` [PATCH 07/21] KVM: x86: Treat #DBs from the emulator as fault-like (code and DR7.GD=1) Sean Christopherson
2022-03-11 3:27 ` [PATCH 08/21] KVM: x86: Use DR7_GD macro instead of open coding check in emulator Sean Christopherson
2022-03-11 3:27 ` [PATCH 09/21] KVM: nVMX: Ignore SIPI that arrives in L2 when vCPU is not in WFS Sean Christopherson
2022-03-11 3:27 ` [PATCH 10/21] KVM: nVMX: Unconditionally clear mtf_pending on nested VM-Exit Sean Christopherson
2022-03-11 3:27 ` [PATCH 11/21] KVM: VMX: Inject #PF on ENCLS as "emulated" #PF Sean Christopherson
2022-03-11 3:27 ` [PATCH 12/21] KVM: x86: Rename kvm_x86_ops.queue_exception to inject_exception Sean Christopherson
2022-03-11 3:27 ` [PATCH 13/21] KVM: x86: Make kvm_queued_exception a properly named, visible struct Sean Christopherson
2022-03-11 3:27 ` [PATCH 14/21] KVM: x86: Formalize blocking of nested pending exceptions Sean Christopherson
2022-03-11 3:27 ` [PATCH 15/21] KVM: x86: Use kvm_queue_exception_e() to queue #DF Sean Christopherson
2022-03-11 3:27 ` [PATCH 16/21] KVM: x86: Hoist nested event checks above event injection logic Sean Christopherson
2022-03-11 3:27 ` [PATCH 17/21] KVM: x86: Evaluate ability to inject SMI/NMI/IRQ after potential VM-Exit Sean Christopherson
2022-03-11 3:27 ` [PATCH 18/21] KVM: x86: Morph pending exceptions to pending VM-Exits at queue time Sean Christopherson
2022-03-11 3:27 ` [PATCH 19/21] KVM: VMX: Update MTF and ICEBP comments to document KVM's subtle behavior Sean Christopherson
2022-03-11 3:28 ` [PATCH 20/21] KVM: selftests: Use uapi header to get VMX and SVM exit reasons/codes Sean Christopherson
2022-03-11 3:28 ` [PATCH 21/21] KVM: selftests: Add an x86-only test to verify nested exception queueing Sean Christopherson
2022-03-11 16:30 ` [PATCH 00/21] KVM: x86: Event/exception fixes and cleanups Maciej S. Szmigiero
2022-03-13 9:22 ` Maxim Levitsky
2022-03-24 21:31 ` Sean Christopherson
2022-03-25 21:25 ` Maciej S. Szmigiero
2022-03-25 23:02 ` Sean Christopherson
2022-03-26 0:21 ` Maciej S. Szmigiero
2022-03-27 15:06 ` Maxim Levitsky
2022-03-28 17:50 ` Sean Christopherson [this message]
2022-03-29 10:45 ` Maxim Levitsky
2022-03-29 15:43 ` Sean Christopherson
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=YkH1e2kyFlQN3Hl9@google.com \
--to=seanjc@google.com \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mlevitsk@redhat.com \
--cc=oupton@google.com \
--cc=pbonzini@redhat.com \
--cc=pshier@google.com \
--cc=vkuznets@redhat.com \
--cc=wanpengli@tencent.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.