Having that include breaks the build for Linux after inclusion of SME support.

Signed-off-by: Mohamed Mediouni <mohamed@unpredictable.fr>
---
 hw/arm/virt.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index cab2e21e8a..7456614d05 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -71,7 +71,6 @@
 #include "hw/intc/arm_gicv3_its_common.h"
 #include "hw/core/irq.h"
 #include "kvm_arm.h"
-#include "hvf_arm.h"
 #include "whpx_arm.h"
 #include "hw/firmware/smbios.h"
 #include "qapi/visitor.h"
-- 
2.50.1 (Apple Git-155)

On Fri, 6 Mar 2026 at 08:31, Mohamed Mediouni <mohamed@unpredictable.fr> wrote:
>
> Having that include breaks the build for Linux after inclusion of SME support.
>
> Signed-off-by: Mohamed Mediouni <mohamed@unpredictable.fr>
> ---
>  hw/arm/virt.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> index cab2e21e8a..7456614d05 100644
> --- a/hw/arm/virt.c
> +++ b/hw/arm/virt.c
> @@ -71,7 +71,6 @@
>  #include "hw/intc/arm_gicv3_its_common.h"
>  #include "hw/core/irq.h"
>  #include "kvm_arm.h"
> -#include "hvf_arm.h"
>  #include "whpx_arm.h"
>  #include "hw/firmware/smbios.h"
>  #include "qapi/visitor.h"
> --

Regardless of what we want to do about the compile failure, if
we don't need to include this header we should drop the include, so
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>

thanks
-- PMM

On Fri, 6 Mar 2026 at 08:31, Mohamed Mediouni <mohamed@unpredictable.fr> wrote:
>
> Having that include breaks the build for Linux after inclusion of SME support.
>
> Signed-off-by: Mohamed Mediouni <mohamed@unpredictable.fr>

Why does this break the Linux build? This is with Manos's two
patches "hvf/arm: handle FEAT_SME2 migration" and "hvf/arm: expose FEAT_SME2
to guest if available", right? Linux builds fine for me with those.

There doesn't seem to be anything in the hvf_arm.h header that would
be a problem on systems without hvf -- there's a couple of prototype
declarations which don't use any HVF specific types, and a block
of code protected by "#ifdef __MAC_OS_X_VERSION_MAX_ALLOWED" which
won't be defined on non-macos hosts.

thanks
-- PMM

On Fri, 6 Mar 2026 at 09:04, Peter Maydell <peter.maydell@linaro.org> wrote:
>
> On Fri, 6 Mar 2026 at 08:31, Mohamed Mediouni <mohamed@unpredictable.fr> wrote:
> >
> > Having that include breaks the build for Linux after inclusion of SME support.
> >
> > Signed-off-by: Mohamed Mediouni <mohamed@unpredictable.fr>
>
> Why does this break the Linux build? This is with Manos's two
> patches "hvf/arm: handle FEAT_SME2 migration" and "hvf/arm: expose FEAT_SME2
> to guest if available", right? Linux builds fine for me with those.
>
> There doesn't seem to be anything in the hvf_arm.h header that would
> be a problem on systems without hvf -- there's a couple of prototype
> declarations which don't use any HVF specific types, and a block
> of code protected by "#ifdef __MAC_OS_X_VERSION_MAX_ALLOWED" which
> won't be defined on non-macos hosts.

...and 5 seconds after sending this I see the include of the
hvf_sme_stubs.h header, but that seems like it's also
self-contained. So what goes wrong?

The only thing I saw that looked like it might be a portability
issue is the "ext_vector_type(64)" attribute on the hv_sme_zt0_uchar64_t
typedef. That looks like it's a clang-specific attribute, so yes,
this is a compilation problem, but it's a "fails on gcc" issue, not
a "fails on Linux" one. I happened to have done my testing of these
patches with a Linux clang build. With GCC on Linux:

In file included from ../../target/arm/hvf_arm.h:63,
                 from ../../hw/arm/virt.c:74:
../../target/arm/hvf/hvf_sme_stubs.h:35:1: error: ‘ext_vector_type’
attribute directive ignored [-Werror=attributes]
   35 | typedef __attribute__((ext_vector_type(64))) uint8_t
hv_sme_zt0_uchar64_t;
      | ^~~~~~~

Our other option for fixing this would be to either
(a) just drop the attribute -- if we're using the stubs it's because
we don't have the real type so it shouldn't matter whether we make
it match the real system typedef or not
(b) drop the attribute for not-clang, or for not-macos

thanks
-- PMM