All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>, kvm@vger.kernel.org
Cc: "Radim Krčmář" <rkrcmar@redhat.com>,
	"Liran Alon" <liran.alon@oracle.com>,
	"Sean Christopherson" <sean.j.christopherson@intel.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC] KVM: x86: vmx: throttle immediate exit through preemtion timer to assist buggy guests
Date: Fri, 29 Mar 2019 16:14:34 +0100	[thread overview]
Message-ID: <877ech3e79.fsf@vitty.brq.redhat.com> (raw)
In-Reply-To: <89d4189b-de6a-7634-de8b-29a044a86e12@redhat.com>

Paolo Bonzini <pbonzini@redhat.com> writes:

> On 29/03/19 15:40, Vitaly Kuznetsov wrote:
>> Paolo Bonzini <pbonzini@redhat.com> writes:
>> 
>>> On 28/03/19 21:31, Vitaly Kuznetsov wrote:
>>>>
>>>> The 'hang' scenario develops like this:
>>>> 1) Hyper-V boots and QEMU is trying to inject two irq simultaneously. One
>>>>  of them is level-triggered. KVM injects the edge-triggered one and
>>>>  requests immediate exit to inject the level-triggered:
>>>>
>>>>  kvm_set_irq:          gsi 23 level 1 source 0
>>>>  kvm_msi_set_irq:      dst 0 vec 80 (Fixed|physical|level)
>>>>  kvm_apic_accept_irq:  apicid 0 vec 80 (Fixed|edge)
>>>>  kvm_msi_set_irq:      dst 0 vec 96 (Fixed|physical|edge)
>>>>  kvm_apic_accept_irq:  apicid 0 vec 96 (Fixed|edge)
>>>>  kvm_nested_vmexit_inject: reason EXTERNAL_INTERRUPT info1 0 info2 0 int_info 80000060 int_info_err 0
>>>>
>>>> 2) Hyper-V requires one of its VMs to run to handle the situation but
>>>>  immediate exit happens:
>>>>
>>>>  kvm_entry:            vcpu 0
>>>>  kvm_exit:             reason VMRESUME rip 0xfffff80006a40115 info 0 0
>>>>  kvm_entry:            vcpu 0
>>>>  kvm_exit:             reason PREEMPTION_TIMER rip 0xfffff8022f3d8350 info 0 0
>>>>  kvm_nested_vmexit:    rip fffff8022f3d8350 reason PREEMPTION_TIMER info1 0 info2 0 int_info 0 int_info_err 0
>>>>  kvm_nested_vmexit_inject: reason EXTERNAL_INTERRUPT info1 0 info2 0 int_info 80000050 int_info_err 0
>>>
>>> I supposed before this there was an eoi for vector 96?
>> 
>> AFAIR: no, it seems that it is actually the VM it is trying to resume
>> (Windows partition?) which needs to do some work and with the preemtion
>> timer of 0 we don't allow it to.
>
> kvm_apic_accept_irq placed IRQ 96 in IRR, and Hyper-V should be running
> with "acknowledge interrupt on exit" since int_info is nonzero in
> kvm_nested_vmexit_inject.
>
> Therefore, at the kvm_nested_vmexit_inject tracepoint KVM should have
> set bit 96 in ISR; and because PPR is now 96, interrupt 80 should have
> never been delivered.  Unless 96 is an auto-EOI interrupt, in which case
> this comment would apply
>
>           /*
>            * For auto-EOI interrupts, there might be another pending
>            * interrupt above PPR, so check whether to raise another
>            * KVM_REQ_EVENT.
>            */
>
> IIRC there was an enlightenment to tell Windows "I support auto-EOI but
> please don't use it".  If this is what's happening, that would also fix it.
>

Oh, that's actually an interesting thought, thanks!

Indeed, there is CPUID 0x40000004.EAX Bit 9: Recommend deprecating
AutoEOI which we don't currently set. I'll try and report back.

-- 
Vitaly

  reply	other threads:[~2019-03-29 15:14 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-28 20:31 [PATCH RFC] KVM: x86: vmx: throttle immediate exit through preemtion timer to assist buggy guests Vitaly Kuznetsov
2019-03-29  2:00 ` Liran Alon
2019-03-29  9:14   ` Vitaly Kuznetsov
2019-03-29 12:09     ` Liran Alon
2019-03-29 14:18 ` Paolo Bonzini
2019-03-29 14:40   ` Vitaly Kuznetsov
2019-03-29 15:01     ` Paolo Bonzini
2019-03-29 15:14       ` Vitaly Kuznetsov [this message]
2019-03-29 15:32       ` Liran Alon
2019-03-29 17:14         ` Paolo Bonzini
2019-04-01  8:39           ` Vitaly Kuznetsov
2019-04-01 10:08             ` Liran Alon
2019-04-01 10:41               ` Vitaly Kuznetsov
2019-04-01  8:50       ` Vitaly Kuznetsov

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=877ech3e79.fsf@vitty.brq.redhat.com \
    --to=vkuznets@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=liran.alon@oracle.com \
    --cc=pbonzini@redhat.com \
    --cc=rkrcmar@redhat.com \
    --cc=sean.j.christopherson@intel.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.