Received: by 10.223.185.116 with SMTP id b49csp185872wrg; Tue, 13 Feb 2018 19:27:55 -0800 (PST) X-Google-Smtp-Source: AH8x225WvfJEAg8dg03REYTdGJESaktoRVbR7ICWezrt7J93DElhX/xuAC2A8lmFl4X5zx7QyL8R X-Received: by 10.99.151.26 with SMTP id n26mr2759414pge.370.1518578874942; Tue, 13 Feb 2018 19:27:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518578874; cv=none; d=google.com; s=arc-20160816; b=mdTh6Vx33W+OZjshOtlCYdqAzwr2XKQCoJ/Zr38xM9Jvk8SmeSCoEAPuf00lWIeb/u 7a/92z8RB+g9Xq2sIX2H1LWgTlu7k2KxiDENfhjfhMhW/UguEi9FaiDvLEi9LktXBOGG W8b65nwI9wQTYY14sWHmr17ijJ1Ld26hGzHgHOseojl2nQ5yTsBF2wCaK3T3/5BpdxuU sn7b2qnMc+LeY+gVykfoSFbkhNSlnNkZnujV1O+7VV13YvklNFLOmNioe7fUQCIxPljn 6R0hKwhCtsqJmyUmskoDb2vBP93ciZTmI6Qzooo+uhsRiv6IFSdYraO+GLR0j6q50JkK 0Kbw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:references:in-reply-to:mime-version :dkim-signature:arc-authentication-results; bh=ZkLZncEu/HBi+fqmQ8ltoigIrRhmHNXX4aetlmeEwa0=; b=AF8ge5u9HvS+IcoYMVqTVPyJuTQBDrGNbUVfUroIM/3kti2kSDHPHlRMDcqDi2OwEs fZyKwQvIq0UCC5HWI0uJCLyo45xtgHeNf39Bs3RSyq6uwablyaLUEiyHqDe4/KsVGeoI se3DesVbGqIfST7f1+6nkxJ4kKEtaVVb8qzCUQ6fCW/Syb11N05Rj/4hEBQGfjRmASa0 W0xRnwyw5Ya32esg9KHwXq55gr7EtpI5wXGW1hmktogHLjbOqSA+ZL4Rdjb+HvusEg7+ F00c4+lEk4UBaM9WyiGdEOHVkHuCD+ciMijqh2fN4EtQX58yXho+PWcTDTki0Oen9I81 hYDw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=KDQC3SyZ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z2si7426260pgr.168.2018.02.13.19.27.39; Tue, 13 Feb 2018 19:27:54 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=KDQC3SyZ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966724AbeBND1A (ORCPT + 99 others); Tue, 13 Feb 2018 22:27:00 -0500 Received: from mail-oi0-f54.google.com ([209.85.218.54]:33478 "EHLO mail-oi0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966631AbeBND06 (ORCPT ); Tue, 13 Feb 2018 22:26:58 -0500 Received: by mail-oi0-f54.google.com with SMTP id l124so3301950oib.0; Tue, 13 Feb 2018 19:26:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ZkLZncEu/HBi+fqmQ8ltoigIrRhmHNXX4aetlmeEwa0=; b=KDQC3SyZIFXkLpKJ3XiL0QYZEk8e/ddfpB+/1Posxk8QGRHNFHbJT26yfeLoYKpVCR pIjhi+fqsBANgrws5CIhapffqnd2Xne43DLhIvlL72FIsep+DcDhsfdxgasSbYOq5TKI q4Wv6O1wEEeQ7akJ6bWxP6NTnarNrxX7bIzXDMq1TVVFeKme3Yz5847ueae1ukt9CH4s SmS5jYnv+ATaWmTy/wkCqaDz1RUmoTczz2pi5CvNgZE2vp/O5XwSOTumU6XSXkKH93zA Ab+AOexcl2L7VDyTYlkeK08g4Hng/En32FiS1kwQG/2zMdI6XJSuSN4wlao1wkSv9/+i 7B5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ZkLZncEu/HBi+fqmQ8ltoigIrRhmHNXX4aetlmeEwa0=; b=a6Ue5ITjsU/79h5w1tdum0ETlrJxU8Tw1AvGSHzAFglnMkFFkmlq57Ci8xy4a4dPVR TilT1Nwp0i3ztyecP6eu0aa7fWmsxfQMxl5gCLUEEwzBEeYthuKvZ0icuCZKMDpVXdyk PjfjjTCZhOX+CgE/vtpy+xgMVpLlDJH7aF89zn4ZhB0t+8u2qHQ8jEoXBqIyRZfsPAEX l12U7pn+J9Esjb8gGY5VrtQuxLe49fKt8/oLUOgK9yhHyWQ0iHsRmW0uFj4CFRcVh/T5 rzFMX5S56w7iqzfJnMLRVvHk2Y6qBHQ9TWVqAtzDHlyFoIiLDk6/mKgliKfaOFTOX90u T0Bg== X-Gm-Message-State: APf1xPCoXk5IZ1HScuPa0BCtMWVRlBSdWIpXeiQuMfPdxiEfUfMEZsAR E4+IJpWenNuish7C9vLBsgk1cPDIULPTRdPZJ/c= X-Received: by 10.202.13.16 with SMTP id 16mr2390006oin.4.1518578818203; Tue, 13 Feb 2018 19:26:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.10.129 with HTTP; Tue, 13 Feb 2018 19:26:57 -0800 (PST) In-Reply-To: <324a8c3a-35f1-ad4b-1ff5-9ba742778470@redhat.com> References: <1517813878-22248-1-git-send-email-wanpengli@tencent.com> <324a8c3a-35f1-ad4b-1ff5-9ba742778470@redhat.com> From: Wanpeng Li Date: Wed, 14 Feb 2018 11:26:57 +0800 Message-ID: Subject: Re: [PATCH v2 1/2] KVM: X86: Add per-VM no-HLT-exiting capability To: Paolo Bonzini Cc: LKML , kvm , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2018-02-14 0:02 GMT+08:00 Paolo Bonzini : > On 05/02/2018 07:57, Wanpeng Li wrote: >> From: Wanpeng Li >> >> If host CPUs are dedicated to a VM, we can avoid VM exits on HLT. >> This patch adds the per-VM non-HLT-exiting capability. >> >> Cc: Paolo Bonzini >> Cc: Radim Kr=C4=8Dm=C3=A1=C5=99 >> Signed-off-by: Wanpeng Li >> --- >> v1 -> v2: >> * vmx_clear_hlt() around INIT handling >> * vmx_clear_hlt() upon SMI and implement auto halt restart > > Hi Wanpeng, > > sorry I could not answer before. > > We do not need to implement AutoHalt. It's a messy functionality and > the way it works is much simpler: on RSM the microcode reads AutoHALT's > bit 0 and... decrements RIP if it is 1. All you need to do however is > clear the activity state. Guests should expect anyway that "CLI;HLT" > can be interrupted by an NMI and follow it with a JMP. Thanks for pointing out. > > Second, I would prefer to implement at the same time MWAIT and PAUSE > passthrough, as in https://www.spinics.net/lists/kvm/msg159517.html: Understand. > >> The three capabilities are more or less all doing the same thing. >> Perhaps it would make some sense to only leave PAUSE spin loops in >> guest, but not HLT/MWAIT; but apart from that I think users would >> probably enable all of them. So I think we should put in the >> documentation that blindly passing the KVM_CHECK_EXTENSION result to >> KVM_ENABLE_CAP is a valid thing to do when vCPUs are associated to >> dedicated physical CPUs. >> >> Let's get rid of KVM_CAP_X86_GUEST_MWAIT altogether and >> add a new capability. But let's use just one. > > Thanks again for your work, and sorry for slightly contradicting Radim's > review. I've rebased and applied patch 2. No problem. You and Radim's review is always appreciated and helpful. Regards, Wanpeng Li