All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoffer Dall <cdall@linaro.org>
To: James Morse <james.morse@arm.com>
Cc: devicetree@vger.kernel.org, Marc Zyngier <marc.zyngier@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Rob Herring <robh+dt@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	kvmarm@lists.cs.columbia.edu
Subject: Re: [PATCH 00/11] arm64/firmware: Software Delegated Exception Interface
Date: Wed, 7 Jun 2017 11:53:26 +0200	[thread overview]
Message-ID: <20170607095326.GC24481@cbox> (raw)
In-Reply-To: <5937CB3C.6040800@arm.com>

On Wed, Jun 07, 2017 at 10:45:32AM +0100, James Morse wrote:
> Hi Christoffer,
> 
> On 06/06/17 20:59, Christoffer Dall wrote:
> > On Mon, May 15, 2017 at 06:43:48PM +0100, James Morse wrote:
> >> Running the event handler behind VHE-KVM's back has some side effects: The
> >> event handler will blindly use any registers that are shared between the host
> >> and guest. The two that I think matter are TPIDR_EL1, and the debug state. The
> >> guest may have set MDSCR_EL1 so debug exceptions must remain masked. The
> >> guest's TPIDR_EL1 will be used by the event handler if it accesses per-cpu
> >> variables. This needs fixing. The first part of this series juggles KVMs use
> >> of TPIDR_EL2 so that we share it with the host on VHE systems. An equivalent
> >> change for 32bit is on my todo list. (one alternative to this is to have a
> >> parody world switch in the SDEI event handler, but this would mean special
> >> casing interrupted guests, and be an ABI link to KVM.)
> >>
> >> Causing a synchronous exception from an event handler will cause KVM to
> >> hyp-panic, but may silently succeed if the event didn't interrupt a guest.
> >> (I may WARN_ON() if this happens in a later patch). You because of this you
> > 
> > The last sentence here doesn't make much sense to me.
> 
> If this interrupts a VHE-guest, KVM's hyp-vectors remain in vbar_el2. If we then
> take a synchronous exception, KVM will assume this happened during world switch
> and panic.
> In contrast if you didn't interrupt a guest, the kernel vectors are in vbar_el2,
> so the fault will be handled.

Sorry, I actually just meant the grammar... "You because of this you..."

> 
> This 'silently succeed' only occurred to me when writing the cover-letter,
> (hence its probably worded badly). I plan to catch it by save-restoring the
> exception registers, and warning if they've changed as this would hyp-panic if
> you interrupted a guest.
> 

But I didn't understand that before, and didn't realize that 'silently
succeed' may not be what you want.

Thanks for the explanation.

-Christoffer

WARNING: multiple messages have this Message-ID (diff)
From: cdall@linaro.org (Christoffer Dall)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 00/11] arm64/firmware: Software Delegated Exception Interface
Date: Wed, 7 Jun 2017 11:53:26 +0200	[thread overview]
Message-ID: <20170607095326.GC24481@cbox> (raw)
In-Reply-To: <5937CB3C.6040800@arm.com>

On Wed, Jun 07, 2017 at 10:45:32AM +0100, James Morse wrote:
> Hi Christoffer,
> 
> On 06/06/17 20:59, Christoffer Dall wrote:
> > On Mon, May 15, 2017 at 06:43:48PM +0100, James Morse wrote:
> >> Running the event handler behind VHE-KVM's back has some side effects: The
> >> event handler will blindly use any registers that are shared between the host
> >> and guest. The two that I think matter are TPIDR_EL1, and the debug state. The
> >> guest may have set MDSCR_EL1 so debug exceptions must remain masked. The
> >> guest's TPIDR_EL1 will be used by the event handler if it accesses per-cpu
> >> variables. This needs fixing. The first part of this series juggles KVMs use
> >> of TPIDR_EL2 so that we share it with the host on VHE systems. An equivalent
> >> change for 32bit is on my todo list. (one alternative to this is to have a
> >> parody world switch in the SDEI event handler, but this would mean special
> >> casing interrupted guests, and be an ABI link to KVM.)
> >>
> >> Causing a synchronous exception from an event handler will cause KVM to
> >> hyp-panic, but may silently succeed if the event didn't interrupt a guest.
> >> (I may WARN_ON() if this happens in a later patch). You because of this you
> > 
> > The last sentence here doesn't make much sense to me.
> 
> If this interrupts a VHE-guest, KVM's hyp-vectors remain in vbar_el2. If we then
> take a synchronous exception, KVM will assume this happened during world switch
> and panic.
> In contrast if you didn't interrupt a guest, the kernel vectors are in vbar_el2,
> so the fault will be handled.

Sorry, I actually just meant the grammar... "You because of this you..."

> 
> This 'silently succeed' only occurred to me when writing the cover-letter,
> (hence its probably worded badly). I plan to catch it by save-restoring the
> exception registers, and warning if they've changed as this would hyp-panic if
> you interrupted a guest.
> 

But I didn't understand that before, and didn't realize that 'silently
succeed' may not be what you want.

Thanks for the explanation.

