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. So it would be nice if we can keep KVM_ASYNC_PF_SEND_ALWAYS around. Thanks Vivek
