On Fri, Jun 30, 2023, Isaku Yamahata wrote: > On Fri, Jun 30, 2023 at 08:30:20PM +0200, > Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > > > On Fri, Jun 30, 2023 at 09:55:32AM +0000, Huang, Kai wrote: > > > On Fri, 2023-06-30 at 11:26 +0200, Peter Zijlstra wrote: > > > > On Thu, Jun 29, 2023 at 12:10:00AM +0000, Huang, Kai wrote: > > > > > On Wed, 2023-06-28 at 15:17 +0200, Peter Zijlstra wrote: > > > > > > On Tue, Jun 27, 2023 at 02:12:37AM +1200, Kai Huang wrote: > > > > > > > +EXPORT_SYMBOL_GPL(tdx_cpu_enable); > > > > > > > > > > > > I can't find a single caller of this.. why is this exported? > > > > > > > > > > It's for KVM TDX patch to use, which isn't in this series. > > > > > > > > > > I'll remove the export. KVM TDX series can export it. > > > > > > > > Fair enough; where will the KVM TDX series call this? Earlier there was > > > > talk about doing it at kvm module load time -- but I objected (and still > > > > do object) to that. > > > > > > > > What's the current plan? > > > > > > > > > > The direction is still doing it during module load (not my series anyway). But > > > this can be a separate discussion with KVM maintainers involved. > > > > They all on Cc afaict. > > > > > I understand you have concern that you don't want to have the memory & cpu time > > > wasted on enabling TDX by default. For that we can have a kernel command line > > > to disable TDX once for all (we can even make it default). > > > > That's insane, I don't want to totally disable it. I want it done at > > guard creation. Do the whole TDX setup the moment you actually create a > > TDX guast. > > > > Totally killing TDX is stupid, I dunno about that, *totally* killing TDX would make my life a lot simpler ;-) > > just about as stupid as doing it on module load (which equates to always > > doing it). > > > > > Also, KVM will have a module parameter 'enable_tdx'. I am hoping this could > > > reduce your concern too. > > > > I don't get this obsession with doing at module load time :/ Waiting until userspace attempts to create the first TDX guest adds complexity and limits what KVM can do to harden itself. Currently, all feature support in KVM is effectively frozen at module load. E.g. most of the setup code is contained in __init functions, many module-scoped variables are effectively RO after init (though they can't be marked as such until we smush kvm-intel.ko and kvm-amd.ko into kvm.ko, which is tentatively the long-term plan). All of those patterns would get tossed aside if KVM waits until userspace attempts to create the first guest. The userspace experience would also be poor, as KVM can't know whether or TDX is actually supported until the TDX module is fully loaded and configured. KVM waits until VM creation to enable VMX, but that's pure enabling and more or less guaranteed to succeed, e.g. will succeed barring hardware failures, software bugs, or *severe* memory pressure. There are also latency and noisy neighbor concerns, e.g. we *really* don't want to end up in a situation where creating a TDX guest for a customer can observe arbitrary latency *and* potentially be disruptive to VMs already running on the host. Userspace can workaround the second and third issues by spawning a dummy TDX guest as early as possible, but that adds complexity to userspace, especially if there's any desire for it to be race free, e.g. with respect to reporting system capabilities to the control plan. On the flip side, limited hardware availability (unless Intel has changed its tune) and the amount of enabling that's required in BIOS and whatnot makes it highly unlikely that random Linux users are going to unknowingly boot with TDX enabled. 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. > The KVM maintainers prefer the initialization on kvm_intel.ko loading time. [1] You can say "Sean", I'm not the bogeyman :-) > I can change enable_tdx parameter for kvm_intel.ko instead of boolean. > Something like > > enable_tdx > ondemand: on-demand initialization when creating the first TDX guest > onload: initialize TDX module when loading kvm_intel.ko No, that's the most complex path and makes no one happy. > disable: disable TDX support
