Re: [Question] About the behavior of HLT in VMX guest mode

From: Wanpeng Li <kernellwp@gmail.com>
To: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: "Longpeng (Mike)" <longpeng2@huawei.com>,
	kvm <kvm@vger.kernel.org>, Gonglei <arei.gonglei@huawei.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Question] About the behavior of HLT in VMX guest mode
Date: Tue, 11 Jul 2017 18:41:49 +0800	[thread overview]
Message-ID: <CANRm+Cwjjn1BAAW8yamOrpOdcGLX4dw1TGFv+wbAn=CD0W2XAw@mail.gmail.com> (raw)
In-Reply-To: <20170710170810.GA28875@potion>

2017-07-11 1:08 GMT+08:00 Radim Krčmář <rkrcmar@redhat.com>:
> 2017-07-04 12:24+0800, Wanpeng Li:
>> I observed that the hang during the boot of guest since pvspinlock
>> depends on trapping the halt as mentioned in this patch:
>> http://lkml.iu.edu/hypermail/linux/kernel/1202.0/03309.html，the hang
>> disappears when I remove the KVM_FEATURE_PV_UNHALT CPUID flag in order
>> to disable the pvspinlock in guest from kvm. So if disable the
>> pvspinlock in the low latency scenario(idle=poll in guest) w/ vCPU and
>> pCPU 1:1 pin can be acceptable?
>
> I think the hang happened because one VCPU did a halt with disabled
> interrupts and then ignored KVM_HC_KICK_CPU from another VCPU.
> The target VCPU does a VM exit, so handling the PV unhalt should be a
> simple setting of GUEST_ACTIVITY_ACTIVE upon arch.pv.pv_unhalted.
>
> If it turns out to be complicated, then forbidding the userspace to
> configure both is acceptable, (like you said, it currently doesn't make
> much sense to combine them)

kvm_spinlock_init() just check KVM_FEATURE_PV_UNHALT once to determine
whether to enable pvspinlock, however, there is no easy way to check
per-VM halt-exiting flag in the function __do_cpuid_ent().

Regards,
Wanpeng Li