Re: Interest in contributing to KVM TODO

Re: Interest in contributing to KVM TODO

[Aaron Ang]

Hi KVM team,

We are a group of graduate students from the University of California,
San Diego, interested in contributing to KVM as part of our class
project. We have identified a task from the TODO that we would like to
tackle: Improve mmu page eviction algorithm (currently FIFO, change to
approximate LRU). May I know if there are any updates on this task,
and is there room for us to develop in this space? We also plan to
introduce other algorithms and compare their performance across
various workloads. We would be happy to talk to the engineers owning
the MMU code to see how we can coordinate our efforts. Thank you.

Regards,
Aaron


On Wed, Jan 22, 2025 at 3:19 PM Aaron Ang <a1ang@ucsd.edu> wrote:
>
> Hi KVM team,
>
> We are a group of graduate students from the University of California, San Diego, interested in contributing to KVM as part of our class project. We have identified a task from the TODO that we would like to tackle: Improve mmu page eviction algorithm (currently FIFO, change to approximate LRU). May I know if there are any updates on this task, and is there room for us to develop in this space? We also plan to introduce other algorithms and compare their performance across various workloads. We would be happy to talk to the engineers owning the MMU code to see how we can coordinate our efforts. Thank you.
>
> Regards,
> Aaron

Re: Interest in contributing to KVM TODO

[Sean Christopherson]

On Wed, Jan 22, 2025, Aaron Ang wrote:
> Hi KVM team,
> 
> We are a group of graduate students from the University of California,
> San Diego, interested in contributing to KVM as part of our class
> project. We have identified a task from the TODO that we would like to

Oof, https://www.linux-kvm.org/page/TODO is a "bit" stale.

> tackle: Improve mmu page eviction algorithm (currently FIFO, change to
> approximate LRU). May I know if there are any updates on this task,
> and is there room for us to develop in this space?

AFAIK, no one is working on this particular task, but honestly I wouldn't bother.
There are use cases that still rely on shadow paging[1], but those tend to be
highly specialized and either ensure there are always "enough" MMU pages available,
or in the case of PVM, I suspect there are _significant_ out-of-tree changes to
optimize shadow paging as a whole.

With the TDP MMU, KVM completely ignores the MMU page limit (both KVM's default
and the limit set by KVM_SET_NR_MMU_PAGES.  With TDP, i.e. without shadow paging,
the number of possible MMU pages is a direct function of the amount of memory
exposed to the guest, i.e. there is no danger of KVM accumulating too many page
tables due shadowing a large number of guest CR3s.

With nested TDP, KVM does employ shadow paging, but the behavior of an L1 hypervisor
using TDP is wildly different than an L1 kernel managing "legacy" page tables for
itself and userspace.  If an L1 hypervisor manages to run up against KVM's limit
on the number of MMU pages, then in all likelihood it deserves to die :-)

What areas are y'all looking to explore?  E.g. KVM/virtualization in general,
memory management in particular, something else entirely?  And what timeline are
you operating on, i.e. how big of a problem/project are you looking to tackle?

[1] https://lore.kernel.org/all/20240226143630.33643-1-jiangshanlai@gmail.com

> We also plan to introduce other algorithms and compare their performance
> across various workloads. We would be happy to talk to the engineers owning
> the MMU code to see how we can coordinate our efforts. Thank you.

Re: Interest in contributing to KVM TODO

[Aaron Ang]

Hi Sean,

Thank you for getting back to us. We are looking at a timeline of
about 3-4 weeks. We are interested in KVM/virtualization in general
and memory management. Ideally, we would work on a fairly scoped task
given our limited experience and timeline. We initially planned to
change the implementation details in `x86/kvm/mmu/mmu.c` to use
approximate LRU, then run some performance benchmarks to compare with
the current FIFO implementation. However, we understand from your
reply that KVM has defaulted to TDP MMU.

Are there any backlog tasks that fit our timeline? We are open to
anything (comparison benchmarks, bug fixes, small features, etc.). Our
solution will probably not be foolproof, but we hope to produce
something actionable for future KVM efforts. Happy to discuss further.

Regards,
Aaron
---------------------------------------------------------------------
From: Sean Christopherson <seanjc@google.com>
Date: Thursday, 20 February 2025 at 11:06 AM
To: Aaron Ang <a1ang@ucsd.edu>
Cc: kvm@vger.kernel.org <kvm@vger.kernel.org>, jukaufman@ucsd.edu
<jukaufman@ucsd.edu>, eth003@ucsd.edu <eth003@ucsd.edu>, Alex Asch
<aasch@ucsd.edu>
Subject: Re: Interest in contributing to KVM TODO

On Wed, Jan 22, 2025, Aaron Ang wrote:
> Hi KVM team,
>
> We are a group of graduate students from the University of California,
> San Diego, interested in contributing to KVM as part of our class
> project. We have identified a task from the TODO that we would like to

Oof, https://urldefense.com/v3/__https://www.linux-kvm.org/page/TODO__;!!Mih3wA!GHlu-1K3bzLd-0OuL5LV30AtMELMkt6xiZXu7wenC6b28xauSSG0z0BVnF-9bLDpYHD97a1YrLov9w$
 is a "bit" stale.

> tackle: Improve mmu page eviction algorithm (currently FIFO, change to
> approximate LRU). May I know if there are any updates on this task,
> and is there room for us to develop in this space?

AFAIK, no one is working on this particular task, but honestly I
wouldn't bother.
There are use cases that still rely on shadow paging[1], but those tend to be
highly specialized and either ensure there are always "enough" MMU
pages available,
or in the case of PVM, I suspect there are _significant_ out-of-tree changes to
optimize shadow paging as a whole.

With the TDP MMU, KVM completely ignores the MMU page limit (both KVM's default
and the limit set by KVM_SET_NR_MMU_PAGES.  With TDP, i.e. without
shadow paging,
the number of possible MMU pages is a direct function of the amount of memory
exposed to the guest, i.e. there is no danger of KVM accumulating too many page
tables due shadowing a large number of guest CR3s.

With nested TDP, KVM does employ shadow paging, but the behavior of an
L1 hypervisor
using TDP is wildly different than an L1 kernel managing "legacy" page
tables for
itself and userspace.  If an L1 hypervisor manages to run up against KVM's limit
on the number of MMU pages, then in all likelihood it deserves to die :-)

What areas are y'all looking to explore?  E.g. KVM/virtualization in general,
memory management in particular, something else entirely?  And what timeline are
you operating on, i.e. how big of a problem/project are you looking to tackle?

[1] https://urldefense.com/v3/__https://lore.kernel.org/all/20240226143630.33643-1-jiangshanlai@gmail.com__;!!Mih3wA!GHlu-1K3bzLd-0OuL5LV30AtMELMkt6xiZXu7wenC6b28xauSSG0z0BVnF-9bLDpYHD97a1KsoVHiQ$

> We also plan to introduce other algorithms and compare their performance
> across various workloads. We would be happy to talk to the engineers owning
> the MMU code to see how we can coordinate our efforts. Thank you.