Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp2690422pxb; Mon, 17 Jan 2022 03:56:46 -0800 (PST) X-Google-Smtp-Source: ABdhPJwprQETNIStFWqewmv5+FMInxEnTuGhFboJCIN8uLAlYM+iLUEL8uMVl5ka2w/08c6u7wSN X-Received: by 2002:a17:902:6844:b0:14a:1da5:88dc with SMTP id f4-20020a170902684400b0014a1da588dcmr22052479pln.30.1642420606558; Mon, 17 Jan 2022 03:56:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1642420606; cv=none; d=google.com; s=arc-20160816; b=jC9Vx4B6oF7fCVbfW2zSPJcQhrD9l5aowIKDdSupJjj2v14JellO+/S32ZYN3WmEUq Z6sx4P1lOir+aEZKR4/N69aCeZgfRV1fdZdtLYEWCb8Pg1uNN3V9QouplavQPcHPvWiE ShKtFCiIt+5iM5V0crmnUnNS4nyGlP840qImZJBBSFcGvik/tlKGBxV/ZU382SfaFD7L CCffZZSkwfv1HrYb6UPZBm5xVgF6chEZhe1Aax24eaa/zGaPhm6Xnblv+7rLWPa4vXwn 6y6uHJKTeRtoiAPPt3JQiVUU0rnYbobsRuWReZNjdCvH6gTr9/rpC0Q2W4tKQp890nLj JNJw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=zcnshIrvHu63ktjO/d0HsCJeBEWnaefm8SBQppjLkK8=; b=pH/+HM+e2OgPxAhWK6OxsT8Wzs70FSBPohcDzxyUdaP1lo+FAnalvMnzR2jzwmmWBF VwSZ70YCr+pyzN8PDkHuN/y5I7UmJztRAm79tZ6bikH8N5fz509uNYQ8q896OrRTrHUV DSE1CtzqJdicl9jcRh1Cwb0WheJn4e+K4zvbboG9shDbfnIwLVXxH/hs2UP5sLkNtZA4 TbXvgU4SsVYgZV9+Wu0b4TehwHOU/ifGuum0jFMy8pERYZjK5EDGp6XdC/kuSnRvCk/q V3AQEGLk7qCjguzg5/BU9xbZdgMETfpSVdnK81LH4Q0YTW7Kozv7wLYUeyYaH40IkXM6 bU6Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=bdS4wD6A; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l9si15424848pls.155.2022.01.17.03.56.30; Mon, 17 Jan 2022 03:56:46 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=bdS4wD6A; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S236911AbiAQDHF (ORCPT + 99 others); Sun, 16 Jan 2022 22:07:05 -0500 Received: from mga12.intel.com ([192.55.52.136]:46396 "EHLO mga12.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234099AbiAQDHD (ORCPT ); Sun, 16 Jan 2022 22:07:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1642388823; x=1673924823; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=R8Sn8SZmhuMPafCTfdZnGovaHJidPy4VsCKLE6frY5I=; b=bdS4wD6AHE+mJ2tHmHW171YjF8JhXjxLB36Hsbsc27Kq4S5wvNKufoAr yT+4jZV3XJGfKRljngwCMX5I2k13+OqzwGFDhT4HlFHsWQtPIiTD/LZ7/ p82Gd6n9yAVqe9yJHHzEn9y/9fCTCixYlzio/9m3tGMa8wxE+2uPqTsW9 EGrgNYTBQNVVubuasV+C/UgdrMxNZWG0znms8zKGtXftAA7wk+BCps7OQ ZfHpesFyWY6fMVdeO98TACgPLT/4pNP6rTaIbInRB6gQzsWOeg3dWbN78 pjtsxJy9vfp7S+TFz8wN9XgetYEw+ucqNBVpkK1WaCR0/DYByMXQMiBB2 A==; X-IronPort-AV: E=McAfee;i="6200,9189,10229"; a="224521886" X-IronPort-AV: E=Sophos;i="5.88,294,1635231600"; d="scan'208";a="224521886" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Jan 2022 19:07:03 -0800 X-IronPort-AV: E=Sophos;i="5.88,294,1635231600"; d="scan'208";a="476489507" Received: from gao-cwp.sh.intel.com (HELO gao-cwp) ([10.239.159.105]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Jan 2022 19:06:58 -0800 Date: Mon, 17 Jan 2022 11:17:52 +0800 From: Chao Gao To: Maxim Levitsky Cc: Sean Christopherson , Zeng Guang , Tom Lendacky , Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , "kvm@vger.kernel.org" , Dave Hansen , "Luck, Tony" , Kan Liang , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Kim Phillips , Jarkko Sakkinen , Jethro Beekman , "Huang, Kai" , "x86@kernel.org" , "linux-kernel@vger.kernel.org" , "Hu, Robert" Subject: Re: [PATCH v5 7/8] KVM: VMX: Update PID-pointer table entry when APIC ID is changed Message-ID: <20220117031750.GA5339@gao-cwp> References: <640e82f3-489d-60af-1d31-25096bef1a46@amd.com> <4eee5de5-ab76-7094-17aa-adc552032ba0@intel.com> <20220110074523.GA18434@gao-cwp> <1ff69ed503faa4c5df3ad1b5abe8979d570ef2b8.camel@redhat.com> <20220114025825.GA3010@gao-cwp> <4b9fb845bf698f7efa6b46d525b37e329dd693ea.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4b9fb845bf698f7efa6b46d525b37e329dd693ea.camel@redhat.com> User-Agent: Mutt/1.9.4 (2018-02-28) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 14, 2022 at 10:17:34AM +0200, Maxim Levitsky wrote: >On Fri, 2022-01-14 at 10:58 +0800, Chao Gao wrote: >> On Thu, Jan 13, 2022 at 10:19:21PM +0000, Sean Christopherson wrote: >> > On Tue, Jan 11, 2022, Maxim Levitsky wrote: >> > > Both Intel and AMD's PRM also state that changing APIC ID is implementation >> > > dependent. >> > > >> > > I vote to forbid changing apic id, at least in the case any APIC acceleration >> > > is used, be that APICv or AVIC. >> > >> > That has my vote as well. For IPIv in particular there's not much concern with >> > backwards compability, i.e. we can tie the behavior to enable_ipiv. >Great! >> >> Hi Sean and Levitsky, >> >> Let's align on the implementation. >> >> To disable changes for xAPIC ID when IPIv/AVIC is enabled: >> >> 1. introduce a variable (forbid_apicid_change) for this behavior in kvm.ko >> and export it so that kvm-intel, kvm-amd can set it when IPIv/AVIC is >> enabled. To reduce complexity, this variable is a module level setting. >> >> 2. when guest attempts to change xAPIC ID but it is forbidden, KVM prints >> a warning on host and injects a #GP to guest. >> >> 3. remove AVIC code that deals with changes to xAPIC ID. >> > >I have a patch for both, I attached them. Looks good to me. We will drop this patch and rely on the first attached patch to forbid guest from changing xAPIC ID. >I haven't tested either of these patches that much other than a smoke test, >but I did test all of the guests I have and none broke in regard to boot. > >I will send those patches as part of larger patch series that implements >nesting for AVIC. I hope to do this next week. Thanks.