All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>,
	rnayak@codeaurora.org, suzuki.poulose@arm.com,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	jeremy.linton@arm.com, bjorn.andersson@linaro.org,
	linux-arm-msm@vger.kernel.org, andrew.murray@arm.com,
	will@kernel.org, Dave.Martin@arm.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: Relax CPU features sanity checking on heterogeneous architectures
Date: Fri, 11 Oct 2019 14:33:43 +0100	[thread overview]
Message-ID: <20191011143343.541da66c@why> (raw)
In-Reply-To: <20191011105010.GA29364@lakrids.cambridge.arm.com>

On Fri, 11 Oct 2019 11:50:11 +0100
Mark Rutland <mark.rutland@arm.com> wrote:

> Hi,
> 
> On Fri, Oct 11, 2019 at 11:19:00AM +0530, Sai Prakash Ranjan wrote:
> > On latest QCOM SoCs like SM8150 and SC7180 with big.LITTLE arch, below
> > warnings are observed during bootup of big cpu cores.  
> 
> For reference, which CPUs are in those SoCs?
> 
> > SM8150:
> > 
> > [    0.271177] CPU features: SANITY CHECK: Unexpected variation in
> > SYS_ID_AA64PFR0_EL1. Boot CPU: 0x00000011112222, CPU4: 0x00000011111112  
> 
> The differing fields are EL3, EL2, and EL1: the boot CPU supports
> AArch64 and AArch32 at those exception levels, while the secondary only
> supports AArch64.
> 
> Do we handle this variation in KVM?

We do, at least at vcpu creation time (see kvm_reset_vcpu). But if one
of the !AArch32 CPU comes in late in the game (after we've started a
guest), all bets are off (we'll schedule the 32bit guest on that CPU,
enter the guest, immediately take an Illegal Exception Return, and
return to userspace with KVM_EXIT_FAIL_ENTRY).

Not sure we could do better, given the HW. My preference would be to
fail these CPUs if they aren't present at boot time.

	M.
-- 
Jazz is not dead. It just smells funny...

WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>,
	rnayak@codeaurora.org, suzuki.poulose@arm.com,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	jeremy.linton@arm.com, bjorn.andersson@linaro.org,
	linux-arm-msm@vger.kernel.org, andrew.murray@arm.com,
	will@kernel.org, Dave.Martin@arm.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: Relax CPU features sanity checking on heterogeneous architectures
Date: Fri, 11 Oct 2019 14:33:43 +0100	[thread overview]
Message-ID: <20191011143343.541da66c@why> (raw)
In-Reply-To: <20191011105010.GA29364@lakrids.cambridge.arm.com>

On Fri, 11 Oct 2019 11:50:11 +0100
Mark Rutland <mark.rutland@arm.com> wrote:

> Hi,
> 
> On Fri, Oct 11, 2019 at 11:19:00AM +0530, Sai Prakash Ranjan wrote:
> > On latest QCOM SoCs like SM8150 and SC7180 with big.LITTLE arch, below
> > warnings are observed during bootup of big cpu cores.  
> 
> For reference, which CPUs are in those SoCs?
> 
> > SM8150:
> > 
> > [    0.271177] CPU features: SANITY CHECK: Unexpected variation in
> > SYS_ID_AA64PFR0_EL1. Boot CPU: 0x00000011112222, CPU4: 0x00000011111112  
> 
> The differing fields are EL3, EL2, and EL1: the boot CPU supports
> AArch64 and AArch32 at those exception levels, while the secondary only
> supports AArch64.
> 
> Do we handle this variation in KVM?

We do, at least at vcpu creation time (see kvm_reset_vcpu). But if one
of the !AArch32 CPU comes in late in the game (after we've started a
guest), all bets are off (we'll schedule the 32bit guest on that CPU,
enter the guest, immediately take an Illegal Exception Return, and
return to userspace with KVM_EXIT_FAIL_ENTRY).

Not sure we could do better, given the HW. My preference would be to
fail these CPUs if they aren't present at boot time.

	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

  parent reply	other threads:[~2019-10-11 13:33 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-11  5:49 Relax CPU features sanity checking on heterogeneous architectures Sai Prakash Ranjan
2019-10-11  5:49 ` Sai Prakash Ranjan
2019-10-11  9:19 ` Marc Gonzalez
2019-10-11  9:19   ` Marc Gonzalez
2019-10-11  9:57   ` Sai Prakash Ranjan
2019-10-11  9:57     ` Sai Prakash Ranjan
2019-10-11 10:50 ` Mark Rutland
2019-10-11 10:50   ` Mark Rutland
2019-10-11 11:09   ` Marc Gonzalez
2019-10-11 11:09     ` Marc Gonzalez
2019-10-11 13:33     ` Sai Prakash Ranjan
2019-10-11 13:33       ` Sai Prakash Ranjan
2019-10-11 13:17   ` Sai Prakash Ranjan
2019-10-11 13:17     ` Sai Prakash Ranjan
2019-10-11 13:34     ` Marc Zyngier
2019-10-11 13:34       ` Marc Zyngier
2019-10-11 13:40       ` Sai Prakash Ranjan
2019-10-11 13:40         ` Sai Prakash Ranjan
2019-10-17 20:00         ` Stephen Boyd
2019-10-17 20:00           ` Stephen Boyd
2019-10-18  7:20           ` Marc Zyngier
2019-10-18  7:20             ` Marc Zyngier
2019-10-18 14:33             ` Stephen Boyd
2019-10-18 14:33               ` Stephen Boyd
2019-10-18 16:40               ` Marc Zyngier
2019-10-18 16:40                 ` Marc Zyngier
2019-10-18 10:18           ` Sai Prakash Ranjan
2019-10-18 10:18             ` Sai Prakash Ranjan
2019-10-11 13:33   ` Marc Zyngier [this message]
2019-10-11 13:33     ` Marc Zyngier
2019-10-11 13:54     ` Mark Rutland
2019-10-11 13:54       ` Mark Rutland
2019-10-11 14:06       ` Marc Zyngier
2019-10-11 14:06         ` Marc Zyngier
2019-10-17 21:39       ` Jeremy Linton
2019-10-17 21:39         ` Jeremy Linton
2019-10-18  9:01         ` Catalin Marinas
2019-10-18  9:01           ` Catalin Marinas
2020-01-20  2:47       ` Sai Prakash Ranjan
2020-01-20  2:47         ` Sai Prakash Ranjan

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=20191011143343.541da66c@why \
    --to=maz@kernel.org \
    --cc=Dave.Martin@arm.com \
    --cc=andrew.murray@arm.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=catalin.marinas@arm.com \
    --cc=jeremy.linton@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=rnayak@codeaurora.org \
    --cc=saiprakash.ranjan@codeaurora.org \
    --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 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.