On Wed, Sep 03, 2025 at 01:45:27AM +0800, Edgecombe, Rick P wrote: > On Tue, 2025-09-02 at 10:37 -0700, Sean Christopherson wrote: > > > If there is a flag we could check it, but we did not ask for one here. We > > > already have a situation where there are bug fixes that KVM depends on, with > > > no way to check. > > > > > > I guess the difference here is that if the behavior is missing, KVM has an > > > option to continue with just small pages. But at the same time, huge pages > > > is very likely to succeed in either case. The "feature" is closer to closing > > > a theoretical race. So very much like the many bugs we don't check for. I'm > > > leaning towards lumping it into that category. And we can add "how do we > > > want to check for TDX module bugs" to the arch todo list. But it's probably > > > down the list, if we even want to do anything. > > > > > > What do you think? > > > > Could we taint the kernel and print a scary message if a known-buggy TDX > > module is loaded? > > If we know which TDX modules have bugs, I guess. There may be some bugs that > only affect the guest, where tainting would not be appropriate. Probably would > want to do it at TDX module load time, so that people that don't use TDX don't > get their kernel tainted from an old TDX module in the BIOS. > > What would you want a TDX module interface for this to look like? Like a bitmap > of fixed bugs? KVM keeps a list of bugs it cares about and compares it to the > list provided by TDX module? I think it could work if KVM is ok selecting and > keeping a bitmap of TDX module bugs. Specific to the problem of TDX_INTERRUPTED_RESTARTABLE, could we choose to port this feature to all old TDX modules?
