On Tue, Apr 18, 2023, David Woodhouse wrote:
> On Mon, 2023-04-17 at 09:31 -0700, Sean Christopherson wrote:
> > On Mon, Apr 17, 2023, Metin Kaya wrote:
> > > HVMOP_flush_tlbs suboperation of hvm_op hypercall allows a guest to
> > > flush all vCPU TLBs. There is no way for the VMM to flush TLBs from
> > > userspace.
> >
> > Ah, took me a minute to connect the dots.� Monday morning is definitely partly
> > to blame, but it would be helpful to expand this sentence to be more explicit as
> > to why userspace's inability to efficiently flush TLBs.
> >
> > And strictly speaking, userspace _can_ flush TLBs, just not in a precise, efficient
> > way.
>
> Hm, how? We should probably implement that in userspace as a fallback,
> however much it sucks.
Oh, the suckage is high :-) Use KVM_{G,S}ET_SREGS2 to toggle any CR{0,3,4}/EFER
bit and __set_sregs() will reset the MMU context. Note that without this fix[*]
that I'm going to squeeze into 6.4, the MMU context reset may result in all TDP
MMU roots being freed and reallocated.
[*] https://lore.kernel.org/all/20230413231251.1481410-1-seanjc@xxxxxxxxxx
>
> > > �arch/x86/kvm/xen.c���������������� | 31 ++++++++++++++++++++++++++++++
> > > �include/xen/interface/hvm/hvm_op.h |� 3 +++
> >
> > Modifications to uapi headers is conspicuously missing.� I.e. there likely needs
> > to be a capability so that userspace can query support.
>
> Nah, nobody cares. If the kernel "accelerates" this hypercall, so be
> it. Userspace will just never get the KVM_EXIT_XEN for that hypercall
> because it'll be magically handled, like the others.
Ah, that makes sense, I was thinking userspace would complain if it got the
"unexpected" exit.
