Messages in this thread | | | Date | Wed, 28 Sep 2022 12:04:42 +0200 | From | Paolo Bonzini <> | Subject | Re: [PATCH] KVM: x86: disable on 32-bit unless CONFIG_BROKEN |
| |
On 9/27/22 19:07, Sean Christopherson wrote: > On Mon, Sep 26, 2022, Paolo Bonzini wrote: >> 32-bit KVM has extra complications in the code due to: >> >> - different ways to write 64-bit values in VMCS >> >> - different handling of DS and ES selectors as well as FS/GS bases >> >> - lack of CR8 and EFER >> >> - lack of XFD >> > > More for the list: > > - SVM is effectively restricted to PAE kernels due to NX requirements
True, but I'm not sure how it complicates the code? Do you mean having to kmap/kunmap, and if so are you thinking of making KVM depend on !HIGHMEM?
>> - impossibility of writing 64-bit PTEs atomically > > It's not impossible, just ugly. KVM could use CMPXCHG8B to do all of the accesses > for the TDP MMU, including the non-atomic reads and writes.
Ok, rephrased:
========== Breakage in 32-bit KVM is somewhat rare, but it did happen and developers themselves found out a few months later. This means that it is very unlikely that it has any users. 32-bit processors with virtualization extensions are a historical curiosity; 32-bit userspace can only deal with small guests due to limited address space.
Hence, it makes sense to restrict x86 KVM to 64-bit hosts and kernels. This removes all the conditional code to deal with the above differences, and it also enables unconditional use of the TDP MMU: making it work on 32-bit systems would require contortions using CMPXCHG8B to write 64-bit PTEs atomically, and they are simply not worth it. ==========
>> The last is the big one, because it prevents from using the TDP MMU >> unconditionally. > > As above, if the TDP MMU really is the sticking point, that's solvable.
Yeah, but until now the maintainability cost of keeping 32-bit on life support was small. Using CMPXCHG8B in the TDP MMU is possibly worse than having two MMUs for the two-dimensional paging case, therefore dropping the old x86 direct MMU for me is what tips the balance in favor of removal.
(Once David submits his MMU callbacks work, I still want to see if it's possible to preserve the "old" x86 direct MMU, for example for use in pKVM; however, it would not be in arch/x86/).
Paolo
> The real justification for deprecating 32-bit KVM is that, outside of KVM developers, > literally no one uses 32-bit KVM. I.e. any amount of effort that is required to > continue supporting 32-bit kernels is a complete waste of resources. >
| |