From: Paolo Bonzini <pbonzini@redhat.com>
To: Jan Kiszka <jan.kiszka@web.de>, 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 08:33:15 +0100 [thread overview]
Message-ID: <531C193B.3080805@redhat.com> (raw)
In-Reply-To: <531AE108.8090008@web.de>
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?
Paolo
next prev parent reply other threads:[~2014-03-09 7:33 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 [this message]
2014-03-09 8:01 ` Jan Kiszka
2014-03-09 8:03 ` Paolo Bonzini
2014-03-09 8:07 ` Jan Kiszka
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=531C193B.3080805@redhat.com \
--to=pbonzini@redhat.com \
--cc=gleb@kernel.org \
--cc=jan.kiszka@web.de \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@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