All of lore.kernel.org
 help / color / mirror / Atom feed
From: bugzilla-daemon@kernel.org
To: kvm@vger.kernel.org
Subject: [Bug 221269] New: Linux kernel (6.18-6.19) memory leak issue QEMU GPU-Passthrough (RDNA3 ?)
Date: Sun, 22 Mar 2026 20:22:59 +0000	[thread overview]
Message-ID: <bug-221269-28872@https.bugzilla.kernel.org/> (raw)

https://bugzilla.kernel.org/show_bug.cgi?id=221269

            Bug ID: 221269
           Summary: Linux kernel (6.18-6.19) memory leak issue QEMU
                    GPU-Passthrough (RDNA3 ?)
           Product: Virtualization
           Version: unspecified
          Hardware: AMD
                OS: Linux
            Status: NEW
          Severity: high
          Priority: P3
         Component: kvm
          Assignee: virtualization_kvm@kernel-bugs.osdl.org
          Reporter: hitomiyukinori@gmail.com
        Regression: No

System Info
Void 6.14.11_1 x86_64 AuthenticAMD uptodate rrrmFFFFFFFF
Ryzen 5 3600
ASUS DUAL RX 7800 XT

Package(s) Affected
linux6.18-6.18.19_1, linux6.19-6.19.9_1

Hello, I recently discovered a very strange cause of memory leakage, The leak
was detected in cases where the following versions of kernels were used :
6.18.19, 6.19.9. Resources (RAM usage) are not properly released when the same
QEMU virtual machine is turning off. This only happens when gpu-passthrough is
used.

Expected behaviour

When I use gpu-passthrough with kernel 6.14.11_1, before powering on the
virtual machine, overall ~ 950 megabytes of RAM is used (checked via ssh+htop),
I’m allocating 14,400 megabytes (14.4GB) of memory for VM, powering on the VM,
and getting something around ~ 14.9 GB overall is used (my hook script offloads
display manager and daemons).

When I make a cycle, power-on, power-off, repeat, like 5-6 times, i am getting
stable results regarding memory allocation / memory used. ~ 950 megabytes when
the VM is OFF, 14.9 GB when the VM is ON

Actual behaviour

Every "power-on, power-off" cycle, something around ~ 300 megabytes of RAM gets
stuck somewhere and can’t be released. Every "power-on, power-off" cycle i am
getting +~300 mb of RAM added to overall "used" / "allocated" by host system.

Steps to reproduce

That is how it works with kernels 6.18.19, 6.19.9 :

1) VM powered OFF, ~950 mb of overall RAM used, VM powered ON, ~ 14.9 GB of
overall RAM used, repeating the cycle

2) VM powered OFF, ~1.2-1.3 GB of overall ram used now, VM powered ON, ~
15.2-15.3 GB of overall ram used now, repeating the cycle

3) ~1.6-1.7 GB of overall ram used now. VM cannot be powered on, because QEMU
cannot allocate 14,400 megabytes (14.4GB) of memory for VM now. Because 15.3 GB
+ 300 MB > Total ram available

This is how memory leakage occurs, without any new running processes, without
changes inside VM, just powering-on VM, powering-off VM, leakage occurs by
repeating this cycle.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

                 reply	other threads:[~2026-03-22 20:23 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=bug-221269-28872@https.bugzilla.kernel.org/ \
    --to=bugzilla-daemon@kernel.org \
    --cc=kvm@vger.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.