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 <brog...@suse.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. Jan
signature.asc
Description: OpenPGP digital signature
