Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp486492iog; Thu, 30 Jun 2022 04:51:18 -0700 (PDT) X-Google-Smtp-Source: AGRyM1uj7qD9b2TmKqn9wsw9LP9+NXOw3ybdAI7nRlGCoE3IAtolDI3q5BCjsK9O0J+cn90xOglj X-Received: by 2002:a63:cc53:0:b0:40d:bf0e:21a4 with SMTP id q19-20020a63cc53000000b0040dbf0e21a4mr7144478pgi.162.1656589878077; Thu, 30 Jun 2022 04:51:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1656589878; cv=none; d=google.com; s=arc-20160816; b=pn2jMaMfkkGamvkeM4/xVDZw6qPaOSPuKRbhMT/emFkGlJs4YCkhAeFl1FqRiRyLmP u1/QfMonpqXiv0Rem/Ypw/YUlkA2OvQBvAwr8/LOymlj/kdFp27KxGvaWPmnF3g4IsUx GLFmDS1atR52GiiNDCYVEctH/o9cVntGh1jge9I2s0q3uQT0BT+dnpX6eExIDWVHEs+s Rm84/fXxvb9qdHwnJrQNycMUIhYGJOlWjkg6eq69KVAZW4LJN9xIEPX50ZoswqV+NQz4 IWD4qmLbJT/TMjStzX6fDZOlOCQk9bcrj1ujyHoK5RbNK7z9sBdBWo4SZrbT7W11OOzn x9Cw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent :content-transfer-encoding:references:in-reply-to:date:cc:to:from :subject:message-id:dkim-signature; bh=NiQ19fqPt1vT5AhRlXkI1051ANamYGM2d2EZ5mnghrU=; b=KyCLdxmE1l3BWLq+vgwDEz/0oUIXh1YyxuBkVTAciO+xmObMHBu7o/zx4+2NqzoJB3 6/C90n1R/+1Rsjw2C8kRlid6xsauggi2IZ4xN+6cIYlx4Kpe9YcGrqGS8NV/77i25sCy relDTq02o4aH6eDcn5LPy08zThXEE9fEq7Jv/YMMCL5YevH2e6uOThHGWU8V5Uk39hPW dS4MGwyDN1wbvojtiyR/c4TPkoDXyZWSgAWGmB7yP5Amc8L/wQTM6IaiIGBaLQs9o2YU QAXMzgnjyWc/bP+oouoH5FkShd5FlJUXHATuKtEjyEio5JwRlxXP+NIczl/QuRzgXCUw uNDw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="g/VEfy35"; 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=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id p23-20020a17090adf9700b001ece6d4794fsi6348609pjv.118.2022.06.30.04.51.06; Thu, 30 Jun 2022 04:51:18 -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=@intel.com header.s=Intel header.b="g/VEfy35"; 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=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235170AbiF3Lhj (ORCPT + 99 others); Thu, 30 Jun 2022 07:37:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52490 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235074AbiF3LhU (ORCPT ); Thu, 30 Jun 2022 07:37:20 -0400 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 91B715A44F; Thu, 30 Jun 2022 04:37:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1656589039; x=1688125039; h=message-id:subject:from:to:cc:date:in-reply-to: references:content-transfer-encoding:mime-version; bh=cJOc9pifRuPqoq93Kxnv9kcuAQi7B+at/0gDeNXNrbw=; b=g/VEfy35U6moKwPaE49uV1lTfha11Ef4GJbu6GYXAAhXp43mPUm5S5Tu ZO0kv1LZapu2FcPlltrw58uNGkO2r4U33eANz7N936XOYS+SV7GGNgs/r FfasxhulYmjrGHoV+hvN8rw2AsPhnMxZ0TylisBxVbneeVQTPJtgvayT1 qhJvc/mfuAYlLOmWFFySLsyjWQth+4lSPXs1H1cIACkt40SevffzdpNV1 I5Kmv28gbSOUwMO69fsbe1D42eBoIBhnCRwqqTVrbB/ZgwjwrK/6c7aAk gGONoUlYSKQLGino2tweJIW7QitegZq3bkBwcZ9l3KSIPSEH2FjOaZMfD Q==; X-IronPort-AV: E=McAfee;i="6400,9594,10393"; a="262121654" X-IronPort-AV: E=Sophos;i="5.92,234,1650956400"; d="scan'208";a="262121654" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Jun 2022 04:37:19 -0700 X-IronPort-AV: E=Sophos;i="5.92,234,1650956400"; d="scan'208";a="617947907" Received: from zhihuich-mobl.amr.corp.intel.com (HELO khuang2-desk.gar.corp.intel.com) ([10.212.49.124]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Jun 2022 04:37:17 -0700 Message-ID: Subject: Re: [PATCH v7 035/102] KVM: x86/mmu: Explicitly check for MMIO spte in fast page fault From: Kai Huang To: isaku.yamahata@intel.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org Cc: isaku.yamahata@gmail.com, Paolo Bonzini , Sean Christopherson Date: Thu, 30 Jun 2022 23:37:15 +1200 In-Reply-To: <71e4c19d1dff8135792e6c5a17d3a483bc99875b.1656366338.git.isaku.yamahata@intel.com> References: <71e4c19d1dff8135792e6c5a17d3a483bc99875b.1656366338.git.isaku.yamahata@intel.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.2 (3.44.2-1.fc36) MIME-Version: 1.0 X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_PASS,SPF_NONE,T_SCC_BODY_TEXT_LINE 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: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2022-06-27 at 14:53 -0700, isaku.yamahata@intel.com wrote: > From: Sean Christopherson >=20 > Explicitly check for an MMIO spte in the fast page fault flow. TDX will > use a not-present entry for MMIO sptes, which can be mistaken for an > access-tracked spte since both have SPTE_SPECIAL_MASK set. SPTE_SPECIAL_MASK has been removed in latest KVM code. The changelog needs update. In fact, if I understand correctly, I don't think this changelog is correct= : The existing code doesn't check is_mmio_spte() because: 1) If MMIO caching is enabled, MMIO fault is always handled in handle_mmio_page_fault() before reaching here;=20 2) If MMIO caching is disabled, is_shadow_present_pte() always returns fals= e for MMIO spte, and is_mmio_spte() also always return false for MMIO spte, so th= ere's no need check here. "A non-present entry for MMIO spte" doesn't necessarily mean is_shadow_present_pte() will return true for it, and there's no explanation= at all that for TDX guest a MMIO spte could reach here and is_shadow_present_p= te() returns true for it. If this patch is ever needed, it should come with or after the patch (patch= es) that handles MMIO fault for TD guest. Hi Sean, Paolo, Did I miss anything? >=20 > MMIO sptes are handled in handle_mmio_page_fault for non-TDX VMs, so this > patch does not affect them. TDX will handle MMIO emulation through a > hypercall instead. >=20 > Signed-off-by: Sean Christopherson > Signed-off-by: Isaku Yamahata > --- > arch/x86/kvm/mmu/mmu.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) >=20 > diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c > index 17252f39bd7c..51306b80f47c 100644 > --- a/arch/x86/kvm/mmu/mmu.c > +++ b/arch/x86/kvm/mmu/mmu.c > @@ -3163,7 +3163,7 @@ static int fast_page_fault(struct kvm_vcpu *vcpu, s= truct kvm_page_fault *fault) > else > sptep =3D fast_pf_get_last_sptep(vcpu, fault->addr, &spte); > =20 > - if (!is_shadow_present_pte(spte)) > + if (!is_shadow_present_pte(spte) || is_mmio_spte(spte)) > break; > =20 > sp =3D sptep_to_sp(sptep);