Received-SPF: pass (google.com: domain of linux-kernel+bounces-180607-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Date: Thu, 16 May 2024 11:56:05 +0800
From: Yan Zhao <yan.y.zhao@intel.com>
To: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
CC: "seanjc@google.com" <seanjc@google.com>, "isaku.yamahata@gmail.com"
	<isaku.yamahata@gmail.com>, "Huang, Kai" <kai.huang@intel.com>,
	"sagis@google.com" <sagis@google.com>, "linux-kernel@vger.kernel.org"
	<linux-kernel@vger.kernel.org>, "Aktas, Erdem" <erdemaktas@google.com>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>, "kvm@vger.kernel.org"
	<kvm@vger.kernel.org>, "dmatlack@google.com" <dmatlack@google.com>
Subject: Re: [PATCH 02/16] KVM: x86/mmu: Introduce a slot flag to zap only
 slot leafs on slot deletion
Message-ID: <ZkWD1ZrUbK90+3cM@yzhao56-desk.sh.intel.com>
Reply-To: Yan Zhao <yan.y.zhao@intel.com>
References: <20240515005952.3410568-1-rick.p.edgecombe@intel.com>
 <20240515005952.3410568-3-rick.p.edgecombe@intel.com>
 <b89385e5c7f4c3e5bc97045ec909455c33652fb1.camel@intel.com>
 <ZkUIMKxhhYbrvS8I@google.com>
 <1257b7b43472fad6287b648ec96fc27a89766eb9.camel@intel.com>
 <ZkUVcjYhgVpVcGAV@google.com>
 <ac5cab4a25d3a1e022a6a1892e59e670e5fff560.camel@intel.com>
 <ZkU7dl3BDXpwYwza@google.com>
 <ec40aed73b79f0099ec14293f2d87d0f72e7d67b.camel@intel.com>
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <ec40aed73b79f0099ec14293f2d87d0f72e7d67b.camel@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?Pf+WvqbXW5NCY9Z1myoOqVzK3V96MmI2mhhCJnpaH8D5SSIYBhZCF2Ohb+?=
 =?iso-8859-1?Q?L72ywTxprFlghLDz8JTDGu1Cduoy+81UMP3V61+wLBgXx2uojM3fHcqp6f?=
 =?iso-8859-1?Q?ly3vPyTCFjoEsMOkJB7DV0ll+37R7C711kg5IyxMzSsBkcH0jKAMH1gcWH?=
 =?iso-8859-1?Q?ufDw6h0OwjS2wVxuTrOqKOWbZsL9Xkjv7tRVr+RqgIfQEhKr37X+Q86Xpp?=
 =?iso-8859-1?Q?lmUcW3o1/ikwVyNMDsWQIEEDFVpGObsdZ8EkQNUqAy9T8BT3gpmRLsmgXq?=
 =?iso-8859-1?Q?3zGHzLXf4QQt3MHDa8sUqRsU+XgcilJlvRROARlkmWb6QrbxD9RSHnB5mT?=
 =?iso-8859-1?Q?/7Gmn8OGrMUQKBUeVRidrLEeSnQvYrLbgSzD9jCx8eWaqYQzyc2kn8tGXn?=
 =?iso-8859-1?Q?m0Fe8aH1Qf9rQk4elM0DYOQkH+2MFa0C5jd6YCUkBKvxLjEUQ1YWrcWsCf?=
 =?iso-8859-1?Q?KqV1q6rBcRCtzKliGU+7grmUxA+xc4VILEyd+1cyiXfT6cnKhJZM5M5uWo?=
 =?iso-8859-1?Q?Sk0qzNSBehSBwM/I1CT5iFFwswk/HxREFswENl0KNcxZVyp7ZPszoD/p5B?=
 =?iso-8859-1?Q?PFK4sdG9jusOzM+SH+2VG1YFMTf0LM9wuFivn0FNWmSYS2jtsV7fVphJ0o?=
 =?iso-8859-1?Q?z3/mUTyXAa8/II0552YcoMxLDMBCa85oDcbmoanIOOdiM8n8aBA4pjvaAT?=
 =?iso-8859-1?Q?c6dsgA3+T/hcHA6TL4tyT7ZSijv7Y16O9o8xMWHnFJ6LMqo5ZBqCP2u93f?=
 =?iso-8859-1?Q?33GqSKC1JcVe6P6XTqbyuECF8dzwm1BtE3wsGU/jQxGUsn3YQT/shJYtGJ?=
 =?iso-8859-1?Q?jSOhuylgCAulJZhf32oCllPcoiOgOO6tCsJ6h4DaILp31C+JmE5InrLhhe?=
 =?iso-8859-1?Q?BTCJaFlwFez6XeByZLvR238+USKgs3kmAicY35Mpfi6loZcXEszPRgRMrM?=
 =?iso-8859-1?Q?rL3hoKIYaKb6BGTKXmN2sshxClnkey98/IQBPqBPrtE1RdV0T+EhxdKFYo?=
 =?iso-8859-1?Q?PY1wIX2f3XJu9tWgzjT7jcmbDTuDPv5PWzw6zDH6coyz7OsFx0XeA6DMUh?=
 =?iso-8859-1?Q?if7frgtuEoqGHH+3yFfed4oIPrzRRkUI3fW70+SpT4DE36MVGVBGWOZ+OD?=
 =?iso-8859-1?Q?2PN2N1cr+8QKHZnnNCpM214OhLUSMeZwPG44LPTA7IcIPAXJDxzpWta/wF?=
 =?iso-8859-1?Q?CBApkVLrOrX2efWW//6ljR1SWjBEdWOK35zzzV7upySNCQ3m5GlwyfMpLq?=
 =?iso-8859-1?Q?PdamvNjw2l9IwP/ea+0xpzUNWOjaohKcDkXUKl9r0YGf2ijQKESgGPkHII?=
 =?iso-8859-1?Q?DXO1RF9A8x3DjWJchBGueijFBPWEVXQHd1NiDO5x1lwo2VxQ1qngc+0HSG?=
 =?iso-8859-1?Q?12lvlPAH/ou8rWmSR9dOWWLGK3iJAG8ZHrD80wKfamtHrUpNRKALnmYLbU?=
 =?iso-8859-1?Q?vKjcrAndQg+uEIlWHv0P5RUaTO8Zv7ip8w+Ljr3FFvouRmhYDo87JWtyAQ?=
 =?iso-8859-1?Q?36XsHyX2CPWTjAtKcJ5uhAmuZjhLRBdaYfsfLcj7BBrH4dzX12s3MFpTLz?=
 =?iso-8859-1?Q?CvsIu3DEzjzhnEBfaTnQIqyvED88L7mzOJ/Pfmedy1vGf24FTAbUV8chk9?=
 =?iso-8859-1?Q?I0sO8izbln70o2I1xZHCfv3d9SDXyefD8y?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 1cf46d2b-c4a8-402e-94c5-08dc755c374a
X-MS-Exchange-CrossTenant-AuthSource: DS7PR11MB5966.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 May 2024 03:56:50.6261
 (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: 8UKQKJCVWw3RKTWXW68i1vAH26S99M4czGBuwq3h3dsUNJrrsucL1OHJIe6Ugic4eIRmSscbtTvNzB95/JuuDQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR11MB7463
X-OriginatorOrg: intel.com

On Thu, May 16, 2024 at 07:56:18AM +0800, Edgecombe, Rick P wrote:
> On Wed, 2024-05-15 at 15:47 -0700, Sean Christopherson wrote:
> > > I didn't gather there was any proof of this. Did you have any hunch either
> > > way?
> > 
> > I doubt the guest was able to access memory it shouldn't have been able to
> > access.
> > But that's a moot point, as the bigger problem is that, because we have no
> > idea
> > what's at fault, KVM can't make any guarantees about the safety of such a
> > flag.
> > 
> > TDX is a special case where we don't have a better option (we do have other
> > options,
> > they're just horrible).? In other words, the choice is essentially to either:
> > 
> > ?(a) cross our fingers and hope that the problem is limited to shared memory
> > ???? with QEMU+VFIO, i.e. and doesn't affect TDX private memory.
> > 
> > or 
> > 
> > ?(b) don't merge TDX until the original regression is fully resolved.
> > 
> > FWIW, I would love to root cause and fix the failure, but I don't know how
> > feasible
> > that is at this point.
Me too. So curious about what's exactly broken.

> 
> If we think it is not a security issue, and we don't even know if it can be hit
> for TDX, then I'd be included to go with (a). Especially since we are just
> aiming for the most basic support, and don't have to worry about regressions in
> the classical sense.
> 
> I'm not sure how easy it will be to root cause it at this point. Hopefully Yan
> will be coming online soon. She mentioned some previous Intel effort to
> investigate it. Presumably we would have to start with the old kernel that
> exhibited the issue. If it can still be found...
I tried to reproduce it under the direction from Weijiang, though my NVIDIA card
was of a little difference as the one used by Weijiang.
However, I failed. I'm not sure whether it was because I did it remotely or
whether it was because I didn't spend enough time (since it's not an official
tasks assigned to me and I just did it out of curiosity).

If you think it's worthwhile, I would like to try again locally to see if I will
be lucky enough to reproduce and root-cause it.

But is it possible not to have TDX be pending on this bug/regression?