On Thu, Dec 15, 2022 at 09:33:17AM +0000, Ryan Roberts wrote: > On 15/12/2022 00:52, Oliver Upton wrote: > > On Tue, Dec 06, 2022 at 01:59:18PM +0000, Ryan Roberts wrote: > >> (appologies, I'm resending this series as I managed to send the cover > >> letter to > >> all but the following patches only to myself on first attempt). > >> > >> This is my first upstream feature submission so please go easy ;-) > > > > Welcome :) > > > >> Support 52-bit Output Addresses: FEAT_LPA2 changes the format of the PTEs. > >> The > >> HW advertises support for LPA2 independently for stage 1 and stage 2, and > >> therefore its possible to have it for one and not the other. I've assumed > >> that > >> there is a valid case for this if stage 1 is not supported but stage 2 is, > >> KVM > >> could still then use LPA2 at stage 2 to create a 52 bit IPA space (which > >> could > >> then be consumed by a 64KB page guest kernel with the help of FEAT_LPA). > >> Because > >> of this independence and the fact that the kvm pgtable library is used for > >> both > >> stage 1 and stage 2 tables, this means the library now has to remember the > >> in-use format on a per-page-table basis. To do this, I had to rework some > >> functions to take a `struct kvm_pgtable *` parameter, and as a result, > >> there is > >> a noisy patch to add this parameter. > > > > Mismatch between the translation stages is an interesting problem... > > > > Given that userspace is responsible for setting up the IPA space, I > > can't really think of a strong use case for 52 bit IPAs with a 48 bit > > VA. Sure, the VMM could construct a sparse IPA space or remap the same > > HVA at multiple IPAs to artificially saturate the address space, but > > neither seems terribly compelling. > > > > Nonetheless, AFAICT we already allow this sort of mismatch on LPA && > > !LVA systems. A 48 bit userspace could construct a 52 bit IPA space for > > its guest. > > I guess a simpler approach would be to only use LPA2 if its supported by both > stage1 and stage2. Then the code could just use a static key in the few > required > places.
Ah, you caught on quick to what I was thinking :-) What I'm groaning about in particular is the changes to the TLB invalidation path, as it feels like a static key is warranted there. Nonetheless, it is all a bit of a mess depending on LPA2 support in both the kernel and KVM. -- Thanks, Oliver _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
