From: "Michael S. Tsirkin" <mst@redhat.com>
To: Ruben Hakobyan <hruben@meta.com>
Cc: "David Hildenbrand" <david@kernel.org>,
"Breno Leitao" <leitao@debian.org>,
"Atish Patra" <atishp@meta.com>,
"Jason Wang" <jasowangio@gmail.com>,
"Eugenio Pérez" <eperezma@redhat.com>,
"Xuan Zhuo" <xuanzhuo@linux.alibaba.com>,
"Alexander Duyck" <alexander.h.duyck@linux.intel.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
virtualization@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] virtio_balloon: batch large descriptor chains for page reporting
Date: Mon, 26 Oct 2026 11:10:53 -0400 [thread overview]
Message-ID: <20261026111005-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20261023081923.164950-1-hruben@meta.com>
On Fri, Oct 23, 2026 at 01:19:19AM -0700, Ruben Hakobyan wrote:
> The virtio_balloon driver reports a scatter-gather list of free pages
> to the VMM so it may discard unused pages.
>
> For an arm64 kernel with 64 KiB pages, the default reporting and
> allocation orders allow entries ranging from 2 MiB to 512 MiB. If the
> report contains a sufficient number of large entries, we will end up
> with a descriptor chain that represents over 4 GiB of memory. This
> violates virtio spec section 2.7.5.2, which requires that the total
> buffer length of a descriptor chain be at most 4 GiB [1]. A VMM that
> faithfully follows the spec may stop processing the descriptor chain
> when it exceeds 4 GiB, and discard less memory than it could. For
> example, this is the case for the virtio-queue in Rust-VMM [2].
>
> Batch the requests into descriptor chains of at most U32_MAX bytes
> (4 GiB - 1 byte). We use U32_MAX here so we can conveniently represent
> the batch length in a u32.
>
> [1] https://docs.oasis-open.org/virtio/virtio/v1.4/virtio-v1.4.html
> [2]
> https://github.com/rust-vmm/rust-vmm/blob/9f7250b1555ebe022ea4133fda676e6311040738/vm-virtio/virtio-queue/src/chain.rs#L183-L190
>
> Fixes: b0c504f15471 ("virtio-balloon: add support for providing free page reports to host")
> Signed-off-by: Ruben Hakobyan <hruben@meta.com>
> ---
thanks a lot for the report. I posted a patchset for your
consideration. if you test it, pls let us know the results.
if you see a need for more changes, pls feel free to take
over the work on it.
> The wording in the spec is a bit ambiguous because it uses "chain
> length" for both descriptor counts and the total size of the memory
> ranges referenced by the descriptors. My read is that the byte limit
> applies to the sum of descriptor lengths, which is also what rust-vmm
> checks.
>
> Another option I considered was to limit reporting capacity based
> on the largest possible block. E.g. for 64 KiB pages, the largest
> block is 512 MiB, so limit the reporting capacity to 7 to stay
> below 4GiB. Although simpler, I found that the time to reclaim
> was quite a bit longer.
>
> I tested this patch on Cloud Hypervisor (which uses Rust-VMM)
> and QEMU (which doesn't enforce this limit).
>
> drivers/virtio/virtio_balloon.c | 47 ++++++++++++++++++++++++---------
> 1 file changed, 35 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
> index ab3e3d887e00..68ce627c8e04 100644
> --- a/drivers/virtio/virtio_balloon.c
> +++ b/drivers/virtio/virtio_balloon.c
> @@ -15,6 +15,7 @@
> #include <linux/slab.h>
> #include <linux/module.h>
> #include <linux/balloon.h>
> +#include <linux/limits.h>
> #include <linux/oom.h>
> #include <linux/wait.h>
> #include <linux/mm.h>
> @@ -207,21 +208,43 @@ static int virtballoon_free_page_report(struct page_reporting_dev_info *pr_dev_i
> struct virtqueue *vq = vb->reporting_vq;
> unsigned int unused, err;
>
> - /* We should always be able to add these buffers to an empty queue. */
> - err = virtqueue_add_inbuf(vq, sg, nents, vb, GFP_NOWAIT);
> + while (nents) {
> + bool unmark_end;
> + struct scatterlist *sg_batch_start = sg;
> + u32 batch_len = 0;
> + unsigned int batch_nents = 0;
>
> - /*
> - * In the extremely unlikely case that something has occurred and we
> - * are able to trigger an error we will simply display a warning
> - * and exit without actually processing the pages.
> - */
> - if (WARN_ON_ONCE(err))
> - return err;
> + /*
> + * Virtio spec 2.7.5.2 limits the total buffer length of a
> + * descriptor chain to 2^32 bytes (4 GiB), so split larger
> + * reports into batches no bigger than that size.
> + */
> + while (batch_nents < nents &&
> + sg->length <= U32_MAX - batch_len) {
> + batch_len += sg->length;
> + batch_nents += 1;
> + sg = sg_next(sg);
> + }
> + unmark_end = !sg_is_last(&sg_batch_start[batch_nents - 1]);
>
> - virtqueue_kick(vq);
> + if (unmark_end)
> + sg_mark_end(&sg_batch_start[batch_nents - 1]);
>
> - /* When host has read buffer, this completes via balloon_ack */
> - wait_event(vb->acked, virtqueue_get_buf(vq, &unused));
> + err = virtqueue_add_inbuf(vq, sg_batch_start, batch_nents, vb,
> + GFP_NOWAIT);
> +
> + if (unmark_end)
> + sg_unmark_end(&sg_batch_start[batch_nents - 1]);
> +
> + if (WARN_ON_ONCE(err))
> + return err;
> +
> + virtqueue_kick(vq);
> +
> + /* When host has read buffer, this completes via balloon_ack */
> + wait_event(vb->acked, virtqueue_get_buf(vq, &unused));
> + nents -= batch_nents;
> + }
>
> return 0;
> }
> --
> 2.53.0-Meta
prev parent reply other threads:[~2026-10-26 15:11 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-23 8:19 [PATCH] virtio_balloon: batch large descriptor chains for page reporting Ruben Hakobyan
2026-10-23 8:25 ` sashiko-bot
2026-10-23 10:04 ` Michael S. Tsirkin
2026-10-25 23:56 ` Ruben Hakobyan
2026-10-26 0:19 ` Michael S. Tsirkin
2026-10-26 12:59 ` Ruben Hakobyan
2026-10-26 13:43 ` Michael S. Tsirkin
2026-10-26 12:06 ` Ruben Hakobyan
2026-10-26 15:10 ` Michael S. Tsirkin [this message]
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=20261026111005-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=alexander.h.duyck@linux.intel.com \
--cc=atishp@meta.com \
--cc=david@kernel.org \
--cc=eperezma@redhat.com \
--cc=hruben@meta.com \
--cc=jasowangio@gmail.com \
--cc=leitao@debian.org \
--cc=linux-kernel@vger.kernel.org \
--cc=virtualization@lists.linux.dev \
--cc=xuanzhuo@linux.alibaba.com \
/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.