mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Babis Chalios <bchalios@amazon.es>
To: Paolo Bonzini <pbonzini@redhat.com>,
	KVM list <kvm@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: Sean Christopherson <seanjc@google.com>,
	Marc Zyngier <maz@kernel.org>, Alexander Graf <graf@amazon.de>,
	"Cali, Marco" <xmarcalx@amazon.co.uk>
Subject: Re: [ANNOUNCE] KVM Microconference at LPC 2023
Date: Wed, 7 Jun 2023 12:13:44 +0200	[thread overview]
Message-ID: <150e1ad0-3d59-762b-6032-897d5630a3bf@amazon.es> (raw)
In-Reply-To: <2f19f26e-20e5-8198-294e-27ea665b706f@redhat.com>



On 9/5/23 11:55, Paolo Bonzini wrote:
> Hi all!
>
> We are planning on submitting a CFP to host a KVM Microconference at
> Linux Plumbers Conference 2023. To help justify the proposal, we would
> like to gather a list of folks that would likely attend, and crowdsource
> a list of topics to include in the proposal.
>
> For both this year and future years, the intent is that a KVM
> Microconference will complement KVM Forum, *NOT* supplant it. As you
> probably noticed, KVM Forum is going through a somewhat radical change in
> how it's organized; the conference is now free and (with some help from
> Red Hat) organized directly by the KVM and QEMU communities. Despite the
> unexpected changes and some teething pains, community response to KVM
> Forum continues to be overwhelmingly positive! KVM Forum will remain
> the venue of choice for KVM/userspace collaboration, for educational
> content covering both KVM and userspace, and to discuss new features in
> QEMU and other userspace projects.
>
> At least on the x86 side, however, the success of KVM Forum led us
> virtualization folks to operate in relative isolation. KVM depends on
> and impacts multiple subsystems (MM, scheduler, perf) in profound ways,
> and recently we’ve seen more and more ideas/features that require
> non-trivial changes outside KVM and buy-in from stakeholders that
> (typically) do not attend KVM Forum. Linux Plumbers Conference is a
> natural place to establish such collaboration within the kernel.
>
> Therefore, the aim of the KVM Microconference will be:
> * to provide a setting in which to discuss KVM and kernel internals
> * to increase collaboration and reduce friction with other subsystems
> * to discuss system virtualization issues that require coordination with
> other subsystems (such as VFIO, or guest support in arch/)
>
> Below is a rough draft of the planned CFP submission.
>
> Thanks!
>
> Paolo Bonzini (KVM Maintainer)
> Sean Christopherson (KVM x86 Co-Maintainer)
> Marc Zyngier (KVM ARM Co-Maintainer)
>
>
> ===================
> KVM Microconference
> ===================
>
> KVM (Kernel-based Virtual Machine) enables the use of hardware features
> to improve the efficiency, performance, and security of virtual machines
> created and managed by userspace.  KVM was originally developed to host
> and accelerate "full" virtual machines running a traditional kernel and
> operating system, but has long since expanded to cover a wide array of 
> use
> cases, e.g. hosting real time workloads, sandboxing untrusted workloads,
> deprivileging third party code, reducing the trusted computed base of
> security sensitive workloads, etc.  As KVM's use cases have grown, so too
> have the requirements placed on KVM and the interactions between it and
> other kernel subsystems.
>
> The KVM Microconference will focus on how to evolve KVM and adjacent
> subsystems in order to satisfy new and upcoming requirements: serving
> guest memory that cannot be accessed by host userspace[1], providing
> accurate, feature-rich PMU/perf virtualization in cloud VMs[2], etc.
>
>
> Potential Topics:
>   - Serving inaccessible/unmappable memory for KVM guests (protected VMs)
>   - Optimizing mmu_notifiers, e.g. reducing TLB flushes and spurious 
> zapping
>   - Supporting multiple KVM modules (for non-disruptive upgrades)
>   - Improving and hardening KVM+perf interactions
>   - Implementing arch-agnostic abstractions in KVM (e.g. MMU)
>   - Defining KVM requirements for hardware vendors
>   - Utilizing "fault" injection to increase test coverage of edge cases
>   - KVM vs VFIO (e.g. memory types, a rather hot topic on the ARM side)
>
>
> Key Attendees:
>   - Paolo Bonzini <pbonzini@redhat.com> (KVM Maintainer)
>   - Sean Christopherson <seanjc@google.com>  (KVM x86 Co-Maintainer)
>   - Your name could be here!
>
> [1] 
> https://lore.kernel.org/all/20221202061347.1070246-1-chao.p.peng@linux.intel.com
> [2] 
> https://lore.kernel.org/all/CALMp9eRBOmwz=mspp0m5Q093K3rMUeAsF3vEL39MGV5Br9wEQQ@mail.gmail.com
>

Hi Paolo,

I think this idea is great!

On our side, we 've been working on providing ways to let VMs (kernel 
and user space)
know that they have been cloned/snapshotted/restored from snapshots[1].

This is tightly coupled with PRNGs both in kernel and user space and 
there needs to be some
collaboration with random.c to tie everything together [2][3]. It sounds 
like it could be a good
fit for this MC (?).

It would be interested to figure out whether such notifications would be 
interested to other
parts of the kernel as well.

Cheers,
Babis

[1] https://www.spinics.net/lists/kernel/msg4808187.html
[2] 
https://www.mail-archive.com/virtio-dev@lists.oasis-open.org/msg09016.html
[3] 
https://lore.kernel.org/lkml/65d872db2e1be29bb03b43ed606e7cc9e74ec08d.camel@infradead.org/T/

  parent reply	other threads:[~2023-06-07 10:14 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-09  9:55 Paolo Bonzini
2023-05-26 15:24 ` Gowans, James
2023-05-26 16:39   ` Sean Christopherson
2023-05-26 17:08     ` Sean Christopherson
2023-05-26 16:09 ` Mickaël Salaün
2023-06-01 21:52   ` Mickaël Salaün
2023-06-02  0:23     ` Sean Christopherson
2023-06-07 10:13 ` Babis Chalios [this message]
2023-06-07 10:37   ` Paolo Bonzini
2023-06-07 12:20     ` Babis Chalios

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=150e1ad0-3d59-762b-6032-897d5630a3bf@amazon.es \
    --to=bchalios@amazon.es \
    --cc=graf@amazon.de \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=seanjc@google.com \
    --cc=xmarcalx@amazon.co.uk \
    /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

all inboxes | Powered by JetHome®