On Fri, Jul 22 2022 at 23:41, Sean Christopherson wrote:
> +x86 maintainers, patch 1 most definitely needs acceptance from folks
> beyond KVM.
Thanks for putting us on CC. It seems to be incredibly hard to CC the
relevant maintainers and to get the prefix in the subject straight.
> 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.
What's even worse is that this exposes a magic kernel syscall interface
to random driver writers. Seriously no.
This approach is certainly a clever idea, but exposing this outside of a
very restricted and controlled environment is a patently bad idea.
I skimmed the documentation on the project page:
sudo modprobe kvm-intel && sudo chmod a+rw /dev/kvm
Can you spot the fail?
I gave up reading further as shortly after that gem the page failed to
render sensibly in Firefox. Hint: Graphics
What's completely missing from the cover letter _and_ from the project
documentation is which subset of KVM functionality this is actually
using and how the actual content of the "guest" looks like. It's all
blury handwaving and lots of marketing to me.
Thanks,
tglx
