On Thu, Sep 21, 2023, isaku.yamahata@xxxxxxxxx wrote:
> From: Isaku Yamahata <isaku.yamahata@xxxxxxxxx>
>
> To test error_remove_page() method of KVM gmem, add a new ioctl to
> inject memory failure based on offset of guest memfd.
>
> Signed-off-by: Isaku Yamahata <isaku.yamahata@xxxxxxxxx>
> ---
> include/uapi/linux/kvm.h | 6 ++++
> virt/kvm/guest_mem.c | 68 ++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 74 insertions(+)
>
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index 65fc983af840..4160614bcc0f 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -2323,4 +2323,10 @@ struct kvm_create_guest_memfd {
> __u64 reserved[6];
> };
>
> +#define KVM_GUEST_MEMORY_FAILURE _IOWR(KVMIO, 0xd5, struct kvm_guest_memory_failure)
If we're going to add a KVM ioctl(), my vote is to make it a generic ioctl(), not
something that's specific to guest_memfd(). IIUC, all we need is the PFN, so the
only downside is that it'd require valid memslots. But the test isn't all that
interesting unless there are memslots, so I don't see that as a negative.
And if we add an ioctl(), it should be conditioned on CONFIG_HWPOISON_INJECT.
An alternative I think we should seriously consider is using the FAULT_INJECTION
framework to poison pages. We (Google) have plans to utilize fault injection for
other things in KVM, e.g. to inject "failures" on CMPXCHG in atomic SPTE updates
to force KVM down unlikely slow paths. I don't expect us to get patches posted
until early next year due to priorities, but hell or high water we will get patches
posted at some point.
The fault injection framework might be overkill for injecting memory errors, e.g.
a single ioctl() is definitely simpler to setup, but I suspect it would also be
much more powerful in the long run..
