All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Bruce Rogers <brogers@suse.com>,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	Jan Kiszka <jan.kiszka@web.de>
Cc: namit@cs.technion.ac.il
Subject: Re: [PATCH 2/2] KVM: x86: allow BSP to handle INIT IPIs like APs do
Date: Mon, 8 Feb 2016 17:40:58 +0100	[thread overview]
Message-ID: <56B8C51A.2070505@redhat.com> (raw)
In-Reply-To: <56B860E202000048001251D8@prv-mh.provo.novell.com>



On 08/02/2016 17:33, Bruce Rogers wrote:
>>> >> 
>>> >> KVM_MP_STATE_INIT_RECEIVED is what Intel calls the "wait for SIPI"
>>> >> state.  The BSP never gets a SIPI, it goes straight to 0xFFFFFFF0
>>> >> instead.  Can you explain the problem more in detail?
>> > 
>> > I suspect this is about sending INIT-SIPI from another CPU, directed to
>> > the BSP, isn't it? We may have to differentiate between CPU (including
>> > system) reset and that IPI case.
> That is correct. In looking over the KVM code which deals with BSP, this was
> the only place which seemed wrong to me wrt special casing for BSP outside the
> context of initial system initialization / reset. As far as I understand the
> BSP shouldn't be treated differently in this case.

See 8.4.2 of the SDM:

If the MP protocol has completed and a BSP is chosen, subsequent INITs
(either to a specific processor or system wide) do not cause the MP
protocol to be repeated. Instead, each logical processor examines its
BSP flag (in the IA32_APIC_BASE MSR) to determine whether it should
execute the BIOS boot-strap code (if it is the BSP) or enter a
wait-for-SIPI state (if it is an AP).

So it is correct to treat the BSP differently here, I think.

Paolo

  reply	other threads:[~2016-02-08 16:40 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-03 22:51 [PATCH 1/2] KVM: x86: fix ordering of cr0 initialization code in vmx_cpu_reset Bruce Rogers
2016-02-03 22:51 ` [PATCH 2/2] KVM: x86: allow BSP to handle INIT IPIs like APs do Bruce Rogers
2016-02-08 15:12   ` Paolo Bonzini
2016-02-08 15:22     ` Jan Kiszka
2016-02-08 16:33       ` Bruce Rogers
2016-02-08 16:40         ` Paolo Bonzini [this message]
2016-02-08 17:27           ` Bruce Rogers
2016-02-08 17:44             ` Paolo Bonzini
2016-02-08 17:38           ` Bruce Rogers
2016-02-08 17:53             ` Jan Kiszka
2016-02-10 17:24               ` Bruce Rogers
2016-02-03 23:18 ` [PATCH 1/2] KVM: x86: fix ordering of cr0 initialization code in vmx_cpu_reset Nadav Amit
2016-02-03 23:38   ` Bruce Rogers
2016-04-22 18:55   ` Bruce Rogers
2016-02-08 15:09 ` Paolo Bonzini
2016-02-08 16:29   ` Bruce Rogers
2016-02-08 16:43     ` Paolo Bonzini
2016-04-27  2:54     ` Wanpeng Li
2016-04-28 22:18       ` Bruce Rogers

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=56B8C51A.2070505@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=brogers@suse.com \
    --cc=jan.kiszka@web.de \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=namit@cs.technion.ac.il \
    /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.