All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoffer Dall <christoffer.dall@arm.com>
To: Marc Zyngier <maz@kernel.org>
Cc: "\"Daniel P. Berrangé\"" <berrange@redhat.com>,
	"Heinrich Schuchardt" <xypron.glpk@gmx.de>,
	"Stefan Hajnoczi" <stefanha@redhat.com>,
	kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v3 0/2] Improve handling of stage 2 aborts without instruction decode
Date: Mon, 21 Oct 2019 15:37:07 +0200	[thread overview]
Message-ID: <20191021133707.GA2652@e113682-lin.lund.arm.com> (raw)
In-Reply-To: <865zkjzpbf.wl-maz@kernel.org>

On Sun, Oct 20, 2019 at 11:25:24AM +0100, Marc Zyngier wrote:
> Hi Christoffer,
> 
> On Fri, 11 Oct 2019 12:07:04 +0100,
> Christoffer Dall <christoffer.dall@arm.com> wrote:
> > 
> > When a guest accesses memory outside the memory slots, KVM usually
> > bounces the access back to userspace with KVM_EXIT_MMIO.  However, on
> > arm/arm64 systems, certain load/store instructions did not provide
> > decoding info for the hypervisor to emulate the instruction, and in this
> > case KVM has rather rudely returned -ENOSYS and printed a not overly
> > helpful error message:
> > 
> >   load/store instruction decoding not implemented
> > 
> > This patch series improves the error message and allows userspace to be
> > notified of this event instead of receiving -ENOSYS, and also allows
> > userspace to ask KVM to inject an external abort to the guest, which it
> > can use for any memory access that it either cannot handle.
> > 
> > One remaining case which this patch set does not address is if the guest
> > accesses an in-kernel emulated device, such as the VGIC, but using a
> > load/store instruction which doesn't provide decode info.  With these
> > patches, this will return to userspace for it to handle, but there's no
> > way for userspace to return the decoding information to KVM and have KVM
> > complete the access to the in-kernel emulated device.  I have no plans
> > to address this limitation.
> 
> You had some pending comments on patch 2, and you seem to indicate
> that you would respin the series. Do you have plans to do so in the
> coming days? I'd like to put that series into -next, but I can either
> wait for your respin, or queue it as it is and apply fixes on top.
> 

I think those for v2 and this is v3 which should address those concerns.
Did I miss something or manage to confuse mysel here?

Thanks,

    Christoffer
_______________________________________________
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: Christoffer Dall <christoffer.dall@arm.com>
To: Marc Zyngier <maz@kernel.org>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
	"\"Daniel P. Berrangé\"" <berrange@redhat.com>,
	"Suzuki K Poulose" <suzuki.poulose@arm.com>,
	"Heinrich Schuchardt" <xypron.glpk@gmx.de>,
	"Alexander Graf" <graf@amazon.com>,
	"Julien Thierry" <julien.thierry.kdev@gmail.com>,
	"Stefan Hajnoczi" <stefanha@redhat.com>,
	"James Morse" <james.morse@arm.com>,
	kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v3 0/2] Improve handling of stage 2 aborts without instruction decode
Date: Mon, 21 Oct 2019 15:37:07 +0200	[thread overview]
Message-ID: <20191021133707.GA2652@e113682-lin.lund.arm.com> (raw)
In-Reply-To: <865zkjzpbf.wl-maz@kernel.org>

On Sun, Oct 20, 2019 at 11:25:24AM +0100, Marc Zyngier wrote:
> Hi Christoffer,
> 
> On Fri, 11 Oct 2019 12:07:04 +0100,
> Christoffer Dall <christoffer.dall@arm.com> wrote:
> > 
> > When a guest accesses memory outside the memory slots, KVM usually
> > bounces the access back to userspace with KVM_EXIT_MMIO.  However, on
> > arm/arm64 systems, certain load/store instructions did not provide
> > decoding info for the hypervisor to emulate the instruction, and in this
> > case KVM has rather rudely returned -ENOSYS and printed a not overly
> > helpful error message:
> > 
> >   load/store instruction decoding not implemented
> > 
> > This patch series improves the error message and allows userspace to be
> > notified of this event instead of receiving -ENOSYS, and also allows
> > userspace to ask KVM to inject an external abort to the guest, which it
> > can use for any memory access that it either cannot handle.
> > 
> > One remaining case which this patch set does not address is if the guest
> > accesses an in-kernel emulated device, such as the VGIC, but using a
> > load/store instruction which doesn't provide decode info.  With these
> > patches, this will return to userspace for it to handle, but there's no
> > way for userspace to return the decoding information to KVM and have KVM
> > complete the access to the in-kernel emulated device.  I have no plans
> > to address this limitation.
> 
> You had some pending comments on patch 2, and you seem to indicate
> that you would respin the series. Do you have plans to do so in the
> coming days? I'd like to put that series into -next, but I can either
> wait for your respin, or queue it as it is and apply fixes on top.
> 

I think those for v2 and this is v3 which should address those concerns.
Did I miss something or manage to confuse mysel here?

Thanks,

    Christoffer

_______________________________________________
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 13:37 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
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 [this message]
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=20191021133707.GA2652@e113682-lin.lund.arm.com \
    --to=christoffer.dall@arm.com \
    --cc=berrange@redhat.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.