linux-kernel - Re: [PATCH 2/2] KVM: x86: allow BSP to handle INIT IPIs like APs do

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <56B8C51A.2070505@redhat.com>
Date:	Mon, 8 Feb 2016 17:40:58 +0100
From:	Paolo Bonzini <pbonzini@...hat.com>
To:	Bruce Rogers <brogers@...e.com>, kvm@...r.kernel.org,
	linux-kernel@...r.kernel.org, Jan Kiszka <jan.kiszka@....de>
Cc:	namit@...technion.ac.il
Subject: Re: [PATCH 2/2] KVM: x86: allow BSP to handle INIT IPIs like APs do



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