Message ID | 20221021153521.1216911-14-vkuznets@redhat.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4242:0:0:0:0:0 with SMTP id s2csp764750wrr; Fri, 21 Oct 2022 08:38:06 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6ouqKKpKKgATrqH0/GVHvfP5bWXAa3dxoXmDpK1+aFWlOkCoH1RdnQElPY4aXbFBdNimY0 X-Received: by 2002:a17:907:760c:b0:78d:b37f:5ce4 with SMTP id jx12-20020a170907760c00b0078db37f5ce4mr15536999ejc.50.1666366686749; Fri, 21 Oct 2022 08:38:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666366686; cv=none; d=google.com; s=arc-20160816; b=GnGynG00BR0+rqvfyIc0vb99o8iZ8fBo5Wl5tActuiJqjv9AW5ho+K3lrSpPm51ZBj 7TlXLcjrgL8VWVArzyDFwbaHg5AbPMru8iQObLCuipJn/TxTq6VyzRqPHHYvImTcm/5u JlCRTRueiQH5igZHT84j3A5P6T32BL9+Kid1yuUGnX/nhdkjEw48VDhJR10FEBgk0vda swztvDpcMkJ32hwoNfxRHwW1rW1A09QIJnkG14zq1/rWyJzMJ709jtoxsLPmrVPcCnDU 7MTN8hX8dM876hQvQYqodQk4v+47rEWCPgR0CW/IPjXycaFPrEbDd7JIxF/3mjwYvk98 X45Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=uYQDVWYA587h/Kln9OtjlnRjb/cKMO5lumdfQpLByKo=; b=P3VkRaG7THYiYPj4tOsmkqfJGIbG2zVRn2GWtBAUgKhq58ciYYHH+nY4/gstoqXldv y0smhQq5pU6FfscbzxLrknjWthrbbQeEXsNGK2KrR35BIvDRu3QC7p8K6zVkG1n3U8Nr g2gLIyHuzUiaBpJJs5WR0RRv9X8v0LEMqzank2rKazYZ2RDfCVo3GQNDILt2bs5VmLFQ KyDwgMSuj0xTby5H7RDZxdyI2mD0aKlf66+Onw8vejCMOrsJ2ZXCsJVGT2Dh0Dalp0qK 5SQ1P72BhwKzNvJNiHI/ZRdT7MFKB9B68YYqnUzxm/P/4DRotbKuqamC2MYSjLK8lH6J Citw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=VaY286bU; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id m3-20020aa7c483000000b0046109fe738bsi3765918edq.477.2022.10.21.08.37.42; Fri, 21 Oct 2022 08:38:06 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=VaY286bU; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230250AbiJUPgu (ORCPT <rfc822;mntrajkot1@gmail.com> + 99 others); Fri, 21 Oct 2022 11:36:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45802 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230429AbiJUPgX (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 21 Oct 2022 11:36:23 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B60AD27354A for <linux-kernel@vger.kernel.org>; Fri, 21 Oct 2022 08:36:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1666366564; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=uYQDVWYA587h/Kln9OtjlnRjb/cKMO5lumdfQpLByKo=; b=VaY286bU6/zphjS7MuxZwy/JeX/iAS5JoJf6eS3GgclZ/DjzFwCbHphObbuDD/TWCwAlLW 8nWu0gBOr9eFTg23jpKtZtoddyT6fssoYz1RpAkNBNLrpqBR5gM0Pjzuc8dNMlrBb81aLN Qo32K1YO3FJ8H0bqeGWYWU6EDcDy8C4= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-611-8Dx5nMiIPJmRFekQc6-JDA-1; Fri, 21 Oct 2022 11:36:00 -0400 X-MC-Unique: 8Dx5nMiIPJmRFekQc6-JDA-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 44F443C1E723; Fri, 21 Oct 2022 15:35:59 +0000 (UTC) Received: from ovpn-192-65.brq.redhat.com (ovpn-192-65.brq.redhat.com [10.40.192.65]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4501D40CA41F; Fri, 21 Oct 2022 15:35:57 +0000 (UTC) From: Vitaly Kuznetsov <vkuznets@redhat.com> To: kvm@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>, Sean Christopherson <seanjc@google.com> Cc: Wanpeng Li <wanpengli@tencent.com>, Jim Mattson <jmattson@google.com>, Michael Kelley <mikelley@microsoft.com>, Siddharth Chandrasekaran <sidcha@amazon.de>, Yuan Yao <yuan.yao@linux.intel.com>, Maxim Levitsky <mlevitsk@redhat.com>, linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v12 13/46] KVM: x86: Prepare kvm_hv_flush_tlb() to handle L2's GPAs Date: Fri, 21 Oct 2022 17:34:48 +0200 Message-Id: <20221021153521.1216911-14-vkuznets@redhat.com> In-Reply-To: <20221021153521.1216911-1-vkuznets@redhat.com> References: <20221021153521.1216911-1-vkuznets@redhat.com> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.1 on 10.11.54.1 X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1747312115126274244?= X-GMAIL-MSGID: =?utf-8?q?1747312115126274244?= |
Series |
KVM: x86: hyper-v: Fine-grained TLB flush + L2 TLB flush features
|
|
Commit Message
Vitaly Kuznetsov
Oct. 21, 2022, 3:34 p.m. UTC
To handle L2 TLB flush requests, KVM needs to translate the specified L2 GPA to L1 GPA to read hypercall arguments from there. No functional change as KVM doesn't handle VMCALL/VMMCALL from L2 yet. Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> --- arch/x86/kvm/hyperv.c | 7 +++++++ 1 file changed, 7 insertions(+)
Comments
On Fri, Oct 21, 2022, Vitaly Kuznetsov wrote: > To handle L2 TLB flush requests, KVM needs to translate the specified > L2 GPA to L1 GPA to read hypercall arguments from there. > > No functional change as KVM doesn't handle VMCALL/VMMCALL from L2 yet. > > Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com> > Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> > --- > arch/x86/kvm/hyperv.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c > index fca9c51891f5..df1efb821eb0 100644 > --- a/arch/x86/kvm/hyperv.c > +++ b/arch/x86/kvm/hyperv.c > @@ -23,6 +23,7 @@ > #include "ioapic.h" > #include "cpuid.h" > #include "hyperv.h" > +#include "mmu.h" > #include "xen.h" > > #include <linux/cpu.h> > @@ -1908,6 +1909,12 @@ static u64 kvm_hv_flush_tlb(struct kvm_vcpu *vcpu, struct kvm_hv_hcall *hc) > */ > BUILD_BUG_ON(KVM_HV_MAX_SPARSE_VCPU_SET_BITS > 64); > > + if (!hc->fast && is_guest_mode(vcpu)) { Please add a comment explaining why only "slow" hypercalls need to translate the GPA from L2=>L1. With a comment (and assuming this isn't a bug), Reviewed-by: Sean Christopherson <seanjc@google.com>
Sean Christopherson <seanjc@google.com> writes: > On Fri, Oct 21, 2022, Vitaly Kuznetsov wrote: >> To handle L2 TLB flush requests, KVM needs to translate the specified >> L2 GPA to L1 GPA to read hypercall arguments from there. >> >> No functional change as KVM doesn't handle VMCALL/VMMCALL from L2 yet. >> >> Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com> >> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> >> --- >> arch/x86/kvm/hyperv.c | 7 +++++++ >> 1 file changed, 7 insertions(+) >> >> diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c >> index fca9c51891f5..df1efb821eb0 100644 >> --- a/arch/x86/kvm/hyperv.c >> +++ b/arch/x86/kvm/hyperv.c >> @@ -23,6 +23,7 @@ >> #include "ioapic.h" >> #include "cpuid.h" >> #include "hyperv.h" >> +#include "mmu.h" >> #include "xen.h" >> >> #include <linux/cpu.h> >> @@ -1908,6 +1909,12 @@ static u64 kvm_hv_flush_tlb(struct kvm_vcpu *vcpu, struct kvm_hv_hcall *hc) >> */ >> BUILD_BUG_ON(KVM_HV_MAX_SPARSE_VCPU_SET_BITS > 64); >> >> + if (!hc->fast && is_guest_mode(vcpu)) { > > Please add a comment explaining why only "slow" hypercalls need to translate the > GPA from L2=>L1. > > With a comment (and assuming this isn't a bug), This is intended, For "slow" hypercalls 'hc->ingpa' is the GPA (or an 'nGPA' -- thus the patch) in guest memory where hypercall parameters are placed, kvm reads them with kvm_read_guest() later. For "fast" hypercalls 'ingpa' is a misnomer as it is not an address but the first parameter (in the 'tlb flush' case it's 'address space id' which we currently don't analyze). We may want to add a union in 'struct kvm_hv_hcall' to make this explicit. The comment I'm thinking of would be: " /* * 'Slow' hypercall's first parameter is the address in guest's memory where * hypercall parameters are placed. This is either a GPA or a nested GPA when * KVM is handling the call from L2 ('direct' TLB flush), translate the address * here so the memory can be uniformly read with kvm_read_guest(). */ " > > Reviewed-by: Sean Christopherson <seanjc@google.com> >
On Thu, Oct 27, 2022, Vitaly Kuznetsov wrote: > Sean Christopherson <seanjc@google.com> writes: > > > On Fri, Oct 21, 2022, Vitaly Kuznetsov wrote: > >> @@ -1908,6 +1909,12 @@ static u64 kvm_hv_flush_tlb(struct kvm_vcpu *vcpu, struct kvm_hv_hcall *hc) > >> */ > >> BUILD_BUG_ON(KVM_HV_MAX_SPARSE_VCPU_SET_BITS > 64); > >> > >> + if (!hc->fast && is_guest_mode(vcpu)) { > > > > Please add a comment explaining why only "slow" hypercalls need to translate the > > GPA from L2=>L1. > > > > With a comment (and assuming this isn't a bug), > > This is intended, > > For "slow" hypercalls 'hc->ingpa' is the GPA (or an 'nGPA' -- thus the > patch) in guest memory where hypercall parameters are placed, kvm reads > them with kvm_read_guest() later. For "fast" hypercalls 'ingpa' is a > misnomer as it is not an address but the first parameter (in the 'tlb > flush' case it's 'address space id' which we currently don't > analyze). We may want to add a union in 'struct kvm_hv_hcall' to make > this explicit. Ya, a union would be helpful. I'm pretty sure at some point I knew the "fast" ingpa isn't actually a GPA, but obviously forgot that detail.
diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c index fca9c51891f5..df1efb821eb0 100644 --- a/arch/x86/kvm/hyperv.c +++ b/arch/x86/kvm/hyperv.c @@ -23,6 +23,7 @@ #include "ioapic.h" #include "cpuid.h" #include "hyperv.h" +#include "mmu.h" #include "xen.h" #include <linux/cpu.h> @@ -1908,6 +1909,12 @@ static u64 kvm_hv_flush_tlb(struct kvm_vcpu *vcpu, struct kvm_hv_hcall *hc) */ BUILD_BUG_ON(KVM_HV_MAX_SPARSE_VCPU_SET_BITS > 64); + if (!hc->fast && is_guest_mode(vcpu)) { + hc->ingpa = translate_nested_gpa(vcpu, hc->ingpa, 0, NULL); + if (unlikely(hc->ingpa == INVALID_GPA)) + return HV_STATUS_INVALID_HYPERCALL_INPUT; + } + if (hc->code == HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST || hc->code == HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE) { if (hc->fast) {