On Fri, Sep 22, 2023, Isaku Yamahata wrote: > On Thu, Sep 21, 2023 at 01:29:59PM -0700, > Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > > On Thu, Sep 21, 2023, isaku.yamahata@xxxxxxxxx wrote: > > > From: Isaku Yamahata <isaku.yamahata@xxxxxxxxx> > > > > > > This patch series is to implement test cases for the KVM gmem error_remove_page > > > method. > > > - Update punch hole method to truncate pages > > > - Add a new ioctl KVM_GUEST_MEMORY_FAILURE to inject memory failure on > > > offset of gmem > > > > Doh. Please try to communicate what you're working on. I was just about to hit > > SEND on a series to fix the truncation bug, and to add a similar test. I would > > have happily punted that in your direction, but I had no idea that you were aware > > of the bug[*], let alone working on a fix. I could have explicitly stated that > > I was going to fix the bug, but I thought that it was implied that I needed to > > clean up my own mess. > > Oops sorry. Now I'm considering about machine check injection. > i.e. somehow trigger kvm_machine_check() and its own test cases. Unless we can't extend fadvise() for some reason, I think we should pursue FADV_HWPOISION. The enabling should be downright trivial, e.g. just implement file_operations.fadvise() for guest_memfd, have it handle FADV_HWPOISON, and pass everything else to generic_fadvise(). It'll basically be your ioctl() just without a dedicated ioctl(). At the very least, we should run the idea past the fs maintainers.
