> On 6. Mar 2026, at 11:05, Manos Pitsidianakis
> <[email protected]> wrote:
>
> On Fri, Mar 6, 2026 at 11:48 AM Peter Maydell <[email protected]>
> wrote:
>>
>> On Fri, 6 Mar 2026 at 09:31, Manos Pitsidianakis
>> <[email protected]> wrote:
>>>
>>> On Fri, Mar 6, 2026 at 11:19 AM Peter Maydell <[email protected]>
>>> wrote:
>>>> Mohamed points out that this breaks the build when compiling
>>>> with GCC (which I hadn't noticed because I happen to do my testing
>>>> of target-arm with clang on Linux these days):
>>>
>>> Oops. same here, I was using clang.
>>
>>>> typedef uint8_t hv_sme_zt0_uchar64_t;
>>>>
>>>> Could somebody confirm that that works OK on the relevant macos
>>>> configurations ?
>>>
>>> I think this works. Do you want me to send a new revision?
>>
>> If you can test it for the macos configs I can just make the change
>> locally. I have:
>
> Tested it with gcc on linux and on macos, thanks.
>
>> +/*
>> + * The system version of this type declares it with
>> + * __attribute__((ext_vector_type(64)))
>> + * However, that is clang specific and not supported by GCC.
>> + * Since these headers are only here for the case where the system
>> + * headers do not provide these types (including both older macos
>> + * and non-macos hosts), we don't need to make the type match
>> + * exactly, so we declare it as a plain uint8_t.
>> + */
>> +typedef uint8_t hv_sme_zt0_uchar64_t;
>
>
>>
>> While you're retesting, could you also look at / test patches
>> 17 and 18 in Mohamed's series
>> https://lore.kernel.org/qemu-devel/[email protected]/T/#m2d1e3dfbfa5aecd41af6c0aa9e3b574a72c6f04d
>>
>> ?
>>
>> They look to me like bugfixes that we should be squashing/including
>> in the "enable SME2 for hvf" handling.
>
> Had a quick look, 17 seems to be nested-virt specific so not a bugfix
> if nested-virt was not already supported in the first place, right?
Hello,
This part isn’t:
@@ -1370,16 +1373,22 @@ int hvf_arch_init_vcpu(CPUState *cpu)
arm_cpu->cpreg_indexes[sregs_cnt++] = kvm_id;
}
}
- if (__builtin_available(macOS 15.2, *)) {
- for (i = 0; i < ARRAY_SIZE(hvf_sreg_list_sme2); i++) {
- hv_sys_reg_t hvf_id = hvf_sreg_list_sme2[i].sreg;
- uint64_t kvm_id = HVF_TO_KVMID(hvf_id);
- uint32_t key = kvm_to_cpreg_id(kvm_id);
- const ARMCPRegInfo *ri = get_arm_cp_reginfo(arm_cpu->cp_regs, key);
-
- if (ri) {
- assert(!(ri->type & ARM_CP_NO_RAW));
- arm_cpu->cpreg_indexes[sregs_cnt++] = kvm_id;
+ if (hvf_arm_sme2_supported()) {
+ /*
+ * Clang doesn't allow us to combine the two checks together.
+ * -Wunsupported-availability-guard
+ */
+ if (__builtin_available(macOS 15.2, *)) {
+ for (i = 0; i < ARRAY_SIZE(hvf_sreg_list_sme2); i++) {
+ hv_sys_reg_t hvf_id = hvf_sreg_list_sme2[i].sreg;
+ uint64_t kvm_id = HVF_TO_KVMID(hvf_id);
+ uint32_t key = kvm_to_cpreg_id(kvm_id);
+ const ARMCPRegInfo *ri = get_arm_cp_reginfo(arm_cpu->cp_regs, key);
+
+ if (ri) {
+ assert(!(ri->type & ARM_CP_NO_RAW));
+ arm_cpu->cpreg_indexes[sregs_cnt++] = kvm_id;
+ }
}
}
/*
For CPUs that don’t have SME
But the remainder of the patch is. Probably worth it to just merge it all as
part of the nested virt stuff though...
>
> As for 18: I'm not sure why this is needed (I'm not that familiar with
> HVF API) and there's no commit message to explain. @Mohamed Mediouni
> can you help?
We have this in sysreg.c.inc:
DEF_SYSREG_15_02(HV_SYS_REG_SMCR_EL1, 3, 0, 1, 2, 6)
DEF_SYSREG_15_02(HV_SYS_REG_SMPRI_EL1, 3, 0, 1, 2, 4)
DEF_SYSREG_15_02(HV_SYS_REG_TPIDR2_EL0, 3, 3, 13, 0, 5)
DEF_SYSREG_15_02(HV_SYS_REG_ID_AA64ZFR0_EL1, 3, 0, 0, 4, 4)
DEF_SYSREG_15_02(HV_SYS_REG_ID_AA64SMFR0_EL1, 3, 0, 0, 4, 5)
DEF_SYSREG_15_02(HV_SYS_REG_SMPRI_EL1, 3, 0, 1, 2, 4)
DEF_SYSREG_15_02(HV_SYS_REG_SMCR_EL1, 3, 0, 1, 2, 6)
which means that actual sysreg state gets synced from the QEMU view including
for the ID_AA64SMFR0_EL1 and ID_AA64ZFR0_EL1 feature registers.
See /proc/cpuinfo from a Linux guest with and without the patch,
without it the QEMU view of those ID regs is empty… and that empty view
gets synced in to the vCPU state.
Thank you,
-Mohamed
>>
>> thanks
>> -- PMM
>
> --
> Manos Pitsidianakis
> Emulation and Virtualization Engineer at Linaro Ltd
>
