On Tue, May 07, 2024, Kai Huang wrote: > > > So I think we have consensus to go with the approach that shows in your > > > second diff -- that is to always enable virtualization during module loading > > > for all other ARCHs other than x86, for which we only always enables > > > virtualization during module loading for TDX. > > > > Assuming the other arch maintainers are ok with that approach. If waiting until > > a VM is created is desirable for other architectures, then we'll need to figure > > out a plan b. E.g. KVM arm64 doesn't support being built as a module, so enabling > > hardware during initialization would mean virtualization is enabled for any kernel > > that is built with CONFIG_KVM=y. > > > > Actually, duh. There's absolutely no reason to force other architectures to > > choose when to enable virtualization. As evidenced by the massaging to have x86 > > keep enabling virtualization on-demand for !TDX, the cleanups don't come from > > enabling virtualization during module load, they come from registering cpuup and > > syscore ops when virtualization is enabled. > > > > I.e. we can keep kvm_usage_count in common code, and just do exactly what I > > proposed for kvm_x86_enable_virtualization(). > > > > I have patches to do this, and initial testing suggests they aren't wildly > > broken. I'll post them soon-ish, assuming nothing pops up in testing. They are > > clean enough that they can land in advance of TDX, e.g. in kvm-coco-queue even > > before other architectures verify I didn't break them. > > > > Hi Sean, > > Just want to check with you what is your plan on this? > > Please feel free to let me know if there's anything that I can help. Ah shoot, I posted patches[*] but managed to forget to Cc any of the TDX folks. Sorry :-/ [*] https://lore.kernel.org/all/20240425233951.3344485-1-seanjc@xxxxxxxxxx
