From: Vivek Goyal <vgoyal@redhat.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Andy Lutomirski <luto@kernel.org>,
Paolo Bonzini <pbonzini@redhat.com>,
LKML <linux-kernel@vger.kernel.org>, X86 ML <x86@kernel.org>,
kvm list <kvm@vger.kernel.org>, stable <stable@vger.kernel.org>
Subject: Re: [PATCH v2] x86/kvm: Disable KVM_ASYNC_PF_SEND_ALWAYS
Date: Mon, 6 Apr 2020 15:09:51 -0400 [thread overview]
Message-ID: <20200406190951.GA19259@redhat.com> (raw)
In-Reply-To: <20200309202215.GM12561@hirez.programming.kicks-ass.net>
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@kernel.org> 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@redhat.com/
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@redhat.com/
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
next prev parent reply other threads:[~2020-04-06 19:10 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-07 2:26 [PATCH v2] x86/kvm: Disable KVM_ASYNC_PF_SEND_ALWAYS Andy Lutomirski
2020-03-07 15:03 ` Andy Lutomirski
2020-03-07 15:47 ` Thomas Gleixner
2020-03-07 15:59 ` Andy Lutomirski
2020-03-07 19:01 ` Thomas Gleixner
2020-03-07 19:34 ` Andy Lutomirski
2020-03-08 7:23 ` Thomas Gleixner
2020-03-09 6:57 ` Thomas Gleixner
2020-03-09 8:40 ` Paolo Bonzini
2020-03-09 9:09 ` Thomas Gleixner
2020-03-09 18:14 ` Andy Lutomirski
2020-03-09 19:05 ` Thomas Gleixner
2020-03-09 20:22 ` Peter Zijlstra
2020-04-06 19:09 ` Vivek Goyal [this message]
2020-04-06 20:25 ` Peter Zijlstra
2020-04-06 20:32 ` Andy Lutomirski
2020-04-06 20:42 ` Andy Lutomirski
2020-04-07 17:21 ` Vivek Goyal
2020-04-07 17:38 ` Andy Lutomirski
2020-04-07 20:20 ` Thomas Gleixner
2020-04-07 21:41 ` Andy Lutomirski
2020-04-07 22:07 ` Paolo Bonzini
2020-04-07 22:29 ` Andy Lutomirski
2020-04-08 0:30 ` Paolo Bonzini
2020-05-21 15:55 ` Vivek Goyal
2020-04-07 22:48 ` Thomas Gleixner
2020-04-08 4:48 ` Andy Lutomirski
2020-04-08 9:32 ` Borislav Petkov
2020-04-08 10:12 ` Thomas Gleixner
2020-04-08 18:23 ` Vivek Goyal
2020-04-07 22:49 ` Vivek Goyal
2020-04-08 10:01 ` Borislav Petkov
2020-04-07 22:04 ` Paolo Bonzini
2020-04-07 23:21 ` Thomas Gleixner
2020-04-08 8:23 ` Paolo Bonzini
2020-04-08 13:01 ` Thomas Gleixner
2020-04-08 15:38 ` Peter Zijlstra
2020-04-08 16:41 ` Thomas Gleixner
2020-04-09 9:03 ` Paolo Bonzini
2020-04-08 15:34 ` Sean Christopherson
2020-04-08 16:50 ` Paolo Bonzini
2020-04-08 18:01 ` Thomas Gleixner
2020-04-08 20:34 ` Vivek Goyal
2020-04-08 23:06 ` Thomas Gleixner
2020-04-08 23:14 ` Thomas Gleixner
2020-04-09 4:50 ` Andy Lutomirski
2020-04-09 9:43 ` Paolo Bonzini
2020-04-09 11:36 ` Andrew Cooper
2020-04-09 12:47 ` Paolo Bonzini
2020-04-09 14:13 ` Andrew Cooper
2020-04-09 14:32 ` Paolo Bonzini
2020-04-09 15:03 ` Andy Lutomirski
2020-04-09 15:17 ` Paolo Bonzini
2020-04-09 17:32 ` Andy Lutomirski
2020-04-06 21:32 ` Thomas Gleixner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200406190951.GA19259@redhat.com \
--to=vgoyal@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=stable@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox