From: Gao Xiang <hsiangkao@linux.alibaba.com>
To: David Hildenbrand <david@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [PATCH] hw/arm: add static NVDIMMs in device tree
Date: Wed, 20 Aug 2025 12:10:30 +0800 [thread overview]
Message-ID: <dd4fff02-7c73-412f-bf8c-ee8446cd9b11@linux.alibaba.com> (raw)
In-Reply-To: <db65aa49-7323-49f4-8531-7c617e9d8a1b@linux.alibaba.com>
(try to Cc David and Paolo for some discussion...)
Hi David and Paolo,
If possible, could you share some thoughts about this, because
currently each `memory-backend-file` has their own page cache
on the host, but if QEMU can provide one nvdimm device backed
by multiple files, so that EROFS can share memory in finer
layer granularity on the host. (we don't need to attach so
many devices, because some container images can be dozens of
layers.)
Without further investigatation, I wonder which direction is
better:
1) one memory-backend-file backed by multiple files;
2) nvdimm, virtio-pmem, .. backed by multiple
`memory-backend-file`s..
Currently I don't have extra slot to look into the QEMU codebase,
but if the idea is acceptable, I will try to work on this later.
Thanks,
Gao Xiang
On 2025/8/1 14:58, Gao Xiang wrote:
> Hi folks,
>
> On 2025/7/31 19:14, Shameerali Kolothum Thodi via wrote:
>>
>>
>>> -----Original Message-----
>>> From: Jonathan Cameron <jonathan.cameron@huawei.com>
>>> Sent: Thursday, July 31, 2025 11:01 AM
>>> To: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
>>> Cc: qemu-devel@nongnu.org; Peter Maydell <peter.maydell@linaro.org>;
>>> qemu-arm@nongnu.org; Gustavo Romero <gustavo.romero@linaro.org>;
>>> Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
>>> Subject: Re: [PATCH] hw/arm: add static NVDIMMs in device tree
>>>
>>> On Wed, 30 Jul 2025 15:21:41 +0300
>>> Manos Pitsidianakis <manos.pitsidianakis@linaro.org> wrote:
>>>
>>>> NVDIMM is used for fast rootfs with EROFS, for example by kata
>>>> containers. To allow booting with static NVDIMM memory, add them to
>>>> the device tree in arm virt machine.
>
> Just another question about the image passthrough via pmem,
> I wonder if it's possible for QEMU to support one nvdimm,
> virtio-pmem device with multiple memory backend files rather
> than just one single file?
>
> Because EROFS can use this way to support multi-layer images,
> for example:
>
> filesystem1: metadatafile + layerfile1 + layerfile2
> filesystem2: metadatafile + layerfile1 + layerfile3
>
> so that multiple pmem devices can share the same layer1 page
> cache on the host.
>
> More details also see:
> https://erofs.docs.kernel.org/en/latest/merging.html
>
>
> Many thanks!
> Gao Xiang
next prev parent reply other threads:[~2025-08-20 4:12 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-30 12:21 [PATCH] hw/arm: add static NVDIMMs in device tree Manos Pitsidianakis
2025-07-31 8:38 ` Philippe Mathieu-Daudé
2025-07-31 9:42 ` Manos Pitsidianakis
2025-07-31 10:00 ` Jonathan Cameron via
2025-07-31 10:00 ` Jonathan Cameron via
2025-07-31 11:14 ` Shameerali Kolothum Thodi via
2025-07-31 11:14 ` Shameerali Kolothum Thodi via
2025-07-31 12:20 ` Manos Pitsidianakis
2025-08-01 11:03 ` Igor Mammedov
2025-08-01 11:35 ` Peter Maydell
2025-08-01 6:58 ` Gao Xiang
2025-08-20 4:10 ` Gao Xiang [this message]
2025-08-20 9:29 ` David Hildenbrand
2025-08-20 10:11 ` Gao Xiang
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=dd4fff02-7c73-412f-bf8c-ee8446cd9b11@linux.alibaba.com \
--to=hsiangkao@linux.alibaba.com \
--cc=david@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.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.