On Fri, Aug 29, 2025, Rick P Edgecombe wrote: > On Fri, 2025-08-29 at 15:02 -0700, Sean Christopherson wrote: > > On Fri, Aug 29, 2025, Rick P Edgecombe wrote: > > > On Fri, 2025-08-29 at 13:19 -0700, Sean Christopherson wrote: > > > > I'm happy to include more context in the changelog, but I really don't want > > > > anyone to walk away from this thinking that pinning pages in random KVM code > > > > is at all encouraged. > > > > > > Sorry for going on a tangent. Defensive programming inside the kernel is a > > > little more settled. But for defensive programming against the TDX module, there > > > are various schools of thought internally. Currently we rely on some > > > undocumented behavior of the TDX module (as in not in the spec) for correctness. > > > > Examples? > > I was thinking about the BUSY error code avoidance logic that is now called > tdh_do_no_vcpus(). We assume no new conditions will appear that cause a > TDX_OPERAND_BUSY. Like a guest opt-in or something. Ah, gotcha. If that happens, that's a TDX-Module ABI break. Probably a good idea to drill it into the TDX-Module authors/designers that ABI is established when behavior is visible to the user, regardless of whether or not that behavior is formally defined. Note, breaking ABI _can_ be fine, e.g. if the behavior of some SEAMCALL changes, but KVM doesn't care. But if the TDX-Module suddenly starts failing a SEAMCALL that previously succeeded, then we're going to have a problem. > It's on our todo list to transition those assumptions to promises. We just need > to formalize them.
