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


Reply via email to