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@xxxxxxxx>
> ---
> 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?
Paolo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
