Vivek Goyal <vgoyal@xxxxxxxxxx> writes: > On Mon, Mar 09, 2020 at 09:22:15PM +0100, Peter Zijlstra wrote: >> On Mon, Mar 09, 2020 at 08:05:18PM +0100, Thomas Gleixner wrote: >> > Andy Lutomirski <luto@xxxxxxxxxx> writes: >> >> > > I'm okay with the save/restore dance, I guess. It's just yet more >> > > entry crud to deal with architecture nastiness, except that this >> > > nastiness is 100% software and isn't Intel/AMD's fault. >> > >> > And we can do it in C and don't have to fiddle with it in the ASM >> > maze. >> >> Right; I'd still love to kill KVM_ASYNC_PF_SEND_ALWAYS though, even if >> we do the save/restore in do_nmi(). That is some wild brain melt. Also, >> AFAIK none of the distros are actually shipping a PREEMPT=y kernel >> anyway, so killing it shouldn't matter much. > > It will be nice if we can retain KVM_ASYNC_PF_SEND_ALWAYS. I have another > use case outside CONFIG_PREEMPT. > > I am trying to extend async pf interface to also report page fault errors > to the guest. > > https://lore.kernel.org/kvm/20200331194011.24834-1-vgoyal@xxxxxxxxxx/ > > Right now async page fault interface assumes that host will always be > able to successfully resolve the page fault and sooner or later PAGE_READY > event will be sent to guest. And there is no mechnaism to report the > errors back to guest. > > I am trying to add enhance virtiofs to directly map host page cache in guest. > > https://lore.kernel.org/linux-fsdevel/20200304165845.3081-1-vgoyal@xxxxxxxxxx/ > > There it is possible that a file page on host is mapped in guest and file > got truncated and page is not there anymore. Guest tries to access it, > and it generates async page fault. On host we will get -EFAULT and I > need to propagate it back to guest so that guest can either send SIGBUS > to process which caused this. Or if kernel was trying to do memcpy(), > then be able to use execpetion table error handling and be able to > return with error. (memcpy_mcflush()). > > For the second case to work, I will need async pf events to come in > even if guest is in kernel and CONFIG_PREEMPT=n. What? > So it would be nice if we can keep KVM_ASYNC_PF_SEND_ALWAYS around. No. If you want this stuff to be actually useful and correct, then please redesign it from scratch w/o abusing #PF. It want's to be a separate vector and then the pagefault resulting from your example above becomes a real #PF without any bells and whistels. Thanks, tglx