+x86 maintainers, patch 1 most definitely needs acceptance from folks beyond KVM. On Fri, Jul 22, 2022, Andrei Vagin wrote: > Another option is the KVM platform. In this case, the Sentry (gVisor > kernel) can run in a guest ring0 and create/manage multiple address > spaces. Its performance is much better than the ptrace one, but it is > still not great compared with the native performance. This change > optimizes the most critical part, which is the syscall overhead. What exactly is the source of the syscall overhead, and what alternatives have been explored? Making arbitrary syscalls from within KVM is mildly terrifying. > The idea of using vmcall to execute system calls isn’t new. Two large users > of gVisor (Google and AntFinacial) have out-of-tree code to implement such > hypercalls. > > In the Google kernel, we have a kvm-like subsystem designed especially > for gVisor. This change is the first step of integrating it into the KVM > code base and making it available to all Linux users. Can you please lay out the complete set of changes that you will be proposing? Doesn't have to be gory details, but at a minimum there needs to be a high level description that very clearly defines the scope of what changes you want to make and what the end result will look like. It's practically impossible to review this series without first understanding the bigger picture, e.g. if KVM_HC_HOST_SYSCALL is ultimately useless without the other bits you plan to upstream, then merging it without a high level of confidence that the other bits are acceptable is a bad idea since it commits KVM to supporting unused ABI.
