On 6/30/23 14:24, Sean Christopherson wrote: > That said, if this is a sticking point, let's just make enable_tdx off by default, > i.e. force userspace to opt-in. Deployments that *know* they may want to schedule > TDX VMs on the host can simply force the module param. And for everyone else, > since KVM is typically configured as a module by distros, KVM can be unloaded and > reload if the user realizes they want TDX well after the system is up and running. Let's just default it to off for now. If we default it to on, we risk inflicting TDX on existing KVM users that don't want it (by surprise). If it turns out to _that_ big of an inconvenience, we'd have to reverse course and change the default from on=>off. *That* would break existing TDX users when we do it. Gnashing of teeth all around would ensue. On the other hand, if we force TDX users to turn it on from day one, we don't surprise _anyone_ that wasn't asking for it. The only teeth gnashing is for the TDX folks. We could change _that_ down the line if the TDX users get too rowdy. But I'd much rather err on the side of inconveniencing the guys that know they want the snazzy new hardware than those who just want to run plain old VMs. I honestly don't care all that much either way. There's an escape hatch at runtime (reload kvm_intel.ko) no matter what we do.
