From mboxrd@z Thu Jan  1 00:00:00 1970
From: Radim =?utf-8?B?S3LEjW3DocWZ?= <rkrcmar@redhat.com>
Subject: Re: [Question] About the behavior of HLT in VMX guest mode
Date: Mon, 10 Jul 2017 19:08:11 +0200
Message-ID: <20170710170810.GA28875@potion>
References: <58C64672.1070706@huawei.com>
 <20170315173254.GF14081@potion>
 <58C9F3A5.3090604@huawei.com>
 <20170316142340.GD14076@potion>
 <58CB727B.20902@huawei.com>
 <20170320151815.GA25540@potion>
 <58D0863D.4080001@huawei.com>
 <CANRm+Cz6md7pv1GcFvyG=sjwmroorUEEtvXPbXQ6Zyqhwz66bw@mail.gmail.com>
 <20170321164557.GB25540@potion>
 <CANRm+CzYcBpm+wtq3Lx6NSASoJ6wGxFypBNRSV+X2=-QWDJu1A@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Cc: "Longpeng (Mike)" <longpeng2@huawei.com>,
        kvm <kvm@vger.kernel.org>, Gonglei <arei.gonglei@huawei.com>,
        Paolo Bonzini <pbonzini@redhat.com>
To: Wanpeng Li <kernellwp@gmail.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx1.redhat.com ([209.132.183.28]:55372 "EHLO mx1.redhat.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1754415AbdGJRIP (ORCPT <rfc822;kvm@vger.kernel.org>);
        Mon, 10 Jul 2017 13:08:15 -0400
Content-Disposition: inline
In-Reply-To: <CANRm+CzYcBpm+wtq3Lx6NSASoJ6wGxFypBNRSV+X2=-QWDJu1A@mail.gmail.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

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)

thanks.