Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 22 Jul 2022 23:41:41 +0000
From:   Sean Christopherson <seanjc@google.com>
To:     Andrei Vagin <avagin@google.com>
Cc:     Paolo Bonzini <pbonzini@redhat.com>, linux-kernel@vger.kernel.org,
        kvm@vger.kernel.org, Wanpeng Li <wanpengli@tencent.com>,
        Vitaly Kuznetsov <vkuznets@redhat.com>,
        Jianfeng Tan <henry.tjf@antfin.com>,
        Adin Scannell <ascannell@google.com>,
        Konstantin Bogomolov <bogomolov@google.com>,
        Etienne Perot <eperot@google.com>,
        Andy Lutomirski <luto@kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org,
        "H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH 0/5] KVM/x86: add a new hypercall to execute host system
Message-ID: <Yts1tUfPxdPH5XGs@google.com>
References: <20220722230241.1944655-1-avagin@google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20220722230241.1944655-1-avagin@google.com>
Precedence: bulk

+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.