All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Maydell <peter.maydell@linaro.org>
To: Marc Zyngier <maz@kernel.org>
Cc: "Heinrich Schuchardt" <xypron.glpk@gmx.de>,
	"James Morse" <james.morse@arm.com>,
	"Julien Thierry" <julien.thierry@arm.com>,
	"Suzuki K Pouloze" <suzuki.poulose@arm.com>,
	"Stefan Hajnoczi" <stefanha@redhat.com>,
	"Daniel P . Berrangé" <berrange@redhat.com>,
	arm-mail-list <linux-arm-kernel@lists.infradead.org>,
	kvmarm@lists.cs.columbia.edu,
	"lkml - Kernel Mailing List" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/1] KVM: inject data abort if instruction cannot be decoded
Date: Thu, 5 Sep 2019 09:16:54 +0100	[thread overview]
Message-ID: <CAFEAcA-mc6cLmRGdGNOBR0PC1f_VBjvTdAL6xYtKjApx3NoPgQ@mail.gmail.com> (raw)
In-Reply-To: <86r24vrwyh.wl-maz@kernel.org>

On Thu, 5 Sep 2019 at 09:04, Marc Zyngier <maz@kernel.org> wrote:
> How can you tell that the access would fault? You have no idea at that
> stage (the kernel doesn't know about the MMIO ranges that userspace
> handles). All you know is that you're faced with a memory access that
> you cannot emulate in the kernel. Injecting a data abort at that stage
> is not something that the architecture allows.

To be fair, locking up the whole CPU (which is effectively
what the kvm_err/ENOSYS is going to do to the VM) isn't
something the architecture allows either :-)

> Of course, the best thing would be to actually fix the guest so that
> it doesn't use non-emulatable MMIO accesses. In general, that the sign
> of a bug in low-level accessors.

This is true, but the problem is that barfing out to userspace
makes it harder to debug the guest because it means that
the VM is immediately destroyed, whereas AIUI if we
inject some kind of exception then (assuming you're set up
to do kernel-debug via gdbstub) you can actually examine
the offending guest code with a debugger because at least
your VM is still around to inspect...

thanks
-- PMM

WARNING: multiple messages have this Message-ID (diff)
From: Peter Maydell <peter.maydell@linaro.org>
To: Marc Zyngier <maz@kernel.org>
Cc: "Daniel P . Berrangé" <berrange@redhat.com>,
	"Heinrich Schuchardt" <xypron.glpk@gmx.de>,
	"lkml - Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Stefan Hajnoczi" <stefanha@redhat.com>,
	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: Thu, 5 Sep 2019 09:16:54 +0100	[thread overview]
Message-ID: <CAFEAcA-mc6cLmRGdGNOBR0PC1f_VBjvTdAL6xYtKjApx3NoPgQ@mail.gmail.com> (raw)
In-Reply-To: <86r24vrwyh.wl-maz@kernel.org>

On Thu, 5 Sep 2019 at 09:04, Marc Zyngier <maz@kernel.org> wrote:
> How can you tell that the access would fault? You have no idea at that
> stage (the kernel doesn't know about the MMIO ranges that userspace
> handles). All you know is that you're faced with a memory access that
> you cannot emulate in the kernel. Injecting a data abort at that stage
> is not something that the architecture allows.

To be fair, locking up the whole CPU (which is effectively
what the kvm_err/ENOSYS is going to do to the VM) isn't
something the architecture allows either :-)

> Of course, the best thing would be to actually fix the guest so that
> it doesn't use non-emulatable MMIO accesses. In general, that the sign
> of a bug in low-level accessors.

This is true, but the problem is that barfing out to userspace
makes it harder to debug the guest because it means that
the VM is immediately destroyed, whereas AIUI if we
inject some kind of exception then (assuming you're set up
to do kernel-debug via gdbstub) you can actually examine
the offending guest code with a debugger because at least
your VM is still around to inspect...

thanks
-- PMM
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

WARNING: multiple messages have this Message-ID (diff)
From: Peter Maydell <peter.maydell@linaro.org>
To: Marc Zyngier <maz@kernel.org>
Cc: "Daniel P . Berrangé" <berrange@redhat.com>,
	"Suzuki K Pouloze" <suzuki.poulose@arm.com>,
	"Heinrich Schuchardt" <xypron.glpk@gmx.de>,
	"Julien Thierry" <julien.thierry@arm.com>,
	"lkml - Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"James Morse" <james.morse@arm.com>,
	"Stefan Hajnoczi" <stefanha@redhat.com>,
	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: Thu, 5 Sep 2019 09:16:54 +0100	[thread overview]
Message-ID: <CAFEAcA-mc6cLmRGdGNOBR0PC1f_VBjvTdAL6xYtKjApx3NoPgQ@mail.gmail.com> (raw)
In-Reply-To: <86r24vrwyh.wl-maz@kernel.org>

On Thu, 5 Sep 2019 at 09:04, Marc Zyngier <maz@kernel.org> wrote:
> How can you tell that the access would fault? You have no idea at that
> stage (the kernel doesn't know about the MMIO ranges that userspace
> handles). All you know is that you're faced with a memory access that
> you cannot emulate in the kernel. Injecting a data abort at that stage
> is not something that the architecture allows.

To be fair, locking up the whole CPU (which is effectively
what the kvm_err/ENOSYS is going to do to the VM) isn't
something the architecture allows either :-)

> Of course, the best thing would be to actually fix the guest so that
> it doesn't use non-emulatable MMIO accesses. In general, that the sign
> of a bug in low-level accessors.

This is true, but the problem is that barfing out to userspace
makes it harder to debug the guest because it means that
the VM is immediately destroyed, whereas AIUI if we
inject some kind of exception then (assuming you're set up
to do kernel-debug via gdbstub) you can actually examine
the offending guest code with a debugger because at least
your VM is still around to inspect...

