From: Stefano Stabellini <sstabellini@kernel.org>
To: Bertrand Marquis <bertrand.marquis@arm.com>
Cc: xen-devel@lists.xenproject.org,
Stefano Stabellini <sstabellini@kernel.org>,
Julien Grall <julien@xen.org>,
Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Subject: Re: [PATCH v2 3/7] xen/arm: create a cpuinfo structure for guest
Date: Fri, 4 Dec 2020 15:57:36 -0800 (PST) [thread overview]
Message-ID: <alpine.DEB.2.21.2012041531420.32240@sstabellini-ThinkPad-T480s> (raw)
In-Reply-To: <539cc9c817a80e35a2532dba5bc01e9b2533ff56.1606742184.git.bertrand.marquis@arm.com>
On Mon, 30 Nov 2020, Bertrand Marquis wrote:
> Create a cpuinfo structure for guest and mask into it the features that
> we do not support in Xen or that we do not want to publish to guests.
>
> Modify some values in the cpuinfo structure for guests to mask some
> features which we do not want to allow to guests (like AMU) or we do not
> support (like SVE).
The first two sentences seem to say the same thing in two different
ways.
> The code is trying to group together registers modifications for the
> same feature to be able in the long term to easily enable/disable a
> feature depending on user parameters or add other registers modification
> in the same place (like enabling/disabling HCR bits).
>
> Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
> ---
> Changes in V2: rebase
> ---
> xen/arch/arm/cpufeature.c | 51 ++++++++++++++++++++++++++++++++
> xen/include/asm-arm/cpufeature.h | 2 ++
> 2 files changed, 53 insertions(+)
>
> diff --git a/xen/arch/arm/cpufeature.c b/xen/arch/arm/cpufeature.c
> index 204be9b084..309941ff37 100644
> --- a/xen/arch/arm/cpufeature.c
> +++ b/xen/arch/arm/cpufeature.c
> @@ -24,6 +24,8 @@
>
> DECLARE_BITMAP(cpu_hwcaps, ARM_NCAPS);
>
> +struct cpuinfo_arm __read_mostly guest_cpuinfo;
> +
> void update_cpu_capabilities(const struct arm_cpu_capabilities *caps,
> const char *info)
> {
> @@ -156,6 +158,55 @@ void identify_cpu(struct cpuinfo_arm *c)
> #endif
> }
>
> +/*
> + * This function is creating a cpuinfo structure with values modified to mask
> + * all cpu features that should not be published to guest.
> + * The created structure is then used to provide ID registers values to guests.
> + */
> +static int __init create_guest_cpuinfo(void)
> +{
> + /*
> + * TODO: The code is currently using only the features detected on the boot
> + * core. In the long term we should try to compute values containing only
> + * features supported by all cores.
> + */
> + identify_cpu(&guest_cpuinfo);
Given that we already have boot_cpu_data and current_cpu_data, which
should be already initialized at this point, we could simply:
guest_cpuinfo = current_cpu_data;
or
guest_cpuinfo = boot_cpu_data;
?
> +#ifdef CONFIG_ARM_64
> + /* Disable MPAM as xen does not support it */
> + guest_cpuinfo.pfr64.mpam = 0;
> + guest_cpuinfo.pfr64.mpam_frac = 0;
> +
> + /* Disable SVE as Xen does not support it */
> + guest_cpuinfo.pfr64.sve = 0;
> + guest_cpuinfo.zfr64.bits[0] = 0;
> +
> + /* Disable MTE as Xen does not support it */
> + guest_cpuinfo.pfr64.mte = 0;
> +#endif
> +
> + /* Disable AMU */
> +#ifdef CONFIG_ARM_64
> + guest_cpuinfo.pfr64.amu = 0;
> +#endif
> + guest_cpuinfo.pfr32.amu = 0;
> +
> + /* Disable RAS as Xen does not support it */
> +#ifdef CONFIG_ARM_64
> + guest_cpuinfo.pfr64.ras = 0;
> + guest_cpuinfo.pfr64.ras_frac = 0;
> +#endif
> + guest_cpuinfo.pfr32.ras = 0;
> + guest_cpuinfo.pfr32.ras_frac = 0;
> +
> + return 0;
> +}
> +/*
> + * This function needs to be run after all smp are started to have
> + * cpuinfo structures for all cores.
> + */
> +__initcall(create_guest_cpuinfo);
> +
> /*
> * Local variables:
> * mode: C
> diff --git a/xen/include/asm-arm/cpufeature.h b/xen/include/asm-arm/cpufeature.h
> index 64354c3f19..0ab6dd42a0 100644
> --- a/xen/include/asm-arm/cpufeature.h
> +++ b/xen/include/asm-arm/cpufeature.h
> @@ -290,6 +290,8 @@ extern void identify_cpu(struct cpuinfo_arm *);
> extern struct cpuinfo_arm cpu_data[];
> #define current_cpu_data cpu_data[smp_processor_id()]
>
> +extern struct cpuinfo_arm guest_cpuinfo;
> +
> #endif /* __ASSEMBLY__ */
>
> #endif
> --
> 2.17.1
>
next prev parent reply other threads:[~2020-12-04 23:57 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-30 14:21 [PATCH v2 0/7] xen/arm: Emulate ID registers Bertrand Marquis
2020-11-30 14:21 ` [PATCH v2 1/7] xen/arm: Add ID registers and complete cpufinfo Bertrand Marquis
2020-11-30 19:55 ` Volodymyr Babchuk
2020-12-04 23:52 ` Stefano Stabellini
2020-12-07 17:35 ` Bertrand Marquis
2020-11-30 14:21 ` [PATCH v2 2/7] xen/arm: Add arm64 ID registers definitions Bertrand Marquis
2020-11-30 20:08 ` Volodymyr Babchuk
2020-12-04 23:54 ` Stefano Stabellini
2020-11-30 14:21 ` [PATCH v2 3/7] xen/arm: create a cpuinfo structure for guest Bertrand Marquis
2020-11-30 20:15 ` Volodymyr Babchuk
2020-12-01 11:41 ` Bertrand Marquis
2020-12-04 23:57 ` Stefano Stabellini [this message]
2020-12-07 17:24 ` Bertrand Marquis
2020-11-30 14:21 ` [PATCH v2 4/7] xen/arm: Add handler for ID registers on arm64 Bertrand Marquis
2020-11-30 20:22 ` Volodymyr Babchuk
2020-12-01 11:42 ` Bertrand Marquis
2020-12-01 11:54 ` Volodymyr Babchuk
2020-12-05 0:19 ` Stefano Stabellini
2020-11-30 14:21 ` [PATCH v2 5/7] xen/arm: Add handler for cp15 ID registers Bertrand Marquis
2020-11-30 20:31 ` Volodymyr Babchuk
2020-12-01 11:46 ` Bertrand Marquis
2020-12-01 12:07 ` Volodymyr Babchuk
2020-12-01 14:21 ` Bertrand Marquis
2020-12-01 16:54 ` Volodymyr Babchuk
2020-12-02 11:12 ` Bertrand Marquis
2020-12-02 11:57 ` Bertrand Marquis
2020-12-05 0:36 ` Stefano Stabellini
2020-11-30 14:21 ` [PATCH v2 6/7] xen/arm: Add CP10 exception support to handle VMFR Bertrand Marquis
2020-11-30 20:39 ` Volodymyr Babchuk
2020-12-01 14:04 ` Bertrand Marquis
2020-11-30 14:21 ` [PATCH v2 7/7] xen/arm: Activate TID3 in HCR_EL2 Bertrand Marquis
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=alpine.DEB.2.21.2012041531420.32240@sstabellini-ThinkPad-T480s \
--to=sstabellini@kernel.org \
--cc=Volodymyr_Babchuk@epam.com \
--cc=bertrand.marquis@arm.com \
--cc=julien@xen.org \
--cc=xen-devel@lists.xenproject.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).