Received-SPF: pass (google.com: domain of linux-kernel+bounces-118301-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Tue, 26 Mar 2024 10:32:28 +0800
From: Chao Gao <chao.gao@intel.com>
To: Isaku Yamahata <isaku.yamahata@intel.com>
CC: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>, "Zhang, Tina"
	<tina.zhang@intel.com>, "seanjc@google.com" <seanjc@google.com>, "Huang, Kai"
	<kai.huang@intel.com>, "kvm@vger.kernel.org" <kvm@vger.kernel.org>, "Chen,
 Bo2" <chen.bo@intel.com>, "sagis@google.com" <sagis@google.com>,
	"isaku.yamahata@gmail.com" <isaku.yamahata@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "Aktas, Erdem"
	<erdemaktas@google.com>, "pbonzini@redhat.com" <pbonzini@redhat.com>,
	"sean.j.christopherson@intel.com" <sean.j.christopherson@intel.com>, "Yuan,
 Hang" <hang.yuan@intel.com>, "isaku.yamahata@linux.intel.com"
	<isaku.yamahata@linux.intel.com>
Subject: Re: [PATCH v19 059/130] KVM: x86/tdp_mmu: Don't zap private pages
 for unsupported cases
Message-ID: <ZgIzvHKobT2K8LZb@chao-email>
References: <1c2283aab681bd882111d14e8e71b4b35549e345.camel@intel.com>
 <f63d19a8fe6d14186aecc8fcf777284879441ef6.camel@intel.com>
 <20240321225910.GU1994522@ls.amr.corp.intel.com>
 <96fcb59cd53ece2c0d269f39c424d087876b3c73.camel@intel.com>
 <20240325190525.GG2357401@ls.amr.corp.intel.com>
 <5917c0ee26cf2bb82a4ff14d35e46c219b40a13f.camel@intel.com>
 <20240325221836.GO2357401@ls.amr.corp.intel.com>
 <20240325231058.GP2357401@ls.amr.corp.intel.com>
 <edcfc04cf358e6f885f65d881ef2f2165e059d7e.camel@intel.com>
 <20240325233528.GQ2357401@ls.amr.corp.intel.com>
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20240325233528.GQ2357401@ls.amr.corp.intel.com>
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?iso-8859-1?Q?Y4LzYa0NZ7ymT5zUeKwxc1ZbfP98OVXaJ4xcjFh7czwwHuZIr2axdobTKM?=
 =?iso-8859-1?Q?wU2+iy4qb6Z94UwcfpqDOGd+Ptel5jxNtRPgdRPHVhFL570JrnXzy/I995?=
 =?iso-8859-1?Q?pe6JySWA6dYks8RYKnKlLyI85vNszEcyrp2rlbKn6u4nuCBdVmb8Q+beNz?=
 =?iso-8859-1?Q?Z2PKjqLZQBpav8NeW+lu8tURRo58qM3YspRUDEuh7d+ln4f+bYJPoEjNcU?=
 =?iso-8859-1?Q?Y2stsfquk90gZqzFZ1f42WjdsqlDUTEBSkvELVUolLcrUvl8FfdYkHLNPt?=
 =?iso-8859-1?Q?B4y+tMsrE8CcSDdZHv33D1tBvWZVhkqvKn6ArC3JbUwgXDBwrnz8Ic3p3S?=
 =?iso-8859-1?Q?+BO+rudLpfXBJM4+gDJwSkPAZ1jOT6WdFyoe+KeJoa4oW+yOZdhZ8gshS8?=
 =?iso-8859-1?Q?hIxAIj1OpMFSPYanDZrt44E5bism92K2PYE74ZiqYFpIA59MwWQBXbyj9K?=
 =?iso-8859-1?Q?csYf3hz+0FU/CF4ogQccuFOegPwJt6JHq+U8IWAMeEs+kzQ8LoAT1iZWDp?=
 =?iso-8859-1?Q?Tahfp0IeHgkXtzTuSLWCHc1uAnfjT7Z37vZ+l3YLvokFxs3UJiOGP8gK/8?=
 =?iso-8859-1?Q?wEorGNH9bIFmjyK9XDvAd63eUnP/JbJ74zUtL5D7AVf0qeLO9NMfgjYpTR?=
 =?iso-8859-1?Q?NwS6dyqZNhjCyqFnFsrl14nr6HFLKJG47dvR2QabPgF4kDvOinkmTMcTH6?=
 =?iso-8859-1?Q?FJ9uKgbv/LBfoMLvTJLGQHrBfjzOFpnCfxUj3Z379rZk7axuskHRC/+7ov?=
 =?iso-8859-1?Q?FFdshdkcvUpwtliYZ/VYgBtTRsmv/YPbUmo1NpX6K0BW5sKY974KQF75lW?=
 =?iso-8859-1?Q?g3npKoIdbJKVSyRHfNrSqHypYABTr3GyZP6OddCFU6YE7jkm5dkjFOKscJ?=
 =?iso-8859-1?Q?QeWThYrym2e8hZ9MOfRl5mMhCGZl7Hq/otmB2Wo+G3acG+2Gg1ExsmWdfV?=
 =?iso-8859-1?Q?1X3qwDsUzdBQFFwfUJIji4ntqljTAF/JfXHtUJjqJiIp5xFN4o9UTLE3xm?=
 =?iso-8859-1?Q?Vg3ohniHMnntS4GQ0sjuxpMlc7O4y+ukM7+UfFUrw+Og+u+X4jpa14CXrS?=
 =?iso-8859-1?Q?3P73fRZ2AwI72lWXLoGcVqwKsNqwXqN7U+UA2yDgV/oUmEPU7kH24MiJsx?=
 =?iso-8859-1?Q?ELC7nA5WdfP4SGY9gvNGNNLrLr6Ipnk0a8KKC1VYgkaS23RVRc5MC+27sQ?=
 =?iso-8859-1?Q?iLwLP6udFH+rknrmfPvEXA+yPZCXnWC0L0joVbArdoCKehlqEZO2C9qiiB?=
 =?iso-8859-1?Q?KjbVUvaJ0wVB5uNxy7QNRM+vYg+2OI+m15ivnGZ3jfpLCS0a4G/KN0ZFoQ?=
 =?iso-8859-1?Q?O4x89UJ2XiEGlktZR0O5A4sREtOmGtZs/StJQk7ITIrbYGSJAx1fBaWxfW?=
 =?iso-8859-1?Q?7IS+JRzR2aPNnspPXXmhfdqKNf+0n6f2A6r4JO5NS2ZvwI2o+CSec4uGxm?=
 =?iso-8859-1?Q?MPV6qP2AUshGctxOcD0r1joZUkOpwBQKjGSO6qiuaOUSfP76S95gr6eW5T?=
 =?iso-8859-1?Q?wI62Mzg+sYht1D/lqLa9r8qG3wlrwMoMgBKPBMiEnemd48EcU6hFXAQoW0?=
 =?iso-8859-1?Q?AnwklzZYK10iusX1oYr6+SL2I4UeOJFJ8gXO9Zynq8m96lhSRs59ipDRs2?=
 =?iso-8859-1?Q?+aFc6Yddg6jG9PGJFMBOLtbJx6XimIlLA0?=
X-MS-Exchange-CrossTenant-Network-Message-Id: a0f7b1bc-b635-4ec5-88a4-08dc4d3d00f4
X-MS-Exchange-CrossTenant-AuthSource: CH3PR11MB8660.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Mar 2024 02:32:38.5747
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 8COOFe8e4hmWxtaOb9NamPnrZHOKWeZYj18kaBf/500sTRN0OEpN526KwSPVv6x25ULIt09Hrc9sc2qWHMp+5w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR11MB8403
X-OriginatorOrg: intel.com

On Mon, Mar 25, 2024 at 04:35:28PM -0700, Isaku Yamahata wrote:
>On Mon, Mar 25, 2024 at 11:21:17PM +0000,
>"Edgecombe, Rick P" <rick.p.edgecombe@intel.com> wrote:
>
>> On Mon, 2024-03-25 at 16:10 -0700, Isaku Yamahata wrote:
>> > > > My understanding is that Sean prefers to exit to userspace when KVM can't handle something,
>> > > > versus
>> > > > making up behavior that keeps known guests alive. So I would think we should change this patch
>> > > > to
>> > > > only be about not using the zapping roots optimization. Then a separate patch should exit to
>> > > > userspace on attempt to use MTRRs. And we ignore the APIC one.
>> > > > 
>> > > > This is trying to guess what maintainers would want here. I'm less sure what Paolo prefers.
>> > > 
>> > > When we hit KVM_MSR_FILTER, the current implementation ignores it and makes it
>> > > error to guest.? Surely we should make it KVM_EXIT_X86_{RDMSR, WRMSR}, instead.
>> > > It's aligns with the existing implementation(default VM and SW-protected) and
>> > > more flexible.
>> > 
>> > Something like this for "112/130 KVM: TDX: Handle TDX PV rdmsr/wrmsr hypercall"
>> > Compile only tested at this point.
>> 
>> Seems reasonable to me. Does QEMU configure a special set of MSRs to filter for TDX currently?
>
>No for TDX at the moment.  We need to add such logic.

What if QEMU doesn't configure the set of MSRs to filter? In this case, KVM
still needs to handle the MSR accesses.