kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nathan Chancellor <natechancellor@gmail.com>
To: Marc Zyngier <maz@kernel.org>
Cc: kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org,
	James Morse <james.morse@arm.com>,
	Julien Thierry <julien.thierry.kdev@gmail.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Will Deacon <will@kernel.org>,
	kernel-team@android.com,
	Nick Desaulniers <ndesaulniers@google.com>
Subject: Re: [PATCH] KVM: arm64: Prevent vcpu_has_ptrauth from generating OOL functions
Date: Thu, 23 Jul 2020 08:59:34 -0700	[thread overview]
Message-ID: <20200723155934.GA3929837@ubuntu-n2-xlarge-x86> (raw)
In-Reply-To: <0fab73670fa24d1c08711991133e4255@kernel.org>

On Thu, Jul 23, 2020 at 09:17:15AM +0100, Marc Zyngier wrote:
> Hi Nathan,
> 
> On 2020-07-23 03:51, Nathan Chancellor wrote:
> > On Wed, Jul 22, 2020 at 05:22:31PM +0100, Marc Zyngier wrote:
> > > So far, vcpu_has_ptrauth() is implemented in terms of
> > > system_supports_*_auth()
> > > calls, which are declared "inline". In some specific conditions (clang
> > > and SCS), the "inline" very much turns into an "out of line", which
> > > leads to a fireworks when this predicate is evaluated on a non-VHE
> > > system (right at the beginning of __hyp_handle_ptrauth).
> > > 
> > > Instead, make sure vcpu_has_ptrauth gets expanded inline by directly
> > > using the cpus_have_final_cap() helpers, which are __always_inline,
> > > generate much better code, and are the only thing that make sense when
> > > running at EL2 on a nVHE system.
> > > 
> > > Fixes: 29eb5a3c57f7 ("KVM: arm64: Handle PtrAuth traps early")
> > > Reported-by: Nathan Chancellor <natechancellor@gmail.com>
> > > Reported-by: Nick Desaulniers <ndesaulniers@google.com>
> > > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > 
> > Thank you for the quick fix! I have booted a mainline kernel with this
> > patch with Shadow Call Stack enabled and verified that using KVM no
> > longer causes a panic.
> 
> Great! I'll try and ferry this to mainline  as quickly as possible.

Awesome, I will keep an eye out.

> > Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
> > Tested-by: Nathan Chancellor <natechancellor@gmail.com>
> > 
> > For the future, is there an easy way to tell which type of system I am
> > using (nVHE or VHE)? I am new to the arm64 KVM world but it is something
> > that I am going to continue to test with various clang technologies now
> > that I have actual hardware capable of it that can run a mainline
> > kernel.
> 
> ARMv8.0 CPUs are only capable of running non-VHE. So if you have
> something based on older ARM CPUs (such as A57, A72, A53, A73, A35...),
> or licensee CPUs (ThunderX, XGene, EMag...), this will only run
> non-VHE (the host kernel runs at EL1, while the hypervisor runs at
> EL2.
> 
> From ARMv8.1 onward, VHE is normally present, and the host kernel
> can run at EL2 directly. ARM CPUs include A55, A65, A75, A76, A77,
> N1, while licensee CPUs include TX2, Kunpeng 920, and probably some
> more.
> 
> As pointed out by Zenghui in another email, KVM shows which mode
> it is using. Even without KVM, the kernel prints very early on:
> 
> [    0.000000] CPU features: detected: Virtualization Host Extensions
> 
> Note that this is only a performance difference, and that most
> features that are supported by the CPU can be used by KVM in either
> mode.
> 
> Thanks again,
> 
>         M.
> -- 
> Jazz is not dead. It just smells funny...

Excellent, thank you both for the in-depth explanation. Hopefully my
test farm continues to grow so I can stay on top of testing this stuff.

Cheers,
Nathan

      reply	other threads:[~2020-07-23 15:59 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-22 16:22 [PATCH] KVM: arm64: Prevent vcpu_has_ptrauth from generating OOL functions Marc Zyngier
2020-07-23  2:51 ` Nathan Chancellor
2020-07-23  3:30   ` Zenghui Yu
2020-07-23  8:17   ` Marc Zyngier
2020-07-23 15:59     ` Nathan Chancellor [this message]

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=20200723155934.GA3929837@ubuntu-n2-xlarge-x86 \
    --to=natechancellor@gmail.com \
    --cc=james.morse@arm.com \
    --cc=julien.thierry.kdev@gmail.com \
    --cc=kernel-team@android.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=maz@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=suzuki.poulose@arm.com \
    --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).