All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Graf <graf@amazon.com>
To: Christoffer Dall <christoffer.dall@arm.com>,
	<kvmarm@lists.cs.columbia.edu>
Cc: "Daniel P. Berrangé" <berrange@redhat.com>,
	"Marc Zyngier" <maz@kernel.org>,
	"Stefan Hajnoczi" <stefanha@redhat.com>,
	"Heinrich Schuchardt" <xypron.glpk@gmx.de>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v3 2/2] KVM: arm/arm64: Allow user injection of external data aborts
Date: Mon, 21 Oct 2019 22:21:09 +0200	[thread overview]
Message-ID: <26fb84dc-17c8-355e-b88b-e6e0b332998b@amazon.com> (raw)
In-Reply-To: <20191011110709.2764-3-christoffer.dall@arm.com>



On 11.10.19 13:07, Christoffer Dall wrote:
> In some scenarios, such as buggy guest or incorrect configuration of the
> VMM and firmware description data, userspace will detect a memory access
> to a portion of the IPA, which is not mapped to any MMIO region.
> 
> For this purpose, the appropriate action is to inject an external abort
> to the guest.  The kernel already has functionality to inject an
> external abort, but we need to wire up a signal from user space that
> lets user space tell the kernel to do this.
> 
> It turns out, we already have the set event functionality which we can
> perfectly reuse for this.
> 
> Signed-off-by: Christoffer Dall <christoffer.dall@arm.com>

Reviewed-by: Alexander Graf <graf@amazon.com>


Alex



Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879


_______________________________________________
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: Alexander Graf <graf@amazon.com>
To: Christoffer Dall <christoffer.dall@arm.com>,
	<kvmarm@lists.cs.columbia.edu>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
	"Daniel P. Berrangé" <berrange@redhat.com>,
	"Suzuki K Poulose" <suzuki.poulose@arm.com>,
	"Marc Zyngier" <maz@kernel.org>,
	"James Morse" <james.morse@arm.com>,
	"Julien Thierry" <julien.thierry.kdev@gmail.com>,
	"Stefan Hajnoczi" <stefanha@redhat.com>,
	"Heinrich Schuchardt" <xypron.glpk@gmx.de>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v3 2/2] KVM: arm/arm64: Allow user injection of external data aborts
Date: Mon, 21 Oct 2019 22:21:09 +0200	[thread overview]
Message-ID: <26fb84dc-17c8-355e-b88b-e6e0b332998b@amazon.com> (raw)
In-Reply-To: <20191011110709.2764-3-christoffer.dall@arm.com>



On 11.10.19 13:07, Christoffer Dall wrote:
> In some scenarios, such as buggy guest or incorrect configuration of the
> VMM and firmware description data, userspace will detect a memory access
> to a portion of the IPA, which is not mapped to any MMIO region.
> 
> For this purpose, the appropriate action is to inject an external abort
> to the guest.  The kernel already has functionality to inject an
> external abort, but we need to wire up a signal from user space that
> lets user space tell the kernel to do this.
> 
> It turns out, we already have the set event functionality which we can
> perfectly reuse for this.
> 
> Signed-off-by: Christoffer Dall <christoffer.dall@arm.com>

Reviewed-by: Alexander Graf <graf@amazon.com>


Alex



Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879


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

  reply	other threads:[~2019-10-21 20:21 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-11 11:07 [PATCH v3 0/2] Improve handling of stage 2 aborts without instruction decode Christoffer Dall
2019-10-11 11:07 ` Christoffer Dall
2019-10-11 11:07 ` [PATCH v3 1/2] KVM: arm/arm64: Allow reporting non-ISV data aborts to userspace Christoffer Dall
2019-10-11 11:07   ` Christoffer Dall
2019-10-11 11:07 ` [PATCH v3 2/2] KVM: arm/arm64: Allow user injection of external data aborts Christoffer Dall
2019-10-11 11:07   ` Christoffer Dall
2019-10-21 20:21   ` Alexander Graf [this message]
2019-10-21 20:21     ` Alexander Graf
2019-10-11 11:07 ` [kvmtool v3 3/5] update headers: Update the KVM headers for new Arm fault reporting features Christoffer Dall
2019-10-11 11:07   ` Christoffer Dall
2019-10-11 11:07 ` [kvmtool v3 4/5] arm: Handle exits from undecoded load/store instructions Christoffer Dall
2019-10-11 11:07   ` Christoffer Dall
2019-10-11 11:07 ` [kvmtool v3 5/5] arm: Inject external data aborts when accessing holes in the memory map Christoffer Dall
2019-10-11 11:07   ` Christoffer Dall
2019-10-20 10:25 ` [PATCH v3 0/2] Improve handling of stage 2 aborts without instruction decode Marc Zyngier
2019-10-20 10:25   ` Marc Zyngier
2019-10-21 13:37   ` Christoffer Dall
2019-10-21 13:37     ` Christoffer Dall
2019-10-21 13:59     ` Marc Zyngier
2019-10-21 13:59       ` Marc Zyngier

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=26fb84dc-17c8-355e-b88b-e6e0b332998b@amazon.com \
    --to=graf@amazon.com \
    --cc=berrange@redhat.com \
    --cc=christoffer.dall@arm.com \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=maz@kernel.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 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.