Re: [PATCH v7 3/6] accel/kvm: Report the loss of a large memory page

[William Roche <william.roche@oracle.com>]

On 2/10/25 17:48, Peter Xu wrote:
> On Fri, Feb 07, 2025 at 07:02:22PM +0100, William Roche wrote:
>> [...]
>> So the main reason is a KVM "weakness" with kvm_send_hwpoison_signal(), and
>> the second reason is to have richer error messages.
> 
> This seems true, and I also remember something when I looked at this
> previously but maybe nobody tried to fix it.  ARM seems to be correct on
> that field, otoh.
> 
> Is it possible we fix KVM on x86?

Yes, very probably, and it would be a kernel fix.
This kernel modification would be needed to run on the hypervisor first 
to influence a new code in qemu able to use the SIGBUS siginfo 
information and identify the size of the page impacted (instead of using 
an internal addition to kvm API).
But this mechanism could help to generate a large page memory error 
specific message on SIGBUS receiving.


>>>
>>> I feel like when hwpoison becomes a serious topic, we need some more
>>> serious reporting facility than error reports.  So that we could have this
>>> as separate topic to be revisited.  It might speed up your prior patches
>>> from not being blocked on this.
>>
>> I explained why I think that error messages are important, but I don't want
>> to get blocked on fixing the hugepage memory recovery because of that.
> 
> What is the major benefit of reporting in QEMU's stderr in this case?

Such messages can be collected into VM specific log file, as any other 
error_report() message, like the existing x86 error injection messages 
reported by Qemu.
This messages should help the administrator to better understand the 
behavior of the VM.


> For example, how should we consume the error reports that this patch
> introduces?  Is it still for debugging purpose?

Its not only debugging, but it's a trace of a significant event that can 
have major consequences on the VM.

> 
> I agree it's always better to dump something in QEMU when such happened,
> but IIUC what I mentioned above (by monitoring QEMU ramblock setups, and
> monitor host dmesg on any vaddr reported hwpoison) should also allow anyone
> to deduce the page size of affected vaddr, especially if it's for debugging
> purpose.  However I could possibly have missed the goal here..

You're right that knowing the address, the administrator can deduce what 
memory area was impacted and the associated page size. But the goal of 
these large page specific messages was to give details on the event type 
and immediately qualify the consequences.
Using large pages can also have drawbacks, and a large page specific 
message on memory error makes that more obvious !  Not only a debug msg, 
but an indication that the VM lost an unusually large amount of its memory.

>>
>> If you think that not displaying a specific message for large page loss can
>> help to get the recovery fixed, than I can change my proposal to do so.
>>
>> Early next week, I'll send a simplified version of my first 3 patches
>> without this specific messages and without the preallocation handling in all
>> remap cases, so you can evaluate this possibility.
> 
> Yes IMHO it'll always be helpful to separate it if possible.

I'm sending now a v8 version, without the specific messages and the 
remap notification. It should fix the main recovery bug we currently 
have. More messages and a notification dealing with pre-allocation can 
be added in a second step.

Please let me know if this v8 version can be integrated without the 
prealloc and specific messages ?

Thanks,
William.