kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Anastassios Nanos <ananos@nubificus.co.uk>
Cc: kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu,
	linux-kernel@vger.kernel.org, James Morse <james.morse@arm.com>,
	Julien Thierry <julien.thierry.kdev@gmail.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Sean Christopherson <sean.j.christopherson@intel.com>,
	Vitaly Kuznetsov <vkuznets@redhat.com>,
	Wanpeng Li <wanpengli@tencent.com>,
	Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH 0/2] Expose KVM API to Linux Kernel
Date: Mon, 18 May 2020 08:50:42 +0100	[thread overview]
Message-ID: <c1124c27293769f8e4836fb8fdbd5adf@kernel.org> (raw)
In-Reply-To: <cover.1589784221.git.ananos@nubificus.co.uk>

On 2020-05-18 07:58, Anastassios Nanos wrote:
> To spawn KVM-enabled Virtual Machines on Linux systems, one has to use
> QEMU, or some other kind of VM monitor in user-space to host the vCPU
> threads, I/O threads and various other book-keeping/management 
> mechanisms.
> This is perfectly fine for a large number of reasons and use cases: for
> instance, running generic VMs, running general purpose Operating 
> systems
> that need some kind of emulation for legacy boot/hardware etc.
> 
> What if we wanted to execute a small piece of code as a guest instance,
> without the involvement of user-space? The KVM functions are already 
> doing
> what they should: VM and vCPU setup is already part of the kernel, the 
> only
> missing piece is memory handling.
> 
> With these series, (a) we expose to the Linux Kernel the bare minimum 
> KVM
> API functions in order to spawn a guest instance without the 
> intervention
> of user-space; and (b) we tweak the memory handling code of KVM-related
> functions to account for another kind of guest, spawned in 
> kernel-space.
> 
> PATCH #1 exposes the needed stub functions, whereas PATCH #2 introduces 
> the
> changes in the KVM memory handling code for x86_64 and aarch64.
> 
> An example of use is provided based on kvmtest.c
> [https://lwn.net/Articles/658512/] at
> https://github.com/cloudkernels/kvmmtest

You don't explain *why* we would want this. What is the overhead of 
having
a userspace if your guest doesn't need any userspace handling? The 
kvmtest
example indeed shows that the KVM userspace API is usable  without any 
form
of emulation, hence has almost no cost.

Without a clear description of the advantages of your solution, as well
as a full featured in-tree use case, I find it pretty hard to support 
this.

Thanks,

         M.
-- 
Jazz is not dead. It just smells funny...

  parent reply	other threads:[~2020-05-18  7:50 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-18  6:58 [PATCH 0/2] Expose KVM API to Linux Kernel Anastassios Nanos
2020-05-18  6:58 ` [PATCH 1/2] KVMM: export needed symbols Anastassios Nanos
2020-05-18  7:41   ` Marc Zyngier
2020-05-18  7:01 ` [PATCH 2/2] KVMM: Memory and interface related changes Anastassios Nanos
2020-05-18  6:59   ` Anastassios Nanos
2020-05-18  9:13   ` kbuild test robot
2020-05-18  9:28   ` kbuild test robot
2020-05-18 10:16   ` kbuild test robot
2020-05-18  7:50 ` Marc Zyngier [this message]
     [not found]   ` <CALRTab90UyMq2hMxCdCmC3GwPWFn2tK_uKMYQP2YBRcHwzkEUQ@mail.gmail.com>
2020-05-18 11:18     ` [PATCH 0/2] Expose KVM API to Linux Kernel Paolo Bonzini
2020-05-18 11:34       ` Maxim Levitsky
2020-05-18 11:51         ` Paolo Bonzini
2020-05-18 12:12           ` Maxim Levitsky
2020-05-18 20:45     ` Andy Lutomirski
2020-05-18  8:42 ` Thomas Gleixner
     [not found]   ` <CALRTab-mEYtRG4zQbSGoAri+jg8xNL-imODv=MWE330Hkt_t+Q@mail.gmail.com>
2020-05-18  9:18     ` Vitaly Kuznetsov
2020-05-18  9:38     ` Thomas Gleixner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c1124c27293769f8e4836fb8fdbd5adf@kernel.org \
    --to=maz@kernel.org \
    --cc=ananos@nubificus.co.uk \
    --cc=bp@alien8.de \
    --cc=catalin.marinas@arm.com \
    --cc=hpa@zytor.com \
    --cc=james.morse@arm.com \
    --cc=jmattson@google.com \
    --cc=joro@8bytes.org \
    --cc=julien.thierry.kdev@gmail.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=sean.j.christopherson@intel.com \
    --cc=suzuki.poulose@arm.com \
    --cc=tglx@linutronix.de \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.com \
    --cc=will@kernel.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).