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;
MIME-Version: 1.0
References: <20220722230241.1944655-1-avagin@google.com> <Yts1tUfPxdPH5XGs@google.com>
 <CAEWA0a4hrRb5HYLqa1Q47=guY6TLsWSJ_zxNjOXXV2jCjUekUA@mail.gmail.com> <69b45487-ce0e-d643-6c48-03c5943ce2e6@redhat.com>
In-Reply-To: <69b45487-ce0e-d643-6c48-03c5943ce2e6@redhat.com>
From:   Andrei Vagin <avagin@google.com>
Date:   Tue, 26 Jul 2022 23:44:23 -0700
Message-ID: <CAEWA0a4G2VzDA0C5ujXQpeyxT98Sg1tmeaLBX7VX3g16WrwjjQ@mail.gmail.com>
Subject: Re: [PATCH 0/5] KVM/x86: add a new hypercall to execute host system
To:     Paolo Bonzini <pbonzini@redhat.com>
Cc:     Sean Christopherson <seanjc@google.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>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Tue, Jul 26, 2022 at 3:27 AM Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> On 7/26/22 10:33, Andrei Vagin wrote:
...
> > == Execute system calls from a user-space VMM ==
> >
> > In this case, the Sentry is always running in VM, and a syscall handler in GR0
> > triggers vmexit to transfer control to VMM (user process that is running in
> > hr3), VMM executes a required system call, and transfers control back to the
> > Sentry. We can say that it implements the suggested hypercall in the
> > user-space.
> >
> > The sentry syscall time is 2100ns in this case.
> >
> > The new hypercall does the same but without switching to the host ring 3. It
> > reduces the sentry syscall time to 1000ns.
>
> Yeah, ~3000 clock cycles is what I would expect.
>
> What does it translate to in terms of benchmarks?  For example a simple
> netperf/UDP_RR benchmark.

* netperf in gVisor with the syscall fast path:
$  ./runsc --platform kvm --network host --rootless do netperf -H ::1
-p 12865 -t UDP_RR
MIGRATED UDP REQUEST/RESPONSE TEST from ::0 (::) port 0 AF_INET6 to
::1 (::1) port 0 AF_INET6 : interval : first burst 0
Local /Remote
Socket Size   Request  Resp.   Elapsed  Trans.
Send   Recv   Size     Size    Time     Rate
bytes  Bytes  bytes    bytes   secs.    per sec

212992 212992 1        1       10.00    95965.18
212992 212992

* netperf in gVisor without syscall fast path:
$  ./runsc.orig --platform kvm --network host --rootless do netperf -H
::1 -p 12865 -t UDP_RR
MIGRATED UDP REQUEST/RESPONSE TEST from ::0 (::) port 0 AF_INET6 to
::1 (::1) port 0 AF_INET6 : interval : first burst 0
Local /Remote
Socket Size   Request  Resp.   Elapsed  Trans.
Send   Recv   Size     Size    Time     Rate
bytes  Bytes  bytes    bytes   secs.    per sec

212992 212992 1        1       10.00    58709.17
212992 212992

* netperf executed on the host without gVisor
$ netperf -H ::1 -p 12865 -t UDP_RR
MIGRATED UDP REQUEST/RESPONSE TEST from ::0 (::) port 0 AF_INET6 to
::1 (::1) port 0 AF_INET6 : interval : first burst 0
Local /Remote
Socket Size   Request  Resp.   Elapsed  Trans.
Send   Recv   Size     Size    Time     Rate
bytes  Bytes  bytes    bytes   secs.    per sec

212992 212992 1        1       10.00    146460.80
212992 212992

Thanks,
Andrei