On Tue, 2020-12-15 at 13:07 +0100, Vitaly Kuznetsov wrote: > Yes, sadly. Multiple address spaces support was added to KVM as a > generic feature but the only use-case for it at this moment is SMM on > x86 which is 'special', i.e. currently there's only one user for > kvm_map_gfn()/kvm_unmap_gfn() which is steal time accounting and it's > not easy to come up with a use-case when this PV feature needs to be > used from SMM. On the other hand, if we try using multiple address > spaces in KVM for e.g. emulating something like Hyper-V VSM, it becomes > unclear which address space id needs to be used even for steal > time. To be entirely correct, we probably need to remember as_id which > was active when steal time was enabled and stick to it later when we > want to update the data. If we do that, kvm_map_gfn() will lose its only > user. I'm also OK with just completely deleting kvm_map_gfn(). I'm not even using it any more myself; I just kept this patch in my v3 series because it's a sane cleanup. The steal time accounting doesn't *need* to have a kernel mapping of the page just so it can do atomic xchg on it; we can do that just fine on userspace addresses, and do exactly that for futexes. So I'm probably going to knock up a kvm_cmpxchg_guest_offset_cached() and make the steal time code use that, on the *userspace* address. There's already a futex_atomic_cmpxchg_inatomic() which does the actual operation. (It returns -EFAULT for an absent page and lets the caller worry about faulting it in, which isn't quite what I want, but it's a good start and I can either wrap the existing arch-provided function like futexes do, or use it as a basis for a version that waits.) And by an amazing coincidence that's also the function I need for accelerating Xen event channel support... :)
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
