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: Tue, 11 Jul 2017 17:04:09 +0200
Message-ID: <20170711150408.GC3326@potion>
References: <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>
 <20170710170810.GA28875@potion>
 <CANRm+Cwjjn1BAAW8yamOrpOdcGLX4dw1TGFv+wbAn=CD0W2XAw@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]:35832 "EHLO mx1.redhat.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S932456AbdGKPEM (ORCPT <rfc822;kvm@vger.kernel.org>);
        Tue, 11 Jul 2017 11:04:12 -0400
Content-Disposition: inline
In-Reply-To: <CANRm+Cwjjn1BAAW8yamOrpOdcGLX4dw1TGFv+wbAn=CD0W2XAw@mail.gmail.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

2017-07-11 18:41+0800, Wanpeng Li:
> 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().

Right, but we do not need to eliminate the flag from __do_cpuid_ent().

The documentation could say that if you enable per-VM halt-exiting, then
you cannot set KVM_FEATURE_PV_UNHALT for VCPUs in that VM.  And KVM can
check when userspace sets the CPUID.  (And at least forbid enablement of
halt-exiting if there already are created VCPUs.)

It's nothing pretty, so I hope that supporting the combination will
work. :)