On 2/4/25 18:01, Peter Xu wrote:
On Sat, Feb 01, 2025 at 09:57:23AM +0000, “William Roche wrote:
From: William Roche <william.roche@xxxxxxxxxx>
In case of a large page impacted by a memory error, provide an
information about the impacted large page before the memory
error injection message.
This message would also appear on ras enabled ARM platforms, with
the introduction of an x86 similar error injection message.
In the case of a large page impacted, we now report:
Memory Error on large page from <backend>:<address>+<fd_offset> +<page_size>
The +<fd_offset> information is only provided with a file backend.
Signed-off-by: William Roche <william.roche@xxxxxxxxxx>
This is still pretty kvm / arch relevant patch that needs some reviews.
I wonder do we really need this - we could fetch ramblock mapping
(e.g. hwaddr -> HVA) via HMP "info ramblock", and also dmesg shows process
ID + VA. IIUC we have all below info already as long as we do some math
based on above. Would that work too?
The HMP command "info ramblock" is implemented with the
ram_block_format() function which returns a message buffer built with a
string for each ramblock (protected by the RCU_READ_LOCK_GUARD). Our new
function copies a struct with the necessary information.
Relaying on the buffer format to retrieve the information doesn't seem
reasonable, and more importantly, this buffer doesn't provide all the
needed data, like fd and fd_offset.
I would say that ram_block_format() and qemu_ram_block_info_from_addr()
serve 2 different goals.
(a reimplementation of ram_block_format() with an adapted version of
qemu_ram_block_info_from_addr() taking the extra information needed
could be doable for example, but may not be worth doing for now)
