[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] xen/arm: don't read aarch32 regs when aarch32 isn't available


  • To: Stefano Stabellini <sstabellini@xxxxxxxxxx>
  • From: Bertrand Marquis <Bertrand.Marquis@xxxxxxx>
  • Date: Tue, 12 Jan 2021 10:50:28 +0000
  • Accept-language: en-GB, en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=geeL1Qau3uigoFryzk1EY9YeP0uaRoArwhEcjTgurGg=; b=Q8qXILrTuPF324dYEOYMQm8qKEIEdzaBl4on9knGDmZNOPs8l0USihQfZ2t8IGc5CQl1Ujg9tU7haYHItJLeLeaIXim6enaunP0Umj4rwfVP/IorZlmqRaV80bOV5ThzczLSFVaUXTOsUCCumrCOGFyG1rkWaIPdiKtP3pzQVN/uInaYtarOdzj3jic4qj/yvprhThxyMRtVlrdpu86J8IhYSwP2dwx8PN27EzJXTCgxY8SXoaBbrMRnQmoQM/TYx47EGCiSY20uiHH3jWnrns+qzvKFNEZE/XW5oateoJ9tuYvJr0H1DCtsNsq+OEh03u5iqo3Pe+z2gBpQ1KwQsw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Cj0NtYL1WctPJxjoMhMxjAnFjEhPkDE384WBQ81l8tR9kI50z1apEAqDwGXQwww0Jdgi1iq0GUghV8qvTuOVotBzA8GS3j97mw85SXfhGmF1GIohkIN6dxIoQP3k4BY5NeA8Dyjf3n5kHboZyJhhxGFTnvEazPXnj+042s7iRhoLa51SQOeaUz3uGWSLjP5cXPZ2u79MOUBrfrQwa6KC7fs7o8wK0lRu1N00I91S9GsgyNeQB+jao1QgUVy6HlobrO+hWvm2l+R7z648duu+l/y6D3lgqUMz3tkkB2KLM8JRMN1nPNH6FYM6ctrg/dRMVwbtv9i6yjscz4LTmoxHog==
  • Authentication-results-original: kernel.org; dkim=none (message not signed) header.d=none;kernel.org; dmarc=none action=none header.from=arm.com;
  • Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, "julien@xxxxxxx" <julien@xxxxxxx>, "Volodymyr_Babchuk@xxxxxxxx" <Volodymyr_Babchuk@xxxxxxxx>, Stefano Stabellini <stefano.stabellini@xxxxxxxxxx>
  • Delivery-date: Tue, 12 Jan 2021 10:50:46 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Nodisclaimer: true
  • Original-authentication-results: kernel.org; dkim=none (message not signed) header.d=none;kernel.org; dmarc=none action=none header.from=arm.com;
  • Thread-index: AQHW6HhLZe62+lKsX0KJMppOaCzey6oj0IcA
  • Thread-topic: [PATCH] xen/arm: don't read aarch32 regs when aarch32 isn't available

Hi Stefano,

> On 12 Jan 2021, at 00:16, Stefano Stabellini <sstabellini@xxxxxxxxxx> wrote:
> 
> Don't read aarch32 system registers at boot time when the aarch32 state
> is not available. They are UNKNOWN, so it is not useful to read them.
> Moreover, on Cavium ThunderX reading ID_PFR2_EL1 causes a Xen crash.
> Instead, only read them when aarch32 is available.
> 
> Leave the corresponding fields in struct cpuinfo_arm so that they
> are read-as-zero from a guest.

I agree with the fact that all users of identify_cpu are currently using spaces
which are 0 but to make the core a bit more robust we could do a memset(0)
of the structure at the beginning of the function.

