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? 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? > > thanks > -- PMM -- Manos Pitsidianakis Emulation and Virtualization Engineer at Linaro Ltd
