From: Christoffer Dall <christoffer.dall@arm.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Alexander Graf" <graf@amazon.com>,
"Daniel P. Berrangé" <berrange@redhat.com>,
"Marc Zyngier" <maz@kernel.org>,
"lkml - Kernel Mailing List" <linux-kernel@vger.kernel.org>,
"Stefan Hajnoczi" <stefanha@redhat.com>,
"Heinrich Schuchardt" <xypron.glpk@gmx.de>,
kvmarm@lists.cs.columbia.edu,
arm-mail-list <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 1/1] KVM: inject data abort if instruction cannot be decoded
Date: Fri, 6 Sep 2019 15:44:40 +0200 [thread overview]
Message-ID: <20190906134440.GH4320@e113682-lin.lund.arm.com> (raw)
In-Reply-To: <CAFEAcA9vwyhAN8uO8=PpaBkBXb0Of4G0jEij7nMrYcnJjSRVjg@mail.gmail.com>
On Fri, Sep 06, 2019 at 02:31:42PM +0100, Peter Maydell wrote:
> On Fri, 6 Sep 2019 at 14:13, Christoffer Dall <christoffer.dall@arm.com> wrote:
> > I'd prefer leaving it to userspace to worry about, but I thought Peter
> > said that had been problematic historically, which I took at face value,
> > but I could have misunderstood.
> >
> > If QEMU, kvmtool, and whatever the crazy^H cool kids are using in
> > userspace these days are happy emulating the exception, then that's a
> > viable approach. The main concern I have with that is whether they'll
> > all get it right, and since we already have the code in the kernel to do
> > this, it might make sense to re-use the kernel logic for it.
>
> Well, for QEMU we've had code that in theory might do this but
> in practice it's never been tested. Essentially the problem is
> that nobody ever wants to inject an exception from userspace
> except in incredibly rare cases like "trying to use h/w breakpoints
> simultaneously inside the VM and also to debug the VM from outside"
> or "we're running on RAS hardware that just told us that the VM's
> RAM was faulty". There's no even vaguely commonly-used usecase
> for it today; and this ABI suggestion adds another "this is in
> practice almost never going to happen" case to the pile. The
> codepath is unreliable in QEMU because (a) it requires getting
> syncing of sysreg values to and from the kernel right -- this is
> about the only situation where userspace wants to modify sysregs
> during execution of the VM, as opposed to just reading them -- and
> (b) we try to reuse the code we already have that does TCG exception
> injection, which might or might not be a design mistake, and
> (c) as noted above it's a never-actually-used untested codepath...
>
> So I think if I were you I wouldn't commit to the kernel ABI until
> somebody had at least written some RFC-quality patches for QEMU and
> tested that they work and the ABI is OK in that sense. (For the
> avoidance of doubt, I'm not volunteering to do that myself.)
> I don't object to the idea in principle, though.
>
> PS: the other "injecting exceptions to the guest" oddity is that
> if the kernel *does* find the ISV information and returns to userspace
> for it to handle the MMIO, there's no way for userspace to say
> "actually that address is supposed to generate a data abort".
>
That's a good point. A synchronous interface with a separate mechanism
to ask the kernel to inject an exception might be a good solution, if
there's an elegant way to do the latter. I'll have a look at that.
Thanks,
Christoffer
next prev parent reply other threads:[~2019-09-06 13:44 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-04 18:07 [PATCH 1/1] KVM: inject data abort if instruction cannot be decoded Heinrich Schuchardt
2019-09-05 8:03 ` Marc Zyngier
2019-09-05 8:16 ` Peter Maydell
2019-09-05 8:25 ` Christoffer Dall
2019-09-05 8:32 ` Peter Maydell
2019-09-05 8:48 ` Heinrich Schuchardt
2019-09-05 8:52 ` Marc Zyngier
2019-09-05 8:56 ` Peter Maydell
2019-09-05 9:15 ` Marc Zyngier
2019-09-05 9:22 ` Christoffer Dall
2019-09-05 13:09 ` Marc Zyngier
2019-09-06 8:00 ` Christoffer Dall
2019-09-06 12:08 ` Alexander Graf
2019-09-06 12:34 ` Marc Zyngier
2019-09-06 13:02 ` [UNVERIFIED SENDER] " Alexander Graf
2019-09-06 13:12 ` Christoffer Dall
2019-09-06 13:16 ` Alexander Graf
2019-09-06 13:31 ` Peter Maydell
2019-09-06 13:41 ` Alexander Graf
2019-09-06 13:50 ` Peter Maydell
2019-09-06 14:12 ` Alexander Graf
2019-09-06 13:44 ` Christoffer Dall [this message]
2019-09-05 13:25 ` Heinrich Schuchardt
2019-09-06 7:58 ` Christoffer Dall
2019-09-05 8:28 ` Heinrich Schuchardt
2019-09-05 9:11 ` Marc Zyngier
2019-09-05 9:20 ` Stefan Hajnoczi
2019-09-05 9:23 ` Daniel P. Berrangé
2019-09-05 12:01 ` Heinrich Schuchardt
2019-09-05 12:16 ` Christoffer Dall
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=20190906134440.GH4320@e113682-lin.lund.arm.com \
--to=christoffer.dall@arm.com \
--cc=berrange@redhat.com \
--cc=graf@amazon.com \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=peter.maydell@linaro.org \
--cc=stefanha@redhat.com \
--cc=xypron.glpk@gmx.de \
/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;
as well as URLs for NNTP newsgroup(s).