Hi, Chenyi,
On Thu, Jun 12, 2025 at 04:27:41PM +0800, Chenyi Qiang wrote:
> Relationship with in-place conversion
> -------------------------------------
> In-place page conversion is the ongoing work to allow mmap() of
> guest_memfd to userspace so that both private and shared memory can use
> the same physical memory as the backend. This new design eliminates the
> need to discard pages during shared/private conversions. When it is
> ready, shared device assignment needs be adjusted to achieve an
> unmap-before-conversion-to-private and map-after-conversion-to-shared
> sequence to be compatible with the change.
Is it intentional to be prepared for this?
The question more or less come from the read of patch 5, where I see a
bunch of very similar code versus virtio-mem, like:
ram_block_attributes_for_each_populated_section
ram_block_attributes_for_each_discarded_section
ram_block_attributes_rdm_register_listener
ram_block_attributes_rdm_unregister_listener
Fundamentally, IIUC it's because of the similar structure of bitmap used,
and the listeners. IOW, I wonder if it's possible to move the shared
elements into RamDisgardManager for:
unsigned bitmap_size;
unsigned long *bitmap;
QLIST_HEAD(, RamDiscardListener) rdl_list;
But if we know it'll be a tri-state some day, maybe that means it won't
apply anymore. However the rdl_list is still applicable to be merged if we
want, it's just that it'll be a smaller portion to be shared.
Other than that, even if I don't know how to test this.. I read the patches
today and they look all good. The duplication is a pure question I have
above, but even if so it can also be done on top.
I do plan to pick this up. Paolo/David, any comments before I do?
Thanks,
--
Peter Xu
