Messages in this thread | | | Date | Mon, 29 Apr 2024 14:45:25 +1200 | Subject | Re: [PATCH 0/3] KVM: x86: Fix supported VM_TYPES caps | From | "Huang, Kai" <> |
| |
On 27/04/2024 3:47 am, Sean Christopherson wrote: > On Fri, Apr 26, 2024, Kai Huang wrote: >> On Thu, 2024-04-25 at 07:30 -0700, Sean Christopherson wrote: >>> On Thu, Apr 25, 2024, Xiaoyao Li wrote: >>>> On 4/24/2024 12:53 AM, Sean Christopherson wrote: >>>>> Fix a goof where KVM fails to re-initialize the set of supported VM types, >>>>> resulting in KVM overreporting the set of supported types when a vendor >>>>> module is reloaded with incompatible settings. E.g. unload kvm-intel.ko, >>>>> reload with ept=0, and KVM will incorrectly treat SW_PROTECTED_VM as >>>>> supported. >>>> >>>> Hah, this reminds me of the bug of msrs_to_save[] and etc. >>>> >>>> 7a5ee6edb42e ("KVM: X86: Fix initialization of MSR lists") >>> >>> Yeah, and we had the same bug with allow_smaller_maxphyaddr >>> >>> 88213da23514 ("kvm: x86: disable the narrow guest module parameter on unload") >>> >>> If the side effects of linking kvm.ko into kvm-{amd,intel}.ko weren't so painful >>> for userspace, >>> >> >> Do we have any real side effects for _userspace_ here? > > kvm.ko ceasing to exist, and "everything" being tied to the vendor module is the > big problem. E.g. params from the kernel command line for kvm.??? will become > ineffective, etc. Some of that can be handled in the kernel, e.g. KVM can create > a sysfs symlink so that the accesses through sysfs continue to work, but AFAIK > params don't supporting such aliasing/links. > > I don't think there are any deal breakers, but I don't expect it to Just Work either.
Perhaps we can make the kvm.ko as a dummy module which only keeps the module parameters for backward compatibility?
| |