From: Jan Kiszka <jan.kiszka@web.de>
To: Paolo Bonzini <pbonzini@redhat.com>,
Gleb Natapov <gleb@kernel.org>,
Marcelo Tosatti <mtosatti@redhat.com>
Cc: kvm <kvm@vger.kernel.org>
Subject: Re: [PATCH v3 1/4] KVM: nVMX: Rework interception of IRQs and NMIs
Date: Sun, 09 Mar 2014 09:07:00 +0100 [thread overview]
Message-ID: <531C2124.6020706@web.de> (raw)
In-Reply-To: <531C2041.1020106@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 3045 bytes --]
On 2014-03-09 09:03, Paolo Bonzini wrote:
> Il 09/03/2014 08:33, Paolo Bonzini ha scritto:
>> Il 08/03/2014 10:21, Jan Kiszka ha scritto:
>>> On 2014-03-07 20:48, Paolo Bonzini wrote:
>>>> Il 07/03/2014 20:03, Jan Kiszka ha scritto:
>>>>> @@ -4631,22 +4631,8 @@ static void vmx_set_nmi_mask(struct kvm_vcpu
>>>>> *vcpu, bool masked)
>>>>>
>>>>> static int vmx_nmi_allowed(struct kvm_vcpu *vcpu)
>>>>> {
>>>>> - if (is_guest_mode(vcpu)) {
>>>>> - if (to_vmx(vcpu)->nested.nested_run_pending)
>>>>> - return 0;
>>>>> - if (nested_exit_on_nmi(vcpu)) {
>>>>> - nested_vmx_vmexit(vcpu, EXIT_REASON_EXCEPTION_NMI,
>>>>> - NMI_VECTOR | INTR_TYPE_NMI_INTR |
>>>>> - INTR_INFO_VALID_MASK, 0);
>>>>> - /*
>>>>> - * The NMI-triggered VM exit counts as injection:
>>>>> - * clear this one and block further NMIs.
>>>>> - */
>>>>> - vcpu->arch.nmi_pending = 0;
>>>>> - vmx_set_nmi_mask(vcpu, true);
>>>>> - return 0;
>>>>> - }
>>>>> - }
>>>>> + if (to_vmx(vcpu)->nested.nested_run_pending)
>>>>> + return 0;
>>>>>
>>>>> if (!cpu_has_virtual_nmis() && to_vmx(vcpu)->soft_vnmi_blocked)
>>>>> return 0;
>>>>> @@ -4658,19 +4644,8 @@ static int vmx_nmi_allowed(struct kvm_vcpu
>>>>> *vcpu)
>>>>>
>>>>> static int vmx_interrupt_allowed(struct kvm_vcpu *vcpu)
>>>>> {
>>>>> - if (is_guest_mode(vcpu)) {
>>>>> - if (to_vmx(vcpu)->nested.nested_run_pending)
>>>>> - return 0;
>>>>> - if (nested_exit_on_intr(vcpu)) {
>>>>> - nested_vmx_vmexit(vcpu, EXIT_REASON_EXTERNAL_INTERRUPT,
>>>>> - 0, 0);
>>>>> - /*
>>>>> - * fall through to normal code, but now in L1, not L2
>>>>> - */
>>>>> - }
>>>>> - }
>>>>> -
>>>>> - return (vmcs_readl(GUEST_RFLAGS) & X86_EFLAGS_IF) &&
>>>>> + return (!to_vmx(vcpu)->nested.nested_run_pending &&
>>>>> + vmcs_readl(GUEST_RFLAGS) & X86_EFLAGS_IF) &&
>>>>> !(vmcs_read32(GUEST_INTERRUPTIBILITY_INFO) &
>>>>> (GUEST_INTR_STATE_STI | GUEST_INTR_STATE_MOV_SS));
>>>>
>>>> The checks on nested_run_pending are not needed anymore and can be
>>>> replaced with a WARN_ON. Otherwise,
>>>
>>> Nope, that won't be correct: If we have a pending interrupt that L1 does
>>> not intercept, we still trigger this condition legally.
>>
>> Right, this is the case of !nested_exit_on_intr(vcpu) or
>> !nested_exit_on_nmi(vcpu).
>>
>> Why don't we need to request an immediate exit in that case, in order to
>> inject the interrupt into L2?
>
> Nevermind, this makes no sense. I was confusing *_allowed with
> enable_*_window.
This code is mind-blowing and probably still not perfect. I wouldn't be
surprised if we are going to find bugs there until we retire. ;)
>
> Applying v3 to kvm/queue, thanks!
>
Great, thank you!
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
next prev parent reply other threads:[~2014-03-09 8:07 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-07 19:03 [PATCH v3 0/4] KVM: x86: Pending nVMX fixes Jan Kiszka
2014-03-07 19:03 ` [PATCH v3 1/4] KVM: nVMX: Rework interception of IRQs and NMIs Jan Kiszka
2014-03-07 19:48 ` Paolo Bonzini
2014-03-08 9:21 ` Jan Kiszka
2014-03-09 7:33 ` Paolo Bonzini
2014-03-09 8:01 ` Jan Kiszka
2014-03-09 8:03 ` Paolo Bonzini
2014-03-09 8:07 ` Jan Kiszka [this message]
2014-03-07 19:03 ` [PATCH v3 2/4] KVM: nVMX: Fully emulate preemption timer Jan Kiszka
2014-03-07 19:03 ` [PATCH v3 3/4] KVM: nVMX: Do not inject NMI vmexits when L2 has a pending interrupt Jan Kiszka
2014-03-07 19:03 ` [PATCH v3 4/4] x86: Remove return code from enable_irq/nmi_window Jan Kiszka
2014-03-07 19:06 ` [PATCH v3 0/4] KVM: x86: Pending nVMX fixes Jan Kiszka
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=531C2124.6020706@web.de \
--to=jan.kiszka@web.de \
--cc=gleb@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@redhat.com \
--cc=pbonzini@redhat.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