On 18.06.25 23:58, Peter Xu wrote:
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.
We discussed some of that in one of the revisions, and it's not clear
yet how virtio-mem will interact in confidential VMs with that (we will
have to have both active at the same time). I shared some ideas, but
they are all stuff for the future.
So how the bitmap(s) will look like in the future and how multiple
RamDiscardManagers will interact remains to be seen.
--
Cheers,
David / dhildenb
