linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Radim Krčmář" <rkrcmar@redhat.com>
To: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	joro@8bytes.org, alex.williamson@redhat.com, gleb@kernel.org,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	wei@redhat.com, sherry.hurwitz@amd.com
Subject: Re: [PART1 RFC 5/9] svm: Add VMEXIT handlers for AVIC
Date: Thu, 18 Feb 2016 15:18:18 +0100	[thread overview]
Message-ID: <20160218141817.GA6289@potion.brq.redhat.com> (raw)
In-Reply-To: <56C52B80.5050104@amd.com>

2016-02-18 09:25+0700, Suravee Suthikulpanit:
> On 2/17/16 01:06, Radim Krčmář wrote:
>>2016-02-16 17:56+0100, Paolo Bonzini:
>>>>On 16/02/2016 15:13, Radim Krčmář wrote:
>>>>>>Yeah, I think atomic there means that it won't race with other writes to
>>>>>>the same byte in IRR.  We're fine as long as AVIC writes IRR before
>>>>>>checking IsRunning on every destination, which it seems to be.
>>>>
>>>>More precisely, if AVIC writes all IRRs (5.1) and ANDs all IsRunning
>>>>flags before checking the result of the AND (6).
>>>>
>>>>>>(It would, but I believe that AVIC designers made it sane and the spec
>>>>>>  doesn't let me read it in a way that supports your theories.)
>>>>
>>>>I hope so as well, and you've probably convinced me.  But I still think
>>>>the code is wrong in this patch.  Let's look at the spec that you pasted:
>>The code definitely is wrong.  I'll be more specific when disagreeing,
>>sorry.
>>
> 
> Would you please be a bit more specific on what you think I am not doing
> correctly to handle the #VMEXIT in the case of target not running below.
> 
> +    case AVIC_INCMP_IPI_ERR_TARGET_NOT_RUN:
> +        kvm_lapic_reg_write(apic, APIC_ICR2, icrh);
> +        kvm_lapic_reg_write(apic, APIC_ICR, icrl);
> 
> This is actually not just writing to the register. Please note that writing
> to APIC_ICR register would also be calling apic_send_ipi(), which results in
> injecting interrupts to the target core:

Exactly.  Injecting the interrupt in AVIC_INCMP_IPI_ERR_TARGET_NOT_RUN
handler is causing the double-injection bug that Paolo described.

> Am I missing something?

Probably that AVIC already wrote to all IRRs (and sent appropriate
doorbells) before this VMEXIT, so KVM shouldn't repeat it.

KVM just has to make sure that targeted VCPUs notice the interrupt,
which means to kick (wake up) VCPUs that don't have IsRunning set.
There is no need to do anything with running VCPUs, because they
 - are in guest mode and noticed the doorbell
 - are in host mode, where they will
   1) VMRUN as fast as they can because the VCPU didn't want to halt
      (and IRR is handled on VMRUN)
   2) check IRR after unsetting IsRunning and goto (1) if there are
      pending interrupts.  (RFC doesn't do this, which is another bug)

It's still possible that we misunderstood the spec.  Does AVIC handle
IPIs differently?

Thanks.

  reply	other threads:[~2016-02-18 14:18 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-12 13:59 [PART1 RFC 0/9] KVM: x86: Introduce SVM AVIC support Suravee Suthikulpanit
2016-02-12 13:59 ` [PART1 RFC 1/9] KVM: x86: Misc LAPIC changes to exposes helper functions Suravee Suthikulpanit
2016-02-12 13:59 ` [PART1 RFC 2/9] svm: Introduce new AVIC VMCB registers Suravee Suthikulpanit
2016-02-12 13:59 ` [PART1 RFC 3/9] svm: clean up V_TPR, V_IRQ, V_INTR_PRIO, and V_INTR_MASKING Suravee Suthikulpanit
2016-02-12 13:59 ` [PART1 RFC 4/9] KVM: x86: Detect and Initialize AVIC support Suravee Suthikulpanit
2016-02-12 14:13   ` Borislav Petkov
2016-02-12 15:46     ` Suravee Suthikulpanit
2016-02-12 13:59 ` [PART1 RFC 5/9] svm: Add VMEXIT handlers for AVIC Suravee Suthikulpanit
2016-02-12 15:38   ` Paolo Bonzini
2016-02-15 19:22     ` Radim Krčmář
2016-02-16  6:29     ` Suravee Suthikulpanit
2016-02-16 12:15       ` Paolo Bonzini
2016-02-16 14:13         ` Radim Krčmář
2016-02-16 16:56           ` Paolo Bonzini
2016-02-16 18:06             ` Radim Krčmář
2016-02-18  2:25               ` Suravee Suthikulpanit
2016-02-18 14:18                 ` Radim Krčmář [this message]
2016-02-18 14:51                   ` Paolo Bonzini
2016-02-18 15:43                     ` Radim Krčmář
2016-02-18 15:53                       ` Paolo Bonzini
2016-02-18 16:27                         ` Radim Krčmář
2016-02-18 17:18                           ` Paolo Bonzini
2016-02-19 11:39                             ` Suravee Suthikulpanit
2016-02-19 11:44                               ` Paolo Bonzini
2016-02-19 11:59                                 ` Suravee Suthikulpanit
2016-03-03 10:42                             ` Suravee Suthikulpanit
2016-03-03 10:50                               ` Paolo Bonzini
2016-02-19 11:32                   ` Suravee Suthikulpanit
2016-02-12 13:59 ` [PART1 RFC 6/9] svm: Add interrupt injection via AVIC Suravee Suthikulpanit
2016-02-12 14:16   ` Borislav Petkov
2016-02-12 15:54     ` Suravee Suthikulpanit
2016-02-12 17:14       ` Borislav Petkov
2016-02-12 18:21         ` Paolo Bonzini
2016-02-12 18:30           ` Borislav Petkov
2016-02-12 18:56             ` Paolo Bonzini
2016-02-12 19:33               ` Borislav Petkov
2016-02-16  7:50                 ` Ingo Molnar
2016-02-16  8:39                   ` [PATCH] x86/msr: Document msr-index.h rule for addition Borislav Petkov
2016-02-12 15:55   ` [PART1 RFC 6/9] svm: Add interrupt injection via AVIC Paolo Bonzini
2016-02-12 16:21     ` Suravee Suthikulpanit
2016-02-12 18:19       ` Paolo Bonzini
2016-02-12 19:36         ` Suravee Suthikulpanit
2016-02-19 11:57         ` Suravee Suthikulpanit
2016-02-12 13:59 ` [PART1 RFC 7/9] svm: Do not expose x2APIC when enable AVIC Suravee Suthikulpanit
2016-02-12 13:59 ` [PART1 RFC 8/9] svm: Do not intercept CR8 " Suravee Suthikulpanit
2016-02-12 15:48   ` Paolo Bonzini
2016-02-12 13:59 ` [PART1 RFC 9/9] svm: Manage vcpu load/unload " Suravee Suthikulpanit
2016-02-12 15:46   ` Paolo Bonzini
2016-02-12 18:13 ` [PART1 RFC 0/9] KVM: x86: Introduce SVM AVIC support Paolo Bonzini
2016-02-12 19:55   ` Suravee Suthikulpanit
2016-02-12 20:05     ` Paolo Bonzini

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=20160218141817.GA6289@potion.brq.redhat.com \
    --to=rkrcmar@redhat.com \
    --cc=Suravee.Suthikulpanit@amd.com \
    --cc=alex.williamson@redhat.com \
    --cc=gleb@kernel.org \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=sherry.hurwitz@amd.com \
    --cc=wei@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;
as well as URLs for NNTP newsgroup(s).