-Christoffer

  reply	other threads:[~2017-06-07  9:49 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-15 17:43 [PATCH 00/11] arm64/firmware: Software Delegated Exception Interface James Morse
2017-05-15 17:43 ` James Morse
2017-05-15 17:43 ` [PATCH 01/11] KVM: arm64: Store vcpu on the stack during __guest_enter() James Morse
2017-05-15 17:43   ` James Morse
     [not found]   ` <20170515174400.29735-2-james.morse-5wv7dgnIgG8@public.gmane.org>
2017-06-06 19:59     ` Christoffer Dall
2017-06-06 19:59       ` Christoffer Dall
2017-08-08 16:48       ` James Morse
2017-08-08 16:48         ` James Morse
     [not found]         ` <5989EB5D.6-5wv7dgnIgG8@public.gmane.org>
2017-08-09  8:48           ` Christoffer Dall
2017-08-09  8:48             ` Christoffer Dall
2017-05-15 17:43 ` [PATCH 05/11] arm64: KVM: Stop save/restoring host tpidr_el1 on VHE James Morse
2017-05-15 17:43   ` James Morse
     [not found]   ` <20170515174400.29735-6-james.morse-5wv7dgnIgG8@public.gmane.org>
2017-06-06 20:00     ` Christoffer Dall
2017-06-06 20:00       ` Christoffer Dall
     [not found] ` <20170515174400.29735-1-james.morse-5wv7dgnIgG8@public.gmane.org>
2017-05-15 17:43   ` [PATCH 02/11] KVM: arm/arm64: Convert kvm_host_cpu_state to a static per-cpu allocation James Morse
2017-05-15 17:43     ` James Morse
     [not found]     ` <20170515174400.29735-3-james.morse-5wv7dgnIgG8@public.gmane.org>
2017-06-06 19:59       ` Christoffer Dall
2017-06-06 19:59         ` Christoffer Dall
2017-05-15 17:43   ` [PATCH 03/11] KVM: arm64: Change hyp_panic()s dependency on tpidr_el2 James Morse
2017-05-15 17:43     ` James Morse
2017-06-06 19:45     ` Christoffer Dall
2017-06-06 19:45       ` Christoffer Dall
2017-06-08 10:23       ` James Morse
2017-06-08 10:23         ` James Morse
     [not found]         ` <593925BB.30503-5wv7dgnIgG8@public.gmane.org>
2017-06-08 10:34           ` Christoffer Dall
2017-06-08 10:34             ` Christoffer Dall
2017-05-15 17:43   ` [PATCH 04/11] arm64: alternatives: use tpidr_el2 on VHE hosts James Morse
2017-05-15 17:43     ` James Morse
2017-05-15 17:43   ` [PATCH 06/11] dt-bindings: add devicetree binding for describing arm64 SDEI firmware James Morse
2017-05-15 17:43     ` James Morse
2017-05-19  1:48     ` Rob Herring
2017-05-19  1:48       ` Rob Herring
2017-06-07  8:28       ` James Morse
2017-06-07  8:28         ` James Morse
2017-05-15 17:43   ` [PATCH 08/11] arm64: kernel: Add arch-specific SDEI entry code and CPU masking James Morse
2017-05-15 17:43     ` James Morse
2017-05-15 17:43   ` [PATCH 09/11] firmware: arm_sdei: Add support for CPU and system power states James Morse
2017-05-15 17:43     ` James Morse
2017-05-15 17:43   ` [PATCH 10/11] firmware: arm_sdei: add support for CPU private events James Morse
2017-05-15 17:43     ` James Morse
2017-05-15 17:43   ` [PATCH 11/11] KVM: arm64: Delegate support for SDEI to userspace James Morse
2017-05-15 17:43     ` James Morse
     [not found]     ` <20170515174400.29735-12-james.morse-5wv7dgnIgG8@public.gmane.org>
2017-06-06 19:58       ` Christoffer Dall
2017-06-06 19:58         ` Christoffer Dall
2017-07-26 17:00         ` James Morse
2017-07-26 17:00           ` James Morse
     [not found]           ` <5978CA93.5090600-5wv7dgnIgG8@public.gmane.org>
2017-07-27  7:49             ` Christoffer Dall
2017-07-27  7:49               ` Christoffer Dall
2017-06-06 19:59   ` [PATCH 00/11] arm64/firmware: Software Delegated Exception Interface Christoffer Dall
2017-06-06 19:59     ` Christoffer Dall
2017-06-07  9:45     ` James Morse
2017-06-07  9:45       ` James Morse
2017-06-07  9:53       ` Christoffer Dall [this message]
2017-06-07  9:53         ` Christoffer Dall
2017-05-15 17:43 ` [PATCH 07/11] firmware: arm_sdei: Add driver for Software Delegated Exceptions James Morse
2017-05-15 17:43   ` James Morse
     [not found]   ` <20170515174400.29735-8-james.morse-5wv7dgnIgG8@public.gmane.org>
2017-07-19 13:52     ` Dave Martin
2017-07-19 13:52       ` Dave Martin
     [not found]       ` <20170719135213.GA1538-M5GwZQ6tE7x5pKCnmE3YQBJ8xKzm50AiAL8bYrjMMd8@public.gmane.org>
2017-08-08 16:48         ` James Morse
2017-08-08 16:48           ` James Morse

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=20170607095326.GC24481@cbox \
    --to=cdall@linaro.org \
    --cc=catalin.marinas@arm.com \
    --cc=devicetree@vger.kernel.org \
    --cc=james.morse@arm.com \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=marc.zyngier@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=will.deacon@arm.com \
    /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.