On 19.09.24 18:52, William Roche wrote:
Hello David,
Hi William,
sorry for not replying earlier, it somehow fell through the cracks as my
inbox got flooded :(
I hope my last week email answered your interrogations about:
- retrieving the valid data from the lost hugepage
- the need of smaller pages to replace a failed large page
- the interaction of memory error and VM migration
- the non-symmetrical access to a poisoned memory area after a recovery
Qemu would be able to continue to access the still valid data
location of the formerly poisoned hugepage, but any other entity
mapping the large page would not be allowed to use the location.
I understand that this last item _is_ some kind of "inconsistency".
That's my biggest concern. Physical memory and its properties are
described by the QEMU RAMBlock, which includes page size,
shared/private, and sometimes properties (e.g., uffd).
Adding inconsistent there is really suboptimal :(
So if I want to make sure that a "shared" memory region (used for vhost-user
processes, vfio or ivshmem) is not recovered, how can I identify what
region(s)
of a guest memory could be used for such a shared location ?
Is there a way for qemu to identify the memory locations that have been
shared ?
I'll reply to your other cleanups/improvements, but we can detect if we
must not discard arbitrary memory (because likely something is relying
on long-term pinnings) using ram_block_discard_is_disabled().
--
Cheers,
David / dhildenb
