From: Marc Zyngier <maz@kernel.org>
To: Qais Yousef <qais.yousef@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
"Peter Zijlstra (Intel)" <peterz@infradead.org>,
Morten Rasmussen <morten.rasmussen@arm.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
James Morse <james.morse@arm.com>,
linux-arm-kernel@lists.infradead.org, linux-arch@vger.kernel.org
Subject: Re: [RFC PATCH v2 1/4] arm64: kvm: Handle Asymmetric AArch32 systems
Date: Wed, 21 Oct 2020 14:51:32 +0100 [thread overview]
Message-ID: <87587dbfb7bee53eca4d1b837fd8194a@kernel.org> (raw)
In-Reply-To: <20201021133543.zeyghjzujivnds2d@e107158-lin>
On 2020-10-21 14:35, Qais Yousef wrote:
> On 10/21/20 13:02, Marc Zyngier wrote:
>> On 2020-10-21 11:46, Qais Yousef wrote:
>> > On a system without uniform support for AArch32 at EL0, it is possible
>> > for the guest to force run AArch32 at EL0 and potentially cause an
>> > illegal exception if running on the wrong core.
>>
>> s/the wrong core/a core without AArch32/
>>
>> >
>> > Add an extra check to catch if the guest ever does that and prevent it
>>
>> Not "if the guest ever does that". Rather "let's hope we are lucky
>> enough
>> to catch the guest doing that".
>>
>> > from running again by resetting vcpu->arch.target and return
>> > ARM_EXCEPTION_IL.
>> >
>> > We try to catch this misbehavior as early as possible and not rely on
>> > PSTATE.IL to occur.
>> >
>> > Tested on Juno by instrumenting the host to:
>> >
>> > * Fake asym aarch32.
>> > * Instrument KVM to make the asymmetry visible to the guest.
>> >
>> > Any attempt to run 32bit app in the guest will produce such error on
>> > qemu:
>>
>> Not *any* attempt. Only the ones where the guest exits whilst in
>> AArch32 EL0. It is perfectly possible for the guest to use AArch32
>> undetected for quite a while.
>
> Thanks Marc! I'll change them all.
>
>> >
>> > # ./test
>> > error: kvm run failed Invalid argument
>> > PC=ffff800010945080 X00=ffff800016a45014 X01=ffff800010945058
>> > X02=ffff800016917190 X03=0000000000000000 X04=0000000000000000
>> > X05=00000000fffffffb X06=0000000000000000 X07=ffff80001000bab0
>> > X08=0000000000000000 X09=0000000092ec5193 X10=0000000000000000
>> > X11=ffff80001608ff40 X12=ffff000075fcde86 X13=ffff000075fcde88
>> > X14=ffffffffffffffff X15=ffff00007b2105a8 X16=ffff00007b006d50
>> > X17=0000000000000000 X18=0000000000000000 X19=ffff00007a82b000
>> > X20=0000000000000000 X21=ffff800015ccd158 X22=ffff00007a82b040
>> > X23=ffff00007a82b008 X24=0000000000000000 X25=ffff800015d169b0
>> > X26=ffff8000126d05bc X27=0000000000000000 X28=0000000000000000
>> > X29=ffff80001000ba90 X30=ffff80001093f3dc SP=ffff80001000ba90
>> > PSTATE=60000005 -ZC- EL1h
>> > qemu-system-aarch64: Failed to get KVM_REG_ARM_TIMER_CNT
>>
>> It'd be worth working out:
>> - why does this show an AArch64 mode it we caught the vcpu in AArch32?
>> - why does QEMU shout about the timer register?
>
> /me puts a monocular on
>
> Which bit is the AArch64?
It clearly spits out "EL1h", and PSTATE.M is 5, also consistent with
EL1h.
> It did surprise me that it is shouting about the timer. My guess was
> that
> a timer interrupt at the guest between exit/reentry caused the state
> change and
> the failure to read the timer register? Since the target is no longer
> valid it
> falls over, hopefully as expected. I could have been naive of course.
> That
> explanation made sense to my mind so I didn't dig further.
Userspace is never involved with the timer interrupt, unless you've
elected
to have the interrupt controller in userspace, which I seriously doubt.
As we are introducing a change to the userspace ABI, it'd be interesting
to find out what is happening here.
M.
--
Jazz is not dead. It just smells funny...
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Qais Yousef <qais.yousef@arm.com>
Cc: linux-arch@vger.kernel.org, Will Deacon <will@kernel.org>,
"Peter Zijlstra \(Intel\)" <peterz@infradead.org>,
Catalin Marinas <catalin.marinas@arm.com>,
James Morse <james.morse@arm.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Morten Rasmussen <morten.rasmussen@arm.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH v2 1/4] arm64: kvm: Handle Asymmetric AArch32 systems
Date: Wed, 21 Oct 2020 14:51:32 +0100 [thread overview]
Message-ID: <87587dbfb7bee53eca4d1b837fd8194a@kernel.org> (raw)
In-Reply-To: <20201021133543.zeyghjzujivnds2d@e107158-lin>
On 2020-10-21 14:35, Qais Yousef wrote:
> On 10/21/20 13:02, Marc Zyngier wrote:
>> On 2020-10-21 11:46, Qais Yousef wrote:
>> > On a system without uniform support for AArch32 at EL0, it is possible
>> > for the guest to force run AArch32 at EL0 and potentially cause an
>> > illegal exception if running on the wrong core.
>>
>> s/the wrong core/a core without AArch32/
>>
>> >
>> > Add an extra check to catch if the guest ever does that and prevent it
>>
>> Not "if the guest ever does that". Rather "let's hope we are lucky
>> enough
>> to catch the guest doing that".
>>
>> > from running again by resetting vcpu->arch.target and return
>> > ARM_EXCEPTION_IL.
>> >
>> > We try to catch this misbehavior as early as possible and not rely on
>> > PSTATE.IL to occur.
>> >
>> > Tested on Juno by instrumenting the host to:
>> >
>> > * Fake asym aarch32.
>> > * Instrument KVM to make the asymmetry visible to the guest.
>> >
>> > Any attempt to run 32bit app in the guest will produce such error on
>> > qemu:
>>
>> Not *any* attempt. Only the ones where the guest exits whilst in
>> AArch32 EL0. It is perfectly possible for the guest to use AArch32
>> undetected for quite a while.
>
> Thanks Marc! I'll change them all.
>
>> >
>> > # ./test
>> > error: kvm run failed Invalid argument
>> > PC=ffff800010945080 X00=ffff800016a45014 X01=ffff800010945058
>> > X02=ffff800016917190 X03=0000000000000000 X04=0000000000000000
>> > X05=00000000fffffffb X06=0000000000000000 X07=ffff80001000bab0
>> > X08=0000000000000000 X09=0000000092ec5193 X10=0000000000000000
>> > X11=ffff80001608ff40 X12=ffff000075fcde86 X13=ffff000075fcde88
>> > X14=ffffffffffffffff X15=ffff00007b2105a8 X16=ffff00007b006d50
>> > X17=0000000000000000 X18=0000000000000000 X19=ffff00007a82b000
>> > X20=0000000000000000 X21=ffff800015ccd158 X22=ffff00007a82b040
>> > X23=ffff00007a82b008 X24=0000000000000000 X25=ffff800015d169b0
>> > X26=ffff8000126d05bc X27=0000000000000000 X28=0000000000000000
>> > X29=ffff80001000ba90 X30=ffff80001093f3dc SP=ffff80001000ba90
>> > PSTATE=60000005 -ZC- EL1h
>> > qemu-system-aarch64: Failed to get KVM_REG_ARM_TIMER_CNT
>>
>> It'd be worth working out:
>> - why does this show an AArch64 mode it we caught the vcpu in AArch32?
>> - why does QEMU shout about the timer register?
>
> /me puts a monocular on
>
> Which bit is the AArch64?
It clearly spits out "EL1h", and PSTATE.M is 5, also consistent with
EL1h.
> It did surprise me that it is shouting about the timer. My guess was
> that
> a timer interrupt at the guest between exit/reentry caused the state
> change and
> the failure to read the timer register? Since the target is no longer
> valid it
> falls over, hopefully as expected. I could have been naive of course.
> That
> explanation made sense to my mind so I didn't dig further.
Userspace is never involved with the timer interrupt, unless you've
elected
to have the interrupt controller in userspace, which I seriously doubt.
As we are introducing a change to the userspace ABI, it'd be interesting
to find out what is happening here.
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-10-21 13:51 UTC|newest]
Thread overview: 114+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-21 10:46 [RFC PATCH v2 0/4] Add support for Asymmetric AArch32 systems Qais Yousef
2020-10-21 10:46 ` Qais Yousef
2020-10-21 10:46 ` [RFC PATCH v2 1/4] arm64: kvm: Handle " Qais Yousef
2020-10-21 10:46 ` Qais Yousef
2020-10-21 12:02 ` Marc Zyngier
2020-10-21 12:02 ` Marc Zyngier
2020-10-21 13:35 ` Qais Yousef
2020-10-21 13:35 ` Qais Yousef
2020-10-21 13:51 ` Marc Zyngier [this message]
2020-10-21 13:51 ` Marc Zyngier
2020-10-21 14:38 ` Qais Yousef
2020-10-21 14:38 ` Qais Yousef
2020-11-02 17:58 ` Qais Yousef
2020-11-02 17:58 ` Qais Yousef
2020-10-21 10:46 ` [RFC PATCH v2 2/4] arm64: Add support for asymmetric AArch32 EL0 configurations Qais Yousef
2020-10-21 10:46 ` Qais Yousef
2020-10-21 15:39 ` Will Deacon
2020-10-21 15:39 ` Will Deacon
2020-10-21 16:21 ` Qais Yousef
2020-10-21 16:21 ` Qais Yousef
2020-10-21 16:52 ` Catalin Marinas
2020-10-21 16:52 ` Catalin Marinas
2020-10-21 17:39 ` Will Deacon
2020-10-21 17:39 ` Will Deacon
2020-10-22 9:53 ` Catalin Marinas
2020-10-22 9:53 ` Catalin Marinas
2020-10-21 10:46 ` [RFC PATCH v2 3/4] arm64: export emulate_sys_reg() Qais Yousef
2020-10-21 10:46 ` Qais Yousef
2020-10-21 10:46 ` [RFC PATCH v2 4/4] arm64: Export id_aar64fpr0 via sysfs Qais Yousef
2020-10-21 10:46 ` Qais Yousef
2020-10-21 11:09 ` Marc Zyngier
2020-10-21 11:09 ` Marc Zyngier
2020-10-21 11:25 ` Greg Kroah-Hartman
2020-10-21 11:25 ` Greg Kroah-Hartman
2020-10-21 11:46 ` Marc Zyngier
2020-10-21 11:46 ` Marc Zyngier
2020-10-21 12:11 ` Greg Kroah-Hartman
2020-10-21 12:11 ` Greg Kroah-Hartman
2020-10-21 13:18 ` Qais Yousef
2020-10-21 13:18 ` Qais Yousef
2020-10-21 12:15 ` Catalin Marinas
2020-10-21 12:15 ` Catalin Marinas
2020-10-21 13:20 ` Qais Yousef
2020-10-21 13:20 ` Qais Yousef
2020-10-21 13:33 ` Morten Rasmussen
2020-10-21 13:33 ` Morten Rasmussen
2020-10-21 14:09 ` Catalin Marinas
2020-10-21 14:09 ` Catalin Marinas
2020-10-21 14:41 ` Morten Rasmussen
2020-10-21 14:41 ` Morten Rasmussen
2020-10-21 14:45 ` Will Deacon
2020-10-21 14:45 ` Will Deacon
2020-10-21 15:10 ` Catalin Marinas
2020-10-21 15:10 ` Catalin Marinas
2020-10-21 15:37 ` Will Deacon
2020-10-21 15:37 ` Will Deacon
2020-10-21 16:18 ` Catalin Marinas
2020-10-21 16:18 ` Catalin Marinas
2020-10-21 17:19 ` Will Deacon
2020-10-21 17:19 ` Will Deacon
2020-10-22 9:55 ` Morten Rasmussen
2020-10-22 9:55 ` Morten Rasmussen
2020-10-21 14:31 ` Qais Yousef
2020-10-21 14:31 ` Qais Yousef
2020-10-22 10:16 ` Morten Rasmussen
2020-10-22 10:16 ` Morten Rasmussen
2020-10-22 10:48 ` Qais Yousef
2020-10-22 10:48 ` Qais Yousef
2020-10-21 14:41 ` Will Deacon
2020-10-21 14:41 ` Will Deacon
2020-10-21 15:03 ` Qais Yousef
2020-10-21 15:03 ` Qais Yousef
2020-10-21 15:23 ` Will Deacon
2020-10-21 15:23 ` Will Deacon
2020-10-21 16:07 ` Qais Yousef
2020-10-21 16:07 ` Qais Yousef
2020-10-21 17:23 ` Will Deacon
2020-10-21 17:23 ` Will Deacon
2020-10-21 19:57 ` Qais Yousef
2020-10-21 19:57 ` Qais Yousef
2020-10-21 20:26 ` Will Deacon
2020-10-21 20:26 ` Will Deacon
2020-10-22 8:16 ` Catalin Marinas
2020-10-22 8:16 ` Catalin Marinas
2020-10-22 9:58 ` Qais Yousef
2020-10-22 9:58 ` Qais Yousef
2020-10-22 13:47 ` Qais Yousef
2020-10-22 13:47 ` Qais Yousef
2020-10-22 13:55 ` Greg Kroah-Hartman
2020-10-22 13:55 ` Greg Kroah-Hartman
2020-10-22 14:31 ` Catalin Marinas
2020-10-22 14:31 ` Catalin Marinas
2020-10-22 14:34 ` Qais Yousef
2020-10-22 14:34 ` Qais Yousef
2020-10-26 19:02 ` Qais Yousef
2020-10-26 19:02 ` Qais Yousef
2020-10-26 19:08 ` Greg Kroah-Hartman
2020-10-26 19:08 ` Greg Kroah-Hartman
2020-10-26 19:18 ` Qais Yousef
2020-10-26 19:18 ` Qais Yousef
2020-10-21 11:28 ` Greg Kroah-Hartman
2020-10-21 11:28 ` Greg Kroah-Hartman
2020-10-21 13:22 ` Qais Yousef
2020-10-21 13:22 ` Qais Yousef
2020-10-21 11:26 ` [RFC PATCH v2 0/4] Add support for Asymmetric AArch32 systems Greg Kroah-Hartman
2020-10-21 11:26 ` Greg Kroah-Hartman
2020-10-21 13:15 ` Qais Yousef
2020-10-21 13:15 ` Qais Yousef
2020-10-21 13:31 ` Greg Kroah-Hartman
2020-10-21 13:31 ` Greg Kroah-Hartman
2020-10-21 13:55 ` Qais Yousef
2020-10-21 13:55 ` Qais Yousef
2020-10-21 14:35 ` Catalin Marinas
2020-10-21 14:35 ` Catalin Marinas
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=87587dbfb7bee53eca4d1b837fd8194a@kernel.org \
--to=maz@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=gregkh@linuxfoundation.org \
--cc=james.morse@arm.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=morten.rasmussen@arm.com \
--cc=peterz@infradead.org \
--cc=qais.yousef@arm.com \
--cc=torvalds@linux-foundation.org \
--cc=will@kernel.org \
/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.