On Fri, Mar 6, 2026 at 11:19 AM Peter Maydell <[email protected]> wrote:
>
> On Tue, 3 Mar 2026 at 07:42, Manos Pitsidianakis
> <[email protected]> wrote:
> >
> > SME2 support adds the following state for HVF guests:
> >
> > - Vector registers Z0, ... , Z31 (introduced by FEAT_SVE but HVF does
> >   not support it)
> > - Predicate registers P0, .., P15 (also FEAT_SVE)
> > - ZA register
> > - ZT0 register
> > - PSTATE.{SM,ZA} bits (SVCR pseudo-register)
> > - SMPRI_EL1 which handles the PE's priority in the SMCU
> > - TPIDR2_EL0 the thread local ID register for SME
>
> 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.


>
> > --- /dev/null
> > +++ b/target/arm/hvf/hvf_sme_stubs.h
> > @@ -0,0 +1,158 @@
> > +/* SPDX-License-Identifier: GPL-2.0-or-later */
> > +
> > +typedef int32_t hv_return_t;
> > +typedef uint64_t hv_vcpu_t;
>
>
> > +typedef __attribute__((ext_vector_type(64))) uint8_t hv_sme_zt0_uchar64_t;
>
> The "ext_vector_type()" attribute is clang specific and gcc
> doesn't recognize it.
>
> Since we're defining all these types specifically because the system
> headers are not providing them and only for the prototypes, my
> preference would be to simply drop the attribute from this
> declaration:
>
> 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?

>
> thanks
> -- PMM

-- 
Manos Pitsidianakis
Emulation and Virtualization Engineer at Linaro Ltd

Reply via email to