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: <56B860E202000048001251D8@prv-mh.provo.novell.com>
Date:	Mon, 08 Feb 2016 09:33:22 -0700
From:	"Bruce Rogers" <brogers@...e.com>
To:	"Paolo Bonzini" <pbonzini@...hat.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 2/8/2016 at 08:22 AM, Jan Kiszka <jan.kiszka@....de> wrote: 
> On 2016-02-08 16:12, Paolo Bonzini wrote:
>> 
>> 
>> On 03/02/2016 23:51, Bruce Rogers wrote:
>>> The INIT IPI event handler special cases the boot-strap processor
>>> (BSP) handling, avoiding the same mp state handling which is done for
>>> the other (AP) processors. Debugging a linux guest usage scenario of
>>> avoiding a reboot through the bios for a crash on any processor via eg:
>>> kexec -p /boot/vmlinuz --initrd=/boot/initrd --append="$(cat /proc/cmdline)\
>>> maxcpus=1" led to identifying this change as the needed fix.
>>>
>>> With this change, an AP can now startup the BSP without error.
>>>
>>> Signed-off-by: Bruce Rogers <brogers@...e.com>
>>> ---
>>>  arch/x86/kvm/lapic.c | 5 +----
>>>  1 file changed, 1 insertion(+), 4 deletions(-)
>>>
>>> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
>>> index 36591fa..eda6bfb 100644
>>> --- a/arch/x86/kvm/lapic.c
>>> +++ b/arch/x86/kvm/lapic.c
>>> @@ -2170,10 +2170,7 @@ void kvm_apic_accept_events(struct kvm_vcpu *vcpu)
>>>  	if (test_bit(KVM_APIC_INIT, &pe)) {
>>>  		kvm_lapic_reset(vcpu, true);
>>>  		kvm_vcpu_reset(vcpu, true);
>>> -		if (kvm_vcpu_is_bsp(apic->vcpu))
>>> -			vcpu->arch.mp_state = KVM_MP_STATE_RUNNABLE;
>>> -		else
>>> -			vcpu->arch.mp_state = KVM_MP_STATE_INIT_RECEIVED;
>>> +		vcpu->arch.mp_state = KVM_MP_STATE_INIT_RECEIVED;
>>>  	}
>>>  	if (test_bit(KVM_APIC_SIPI, &pe) &&
>>>  	    vcpu->arch.mp_state == KVM_MP_STATE_INIT_RECEIVED) {
>>>
>> 
>> 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.

Bruce