Received: by 2002:ab2:3350:0:b0:1f4:6588:b3a7 with SMTP id o16csp734456lqe; Sun, 7 Apr 2024 01:04:03 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCXIuR430vKeHQ0hKZAsDpSCvgbrDyxzxV8BISO+apTGbPVhH3J9WNfIAbILz4G/khvHR+/4rMbapfRR4GSNkfZ/ykvp4SLOJzZ/ERkc9A== X-Google-Smtp-Source: AGHT+IHj8tqB2axmrZ3nIvDC5CDZDwcxPyEiul86cAKYXeQHKfhDmplxpXLdius/XmIaeh9LhAza X-Received: by 2002:a05:6a20:438e:b0:1a1:878d:d3f6 with SMTP id i14-20020a056a20438e00b001a1878dd3f6mr6964962pzl.26.1712477042774; Sun, 07 Apr 2024 01:04:02 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1712477042; cv=pass; d=google.com; s=arc-20160816; b=yMANveiAf+7Ubwj5XFnQU8yaNiucEoV8HPjZTRs3og7b3nKQOKVKtmzeocBylUB80d p9hCQPDSa62INKrRni4eveoGvAzhi/dUcvriqCu+lqbmt88cmOzwADa8EeJssTgRWDRy qLypbiXFjMN3gL1zqQpx47KcA6y+TcY3mdWeIvwhVpQEmKp/hvNWExvTspbcNI0VoRDI pTp9UIG8X2zq5VjE/Thd3WIcWrH+7J+F6LwbVUvBP1tSkD/vY6YssV+I6+Ehb/1YoF6i 2O8dgzGv22MxBaU+hkX9DdZsj1fO/GexZGvqWXqLUQCpdmV5pm9sXlux8puFuKekbHuz rmug== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:from:references:cc:to:subject :user-agent:mime-version:list-unsubscribe:list-subscribe:list-id :precedence:date:message-id:dkim-signature; bh=8DW4j+tmEMyYpB/8f1mBKX7jaELBMskgujRxpxm+Uo8=; fh=VW4yAPNdzA/pjnB0g8MIYVGlB8pyvz3QV7bznXDNeA4=; b=UKS+7yYy+ggmW54RK9rwFwp4dltz2WrpOhHsRp3nowYICEpqqdyS2La5BFC5MWhCAg B0i8apePnD9m7krGfERF/DsDfOdZLSZ7QWQRLnQy+iGk4IgMRUyPGPiyntswlAPXIDNp LuzUjXmwrrjdAalpOBKhbWcj+qATDykrlKxix9fh5tM/wXMUBKD0Gzud4lEKSa0rIt8p 90ggU+VhI451ZlqdWPXxpyXpw/CgxHSswMLIKuGt78tWudWo23hEazgSQ32Vz/PEAI0H q+b74CMn5+stJMMzYG4Kbfmar1v2ee40NhvQw2ODplvMKKPsDz/CGD3Tn/llnjhUbseh AeCA==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="Pf/7woyR"; arc=pass (i=1 dkim=pass dkdomain=intel.com dmarc=pass fromdomain=linux.intel.com); spf=pass (google.com: domain of linux-kernel+bounces-134177-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-134177-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [2604:1380:45e3:2400::1]) by mx.google.com with ESMTPS id f2-20020a056a0022c200b006e6500001e9si4288462pfj.356.2024.04.07.01.04.02 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 07 Apr 2024 01:04:02 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-134177-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="Pf/7woyR"; arc=pass (i=1 dkim=pass dkdomain=intel.com dmarc=pass fromdomain=linux.intel.com); spf=pass (google.com: domain of linux-kernel+bounces-134177-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-134177-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 2B048282B9C for ; Sun, 7 Apr 2024 05:37:17 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 9521D6FC3; Sun, 7 Apr 2024 05:37:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="Pf/7woyR" Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2BCD2184D; Sun, 7 Apr 2024 05:37:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.19 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712468226; cv=none; b=GG/uww5TFzXKeCMfiIOzmN6DRn1ld86bgTXh19JaC4SURCPDvYezm6zQfm3kyYwZw+KPCBxjQTqCM95okP4hyVSc6GO+FWvPPc6CbNOyoPxORc8QkxjZWGbXsjLOBs8zN5hVrDudFo5pfLspnXNExByrhRZexxlcJxnWRxjyxCQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712468226; c=relaxed/simple; bh=p1++XEct0zqjkvfqOY79k0HaC8ytkpJhtyCReqfXBWo=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=HLQpX7VUl6ZoMSX2NVjh/WPzGQUdk1Cean7dCqa3+IwS1OOwjO1JwZbpvTWkXvfq5D574AfKBuBUqYwJaudbUsrItGDQC/JtRh6/5mUDG2v2pZyR6ImFAgnZE4NhaeRwarh+OWeIilTVO2xk6K3JFCxLusEBhCF8rf9AIQbQr8w= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=Pf/7woyR; arc=none smtp.client-ip=198.175.65.19 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1712468225; x=1744004225; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=p1++XEct0zqjkvfqOY79k0HaC8ytkpJhtyCReqfXBWo=; b=Pf/7woyRL+Ie8O5R00MnnMOVMQ4RdPQcy2C/OibEjUhg/eyBRnAi7enC ERrcYYtMyIbBHk4/FKeSUv0wqC1IAvf3GXWI89UwBcj1pD/U1OmXe7kYP 8ukG0rBVqHZEhL5dSlTI8DS+V+gIRIxS7HcGo0dUgsg5OWUEZYzVOarky G4osX1q0YHrfiKyRkxxHjfVwqumaOnhZZlEhNjUROGq2652DaJ0lC61/w XEmz4qS+JcKKaAFNuziYxsSU54FLZuMrg6CO2sYDF38P9wRPWus5f0hye QFfKz7IHGl/IHIRkr+UBoXNJS3zNYsGphWHWymS4GoujF950w2I2w12Mf w==; X-CSE-ConnectionGUID: Ax+siIQiR+S70+vvq7Qm1A== X-CSE-MsgGUID: tsfNep0QRMOaJHAZapQCow== X-IronPort-AV: E=McAfee;i="6600,9927,11036"; a="7621846" X-IronPort-AV: E=Sophos;i="6.07,184,1708416000"; d="scan'208";a="7621846" Received: from fmviesa003.fm.intel.com ([10.60.135.143]) by orvoesa111.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Apr 2024 22:37:04 -0700 X-CSE-ConnectionGUID: DrxeY2GYTOqwLNTdzyBxIQ== X-CSE-MsgGUID: g5DrH5lsQd6L7ZYsAR2Cdg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,184,1708416000"; d="scan'208";a="24043213" Received: from binbinwu-mobl.ccr.corp.intel.com (HELO [10.124.236.140]) ([10.124.236.140]) by fmviesa003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Apr 2024 22:37:01 -0700 Message-ID: Date: Sun, 7 Apr 2024 13:36:46 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v19 081/130] KVM: x86: Allow to update cached values in kvm_user_return_msrs w/o wrmsr To: isaku.yamahata@intel.com Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, isaku.yamahata@gmail.com, Paolo Bonzini , erdemaktas@google.com, Sean Christopherson , Sagi Shahar , Kai Huang , chen.bo@intel.com, hang.yuan@intel.com, tina.zhang@intel.com, Chao Gao References: From: Binbin Wu In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2/26/2024 4:26 PM, isaku.yamahata@intel.com wrote: > From: Chao Gao > > Several MSRs are constant and only used in userspace(ring 3). But VMs may > have different values. KVM uses kvm_set_user_return_msr() to switch to > guest's values and leverages user return notifier to restore them when the > kernel is to return to userspace. To eliminate unnecessary wrmsr, KVM also > caches the value it wrote to an MSR last time. > > TDX module unconditionally resets some of these MSRs to architectural INIT > state on TD exit. It makes the cached values in kvm_user_return_msrs are                                                                        ^                                                                extra "are" > inconsistent with values in hardware. This inconsistency needs to be > fixed. Otherwise, it may mislead kvm_on_user_return() to skip restoring > some MSRs to the host's values. kvm_set_user_return_msr() can help correct > this case, but it is not optimal as it always does a wrmsr. So, introduce > a variation of kvm_set_user_return_msr() to update cached values and skip > that wrmsr. > > Signed-off-by: Chao Gao > Signed-off-by: Isaku Yamahata > Reviewed-by: Paolo Bonzini > --- > arch/x86/include/asm/kvm_host.h | 1 + > arch/x86/kvm/x86.c | 25 ++++++++++++++++++++----- > 2 files changed, 21 insertions(+), 5 deletions(-) > > diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h > index 36694e784c27..3ab85c3d86ee 100644 > --- a/arch/x86/include/asm/kvm_host.h > +++ b/arch/x86/include/asm/kvm_host.h > @@ -2259,6 +2259,7 @@ int kvm_pv_send_ipi(struct kvm *kvm, unsigned long ipi_bitmap_low, > int kvm_add_user_return_msr(u32 msr); > int kvm_find_user_return_msr(u32 msr); > int kvm_set_user_return_msr(unsigned index, u64 val, u64 mask); > +void kvm_user_return_update_cache(unsigned int index, u64 val); > > static inline bool kvm_is_supported_user_return_msr(u32 msr) > { > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index b361d948140f..1b189e86a1f1 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -440,6 +440,15 @@ static void kvm_user_return_msr_cpu_online(void) > } > } > > +static void kvm_user_return_register_notifier(struct kvm_user_return_msrs *msrs) > +{ > + if (!msrs->registered) { > + msrs->urn.on_user_return = kvm_on_user_return; > + user_return_notifier_register(&msrs->urn); > + msrs->registered = true; > + } > +} > + > int kvm_set_user_return_msr(unsigned slot, u64 value, u64 mask) > { > unsigned int cpu = smp_processor_id(); > @@ -454,15 +463,21 @@ int kvm_set_user_return_msr(unsigned slot, u64 value, u64 mask) > return 1; > > msrs->values[slot].curr = value; > - if (!msrs->registered) { > - msrs->urn.on_user_return = kvm_on_user_return; > - user_return_notifier_register(&msrs->urn); > - msrs->registered = true; > - } > + kvm_user_return_register_notifier(msrs); > return 0; > } > EXPORT_SYMBOL_GPL(kvm_set_user_return_msr); > > +/* Update the cache, "curr", and register the notifier */ Not sure this comment is necessary, since the code is simple. > +void kvm_user_return_update_cache(unsigned int slot, u64 value) As a public API, is it better to use "kvm_user_return_msr_update_cache" instead of "kvm_user_return_update_cache"? Although it makes the API name longer... > +{ > + struct kvm_user_return_msrs *msrs = this_cpu_ptr(user_return_msrs); > + > + msrs->values[slot].curr = value; > + kvm_user_return_register_notifier(msrs); > +} > +EXPORT_SYMBOL_GPL(kvm_user_return_update_cache); > + > static void drop_user_return_notifiers(void) > { > unsigned int cpu = smp_processor_id();