thanks
-- PMM

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-09-05  8:17 UTC|newest]

Thread overview: 92+ 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-04 18:07 ` Heinrich Schuchardt
2019-09-04 18:07 ` Heinrich Schuchardt
2019-09-05  1:35 ` Guoheyi
2019-09-05  1:35   ` Guoheyi
2019-09-05  8:03 ` Marc Zyngier
2019-09-05  8:03   ` Marc Zyngier
2019-09-05  8:03   ` Marc Zyngier
2019-09-05  8:16   ` Peter Maydell [this message]
2019-09-05  8:16     ` Peter Maydell
2019-09-05  8:16     ` Peter Maydell
2019-09-05  8:25     ` Christoffer Dall
2019-09-05  8:25       ` Christoffer Dall
2019-09-05  8:25       ` Christoffer Dall
2019-09-05  8:32       ` Peter Maydell
2019-09-05  8:32         ` Peter Maydell
2019-09-05  8:32         ` Peter Maydell
2019-09-05  8:48     ` Heinrich Schuchardt
2019-09-05  8:48       ` Heinrich Schuchardt
2019-09-05  8:48       ` Heinrich Schuchardt
2019-09-05  8:52     ` Marc Zyngier
2019-09-05  8:52       ` Marc Zyngier
2019-09-05  8:52       ` Marc Zyngier
2019-09-05  8:56       ` Peter Maydell
2019-09-05  8:56         ` Peter Maydell
2019-09-05  8:56         ` Peter Maydell
2019-09-05  9:15         ` Marc Zyngier
2019-09-05  9:15           ` Marc Zyngier
2019-09-05  9:15           ` Marc Zyngier
2019-09-05  9:22         ` Christoffer Dall
2019-09-05  9:22           ` Christoffer Dall
2019-09-05  9:22           ` Christoffer Dall
2019-09-05 13:09           ` Marc Zyngier
2019-09-05 13:09             ` Marc Zyngier
2019-09-05 13:09             ` Marc Zyngier
2019-09-06  8:00             ` Christoffer Dall
2019-09-06  8:00               ` Christoffer Dall
2019-09-06  8:00               ` Christoffer Dall
2019-09-06 12:08               ` Alexander Graf
2019-09-06 12:08                 ` Alexander Graf
2019-09-06 12:08                 ` Alexander Graf
2019-09-06 12:34                 ` Marc Zyngier
2019-09-06 12:34                   ` Marc Zyngier
2019-09-06 12:34                   ` Marc Zyngier
2019-09-06 13:02                   ` [UNVERIFIED SENDER] " Alexander Graf
2019-09-06 13:02                     ` Alexander Graf
2019-09-06 13:02                     ` Alexander Graf
2019-09-06 13:12                 ` Christoffer Dall
2019-09-06 13:12                   ` Christoffer Dall
2019-09-06 13:12                   ` Christoffer Dall
2019-09-06 13:16                   ` Alexander Graf
2019-09-06 13:16                     ` Alexander Graf
2019-09-06 13:16                     ` Alexander Graf
2019-09-06 13:31                   ` Peter Maydell
2019-09-06 13:31                     ` Peter Maydell
2019-09-06 13:31                     ` Peter Maydell
2019-09-06 13:41                     ` Alexander Graf
2019-09-06 13:41                       ` Alexander Graf
2019-09-06 13:41                       ` Alexander Graf
2019-09-06 13:50                       ` Peter Maydell
2019-09-06 13:50                         ` Peter Maydell
2019-09-06 13:50                         ` Peter Maydell
2019-09-06 14:12                         ` Alexander Graf
2019-09-06 14:12                           ` Alexander Graf
2019-09-06 14:12                           ` Alexander Graf
2019-09-06 13:44                     ` Christoffer Dall
2019-09-06 13:44                       ` Christoffer Dall
2019-09-06 13:44                       ` Christoffer Dall
2019-09-05 13:25           ` Heinrich Schuchardt
2019-09-05 13:25             ` Heinrich Schuchardt
2019-09-05 13:25             ` Heinrich Schuchardt
2019-09-06  7:58             ` Christoffer Dall
2019-09-06  7:58               ` Christoffer Dall
2019-09-06  7:58               ` Christoffer Dall
2019-09-05  8:28   ` Heinrich Schuchardt
2019-09-05  8:28     ` Heinrich Schuchardt
2019-09-05  8:28     ` Heinrich Schuchardt
2019-09-05  9:11     ` Marc Zyngier
2019-09-05  9:11       ` Marc Zyngier
2019-09-05  9:11       ` Marc Zyngier
2019-09-05  9:20 ` Stefan Hajnoczi
2019-09-05  9:20   ` Stefan Hajnoczi
2019-09-05  9:20   ` Stefan Hajnoczi
2019-09-05  9:23   ` Daniel P. Berrangé
2019-09-05  9:23     ` Daniel P. Berrangé
2019-09-05  9:23     ` Daniel P. Berrangé
2019-09-05 12:01   ` Heinrich Schuchardt
2019-09-05 12:01     ` Heinrich Schuchardt
2019-09-05 12:01     ` Heinrich Schuchardt
2019-09-05 12:16     ` Christoffer Dall
2019-09-05 12:16       ` Christoffer Dall
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=CAFEAcA-mc6cLmRGdGNOBR0PC1f_VBjvTdAL6xYtKjApx3NoPgQ@mail.gmail.com \
    --to=peter.maydell@linaro.org \
    --cc=berrange@redhat.com \
    --cc=james.morse@arm.com \
    --cc=julien.thierry@arm.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=stefanha@redhat.com \
    --cc=suzuki.poulose@arm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.