On Fri, 14 Dec 2018 at 13:56, James Morse <james.morse@xxxxxxx> wrote: > > Hi Dongjiu Geng, > > On 14/12/2018 10:15, Dongjiu Geng wrote: > > When user space do memory recovery, it will check whether KVM and > > guest support the error recovery, only when both of them support, > > user space will do the error recovery. This patch exports this > > capability of KVM to user space. > > I can understand user-space only wanting to do the work if host and guest > support the feature. But 'error recovery' isn't a KVM feature, its a Linux > kernel feature. > > KVM will send it's user-space a SIGBUS with MCEERR code whenever its trying to > map a page at stage2 that the kernel-mm code refuses this because its poisoned. > (e.g. check_user_page_hwpoison(), get_user_pages() returns -EHWPOISON) > > This is exactly the same as happens to a normal user-space process. > > I think you really want to know if the host kernel was built with > CONFIG_MEMORY_FAILURE. Does userspace need to care about that? Presumably if the host kernel wasn't built with that support then it will simply never deliver any memory failure events to QEMU, which is fine. The point I was trying to make in the email Dongjiu references (https://patchwork.codeaurora.org/patch/652261/) is simply that "QEMU gets memory-failure notifications from the host kernel" does not imply "the guest is prepared to receive memory failure notifications", and so the code path which handles the SIGBUS must do some kind of check for whether the guest CPU is a type which expects them and that the board code set up the ACPI tables that it wants to fill in. thanks -- PMM
