SRU request submitted to the Ubuntu kernel team mailing list for jammy, impish
and focal:
https://lists.ubuntu.com/archives/kernel-team/2022-May/thread.html#130450
Changing status to 'In Progress' for jammy, impish and focal.
** Changed in: linux (Ubuntu Impish)
Status: New => In Progress
** Changed in: linux (Ubuntu Focal)
Status: New => In Progress
** Changed in: linux (Ubuntu Focal)
Assignee: (unassigned) => Canonical Kernel Team (canonical-kernel-team)
** Changed in: linux (Ubuntu Impish)
Assignee: (unassigned) => Canonical Kernel Team (canonical-kernel-team)
** Changed in: linux (Ubuntu Jammy)
Assignee: Frank Heimes (fheimes) => Canonical Kernel Team
(canonical-kernel-team)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1974017
Title:
[UBUNTU 20.04] KVM nesting support leaks too much memory, might result
in stalls during cleanup
Status in Ubuntu on IBM z Systems:
In Progress
Status in linux package in Ubuntu:
New
Status in linux source package in Focal:
In Progress
Status in linux source package in Impish:
In Progress
Status in linux source package in Jammy:
In Progress
Bug description:
SRU Justification:
==================
[Impact]
* If running KVM with nesting support (e.g. 'kvm.nested=1' on the kernel
command line), the shadow page table code will produce too many entries
in the shadow code.
* The below mentioned upstream fix will prevent the entries from being
piled up, by checking for existing entries at insert time.
* This measurably reduces the list length and is faster than traversing
the list at shutdown time only.
[Fix]
* a06afe8383080c630a7a528b8382fc6bb4925b61 a06afe838308
"KVM: s390: vsie/gmap: reduce gmap_rmap overhead"
[Test Plan]
* A IBM zSystems or LinuxONE LPAR on a z13 or newer is needed.
* Ubuntu focal, impish or jammy needs to be installed
and the Ubuntu LPAR setup as (1st level) KVM host,
allowing nested virtualization.
* Now setup one (or more) KVM virtual machines,
with similar Ubuntu releases,
and define one or more of them again as (2nd level) KVM host.
* Define several KVM virtual machines on this (2nd level) KVM host
in a memory constraint fashion,
so that a lot of memory mapping is caused.
* Let such a system run for a while under load.
* Now shutdown one (or more) 2nd level VMs and notice the
time it takes.
* With the patch in place this time should be considerably
quicker than without.
* The result is reduced mapping (gmap_rmap) overhead,
less danger of leaking memory
and a better responding system.
[Where problems could occur]
* In case wrong entries are freed up this will harm the virtual
memory management and may even lead to crashes.
* In case the pointer handling is not done properly,
again crashes may occur.
* But with net just five new lines the patch is pretty short, readable
and the modifications traceable in arch/s390/mm/gmap.c only.
* The changes are limited to s390/mm only,
hence don't affect other architectures.
[Other Info]
* The commit was upstream accepted in v5.18-rc6.
* Since the planned target kernel for kinetic is 5.19,
the kinetic kernel does not need to be patched.
* Hence the SRUs are for jammy, impish and focal.
__________
KVM nesting support consumes too much memory
When running KVM with nesting support (kvm.nested=1 on the kernel
command line) the shadow page table code will produce too many entries
in the shadow code.
There is an upstream fix that will prevent the majority of the
problem:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a06afe8383080c630a7a528b8382fc6bb4925b61
The fix is needed for 20.04 and 22.04.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1974017/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : [email protected]
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