> 
> Since we are editing identify_cpu, also fix the indentation: 4 spaces
> instead of 8.
> 
> Fixes: 9cfdb489af81 ("xen/arm: Add ID registers and complete cpuinfo")
> Link: https://marc.info/?l=xen-devel&m=161035501118086
> Link: 
> http://logs.test-lab.xenproject.org/osstest/logs/158293/test-arm64-arm64-xl-xsm/info.html
> Suggested-by: Julien Grall <julien@xxxxxxx>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxx>
> ---
> xen/arch/arm/cpufeature.c | 35 +++++++++++++++++++++--------------
> 1 file changed, 21 insertions(+), 14 deletions(-)
> 
> diff --git a/xen/arch/arm/cpufeature.c b/xen/arch/arm/cpufeature.c
> index 698bfa0201..b1c82ade49 100644
> --- a/xen/arch/arm/cpufeature.c
> +++ b/xen/arch/arm/cpufeature.c
> @@ -101,29 +101,35 @@ int enable_nonboot_cpu_caps(const struct 
> arm_cpu_capabilities *caps)
> 
> void identify_cpu(struct cpuinfo_arm *c)
> {
> -        c->midr.bits = READ_SYSREG(MIDR_EL1);
> -        c->mpidr.bits = READ_SYSREG(MPIDR_EL1);
> +    bool aarch32 = true;
> +
> +    c->midr.bits = READ_SYSREG(MIDR_EL1);
> +    c->mpidr.bits = READ_SYSREG(MPIDR_EL1);
> 
> #ifdef CONFIG_ARM_64
> -        c->pfr64.bits[0] = READ_SYSREG(ID_AA64PFR0_EL1);
> -        c->pfr64.bits[1] = READ_SYSREG(ID_AA64PFR1_EL1);
> +    c->pfr64.bits[0] = READ_SYSREG(ID_AA64PFR0_EL1);
> +    c->pfr64.bits[1] = READ_SYSREG(ID_AA64PFR1_EL1);
> +
> +    c->dbg64.bits[0] = READ_SYSREG(ID_AA64DFR0_EL1);
> +    c->dbg64.bits[1] = READ_SYSREG(ID_AA64DFR1_EL1);
> 
> -        c->dbg64.bits[0] = READ_SYSREG(ID_AA64DFR0_EL1);
> -        c->dbg64.bits[1] = READ_SYSREG(ID_AA64DFR1_EL1);
> +    c->aux64.bits[0] = READ_SYSREG(ID_AA64AFR0_EL1);
> +    c->aux64.bits[1] = READ_SYSREG(ID_AA64AFR1_EL1);
> 
> -        c->aux64.bits[0] = READ_SYSREG(ID_AA64AFR0_EL1);
> -        c->aux64.bits[1] = READ_SYSREG(ID_AA64AFR1_EL1);
> +    c->mm64.bits[0]  = READ_SYSREG(ID_AA64MMFR0_EL1);
> +    c->mm64.bits[1]  = READ_SYSREG(ID_AA64MMFR1_EL1);
> +    c->mm64.bits[2]  = READ_SYSREG(ID_AA64MMFR2_EL1);
> 
> -        c->mm64.bits[0]  = READ_SYSREG(ID_AA64MMFR0_EL1);
> -        c->mm64.bits[1]  = READ_SYSREG(ID_AA64MMFR1_EL1);
> -        c->mm64.bits[2]  = READ_SYSREG(ID_AA64MMFR2_EL1);
> +    c->isa64.bits[0] = READ_SYSREG(ID_AA64ISAR0_EL1);
> +    c->isa64.bits[1] = READ_SYSREG(ID_AA64ISAR1_EL1);
> 
> -        c->isa64.bits[0] = READ_SYSREG(ID_AA64ISAR0_EL1);
> -        c->isa64.bits[1] = READ_SYSREG(ID_AA64ISAR1_EL1);
> +    c->zfr64.bits[0] = READ_SYSREG(ID_AA64ZFR0_EL1);
> 
> -        c->zfr64.bits[0] = READ_SYSREG(ID_AA64ZFR0_EL1);
> +    aarch32 = c->pfr64.el1 == 2;

I would put some () around the test.

> #endif
> 
> +    if ( aarch32 )
> +    {
>         c->pfr32.bits[0] = READ_SYSREG(ID_PFR0_EL1);
>         c->pfr32.bits[1] = READ_SYSREG(ID_PFR1_EL1);
>         c->pfr32.bits[2] = READ_SYSREG(ID_PFR2_EL1);
> @@ -153,6 +159,7 @@ void identify_cpu(struct cpuinfo_arm *c)
> #ifndef MVFR2_MAYBE_UNDEFINED
>         c->mvfr.bits[2] = READ_SYSREG(MVFR2_EL1);
> #endif

If we test for aarch32, the ifndef here should not be needed anymore.

Is your previous patch really still needed if we go with the aarch32 path ?

Cheers
Bertrand

> +    }
> }
> 
> /*
> -- 
> 2.17.1
> 




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.