Hi Julien, > On 24 May 2023, at 11:58, Julien Grall <jul...@xen.org> wrote: > > Hi, > > On 24/05/2023 10:01, Bertrand Marquis wrote: >>> diff --git a/xen/arch/arm/cpufeature.c b/xen/arch/arm/cpufeature.c >>> index c4ec38bb2554..83b84368f6d5 100644 >>> --- a/xen/arch/arm/cpufeature.c >>> +++ b/xen/arch/arm/cpufeature.c >>> @@ -9,6 +9,7 @@ >>> #include <xen/init.h> >>> #include <xen/smp.h> >>> #include <xen/stop_machine.h> >>> +#include <asm/arm64/sve.h> >>> #include <asm/cpufeature.h> >>> >>> DECLARE_BITMAP(cpu_hwcaps, ARM_NCAPS); >>> @@ -143,6 +144,9 @@ void identify_cpu(struct cpuinfo_arm *c) >>> >>> c->zfr64.bits[0] = READ_SYSREG(ID_AA64ZFR0_EL1); >>> >>> + if ( cpu_has_sve ) >>> + c->zcr64.bits[0] = compute_max_zcr(); >>> + >>> c->dczid.bits[0] = READ_SYSREG(DCZID_EL0); >>> >>> c->ctr.bits[0] = READ_SYSREG(CTR_EL0); >>> @@ -199,7 +203,7 @@ static int __init create_guest_cpuinfo(void) >>> guest_cpuinfo.pfr64.mpam = 0; >>> guest_cpuinfo.pfr64.mpam_frac = 0; >>> >>> - /* Hide SVE as Xen does not support it */ >>> + /* Hide SVE by default to the guests */ >> Everything is for guests and as Jan mentioned in an other comment >> this could be wrongly interpreted. > > (Not directly related to this patch, so no changes expected here) > > Hmmm... The name of the function/variable is confusing as well given that the > cpuinfo should also apply to dom0. Should we s/guest/domain/?
Would make sense to do some kind of coherency check here to use domain whenever something is for dom0 or guest. So yes that would be a good idea and I can add this to my todolist (after SVE is merged to prevent conflicts). Cheers Bertrand > > Cheers, > > -- > Julien Grall