From: Marc Zyngier <maz@kernel.org>
To: Qais Yousef <qais.yousef@arm.com>
Cc: linux-arch@vger.kernel.org,
"Peter Zijlstra \(Intel\)" <peterz@infradead.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
James Morse <james.morse@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Morten Rasmussen <morten.rasmussen@arm.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH 1/3] arm64: kvm: Handle Asymmetric AArch32 systems
Date: Tue, 13 Oct 2020 13:09:47 +0100 [thread overview]
Message-ID: <20fba6976710e00dc32164bf8af26164@kernel.org> (raw)
In-Reply-To: <20201013115953.gepxn5dbzrk6x6ec@e107158-lin>
On 2020-10-13 12:59, Qais Yousef wrote:
> On 10/13/20 12:51, James Morse wrote:
>> Hi Marc,
>>
>> On 13/10/2020 11:32, Marc Zyngier wrote:
>> > On 2020-10-12 16:32, James Morse wrote:
>> >> On 09/10/2020 13:48, Qais Yousef wrote:
>> >>> On 10/09/20 13:34, Marc Zyngier wrote:
>> >>>> You can try setting vcpu->arch.target to -1, which is already caught by
>> >>>> kvm_vcpu_initialized() right at the top of this function. This will
>> >>
>> >>>> prevent any reentry unless the VMM issues a KVM_ARM_VCPU_INIT ioctl.
>> >>
>> >> This doesn't reset SPSR, so this lets the VMM restart the guest with a
>> >> bad value.
>> >
>> > That's not my reading of the code. Without a valid target, you cannot enter
>> > the guest (kvm_vcpu_initialized() prevents you to do so). To set the target,
>> > you need to issue a KVM_ARM_VCPU_INIT ioctl, which eventually calls
>>
>> > kvm_reset_vcpu(), which does set PSTATE to something legal.
>>
>> aha! So it does, this is what I was missing.
>>
>>
>> > Or do you mean the guest's SPSR_EL1? Why would that matter?
>> >
>> >> I think we should make it impossible to return to aarch32 from EL2 on
>> >> these systems.
>> >
>> > And I'm saying that the above fulfills that requirement. Am I missing
>> > something obvious?
>>
>> Nope, I was.
>>
>> I agree the check on entry from user-space isn't needed.
>
> Thanks both.
>
> So using the vcpu->arch.target = -1 is the best way forward. In my
> experiments
> when I did that I considered calling kvm_reset_vcpu() too, does it make
> sense
> to force the reset here too? Or too heavy handed?
No, userspace should know about it and take action if it wants too.
Trying to fix it behind the scenes is setting expectations, which
I'd really like to avoid.
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-13 12:11 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-08 18:16 [RFC PATCH 0/3] Add support for Asymmetric AArch32 systems Qais Yousef
2020-10-08 18:16 ` [RFC PATCH 1/3] arm64: kvm: Handle " Qais Yousef
2020-10-09 8:12 ` Marc Zyngier
2020-10-09 9:58 ` Qais Yousef
2020-10-09 12:34 ` Marc Zyngier
2020-10-09 12:48 ` Qais Yousef
2020-10-12 15:32 ` James Morse
2020-10-13 10:32 ` Marc Zyngier
2020-10-13 11:51 ` James Morse
2020-10-13 11:59 ` Qais Yousef
2020-10-13 12:09 ` Marc Zyngier [this message]
2020-10-13 12:16 ` Qais Yousef
2020-10-08 18:16 ` [RFC PATCH 2/3] arm64: Add support for asymmetric AArch32 EL0 configurations Qais Yousef
2020-10-08 18:22 ` Randy Dunlap
2020-10-12 10:22 ` Qais Yousef
2020-10-09 6:13 ` Greg Kroah-Hartman
2020-10-09 8:40 ` Will Deacon
2020-10-09 8:50 ` Catalin Marinas
2020-10-09 9:39 ` Catalin Marinas
2020-10-12 12:46 ` Qais Yousef
2020-10-08 18:16 ` [RFC PATCH 3/3] arm64: Handle AArch32 tasks running on non AArch32 cpu Qais Yousef
2020-10-09 7:29 ` Peter Zijlstra
2020-10-09 8:13 ` Morten Rasmussen
2020-10-09 8:31 ` Will Deacon
2020-10-09 8:50 ` Morten Rasmussen
2020-10-09 9:33 ` Catalin Marinas
2020-10-09 9:42 ` Greg Kroah-Hartman
2020-10-09 11:31 ` Qais Yousef
2020-10-09 12:40 ` Catalin Marinas
2020-10-13 14:23 ` Qais Yousef
2020-10-09 9:25 ` Peter Zijlstra
2020-10-09 9:39 ` Qais Yousef
2020-10-09 9:51 ` 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=20fba6976710e00dc32164bf8af26164@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).