lkml.org 
[lkml]   [2016]   [Feb]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 2/2] KVM: x86: allow BSP to handle INIT IPIs like APs do
>>> On 2/8/2016 at 10:27 AM, Bruce Rogers wrote: 
> >>> On 2/8/2016 at 09:40 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
>>
>> 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.
>
> I had read that, but I though this was speaking from the perspective of the
> SMP aware BIOS code only. In other words, the BIOS would sidetrack AP's
> (based on BSP flag not being present), while BSP would be allowed to go
> through
> the regular BIOS code, checking for reset case, etc. An OS on the other hand
> would be free to treat all x86 processors equally, once it has booted into
> fully symmetrical mode.
> I certainly could be wrong about my above interpretation, but with these
> changes I'm proposing, things work well for the test case of manually
> onlining
> the BSP after the crash kernel has been started (via kexec -e on a AP
> processor
> with maxcpus=1 on the crash kernel command line). From looking through the
> kernel git history it appears this sequence of events was explicitly
> supported
> quite a while ago, and we've got a customer who uses this for fast recovery
> from
> a guest kernel crash.
>
> Bruce

I mean kexec - p ... above, not kexec -e. Sorry about that.

Bruce

\
 
 \ /
  Last update: 2016-02-08 19:01    [W:0.131 / U:0.088 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site