On Tuesday 05 Apr 2022 at 18:03:21 (+0000), Sean Christopherson wrote: > On Tue, Apr 05, 2022, Quentin Perret wrote: > > On Monday 04 Apr 2022 at 15:04:17 (-0700), Andy Lutomirski wrote: > > > >> - it can be very useful for protected VMs to do shared=>private > > > >> conversions. Think of a VM receiving some data from the host in a > > > >> shared buffer, and then it wants to operate on that buffer without > > > >> risking to leak confidential informations in a transient state. In > > > >> that case the most logical thing to do is to convert the buffer back > > > >> to private, do whatever needs to be done on that buffer (decrypting a > > > >> frame, ...), and then share it back with the host to consume it; > > > > > > > > If performance is a motivation, why would the guest want to do two > > > > conversions instead of just doing internal memcpy() to/from a private > > > > page? I would be quite surprised if multiple exits and TLB shootdowns is > > > > actually faster, especially at any kind of scale where zapping stage-2 > > > > PTEs will cause lock contention and IPIs. > > > > > > I don't know the numbers or all the details, but this is arm64, which is a > > > rather better architecture than x86 in this regard. So maybe it's not so > > > bad, at least in very simple cases, ignoring all implementation details. > > > (But see below.) Also the systems in question tend to have fewer CPUs than > > > some of the massive x86 systems out there. > > > > Yep. I can try and do some measurements if that's really necessary, but > > I'm really convinced the cost of the TLBI for the shared->private > > conversion is going to be significantly smaller than the cost of memcpy > > the buffer twice in the guest for us. > > It's not just the TLB shootdown, the VM-Exits aren't free. Ack, but we can at least work on the rest (number of exits, locking, ...). The cost of the memcpy and the TLBI are really incompressible. > And barring non-trivial > improvements to KVM's MMU, e.g. sharding of mmu_lock, modifying the page tables will > block all other updates and MMU operations. Taking mmu_lock for read, should arm64 > ever convert to a rwlock, is not an option because KVM needs to block other > conversions to avoid races. FWIW the host mmu_lock isn't all that useful for pKVM. The host doesn't have _any_ control over guest page-tables, and the hypervisor can't safely rely on the host for locking, so we have hypervisor-level synchronization. > Hmm, though batching multiple pages into a single request would mitigate most of > the overhead. Yep, there are a few tricks we can play to make this fairly efficient in the most common cases. And fine-grain locking at EL2 is really high up on the todo list :-) Thanks, Quentin
