Re: Emulating SVE on non-SVE host with qemu-system-aarch64

[Peter Maydell]

On Tue, 7 Jan 2025 at 22:08, Mitchell Augustin
<mitchell.augustin@canonical.com> wrote:
>
> > You don't say what your command line is..
>
> Sorry, meant to include that, although I think I may have figured out
> my issue after looking through the docs more.
>
> I am trying to launch a VM with libvirt/virt-install, using the
> following options (now with sve-default-vector-length removed):
> virt-install --name ${VM} --memory $((18*1024)) --graphics
> vnc,listen=0.0.0.0 --noautoconsole \
>              --console pty,target_type=serial --vcpus 4,cpuset=0-3 \
>              --machine virt --osinfo name=ubuntunoble \
>              --cdrom /vms/ubuntu-24.04-live-server-arm64.iso \
>              --disk /vms/${VM}-vda.qcow2 --disk /vms/${VM}-seed.qcow2
> --import  --qemu-commandline="-cpu neoverse-v1"

That's not much help to me because I have no idea what stuff
virt-install is adding to the QEMU command line... Can
you give a QEMU command line?

> I forgot to mention that I also am using KVM on the host, which it
> seems is probably my issue:
>
> > If KVM is enabled then only vector lengths that the host CPU type support 
> > may be enabled. If SVE is not supported by the host, then no sve* 
> > properties may be enabled

Right, if you're using KVM then the guest gets the same CPU
that the host has, there's no way to magically give it extra
features. If you want to run an SVE-using guest program on
a non-SVE host then you must use TCG emulation (either userspace
or full-system, depending on what you want to do).

In particular, QEMU does *not* support "use the host CPU to
accelerate running the bits of guest code that don't have
feature X and then only emulate the instructions that are
part of feature X". It's either fully KVM using the host CPU,
or fully emulated.

> With the above command, I see this when trying to launch the VM:
> qemu-system-aarch64: target/arm/cpu64.c:72: arm_cpu_sve_finalize:
> Assertion `!cpu_isar_feature(aa64_sve, cpu)' failed.

We shouldn't assert here, even if you accidentally asked QEMU
to do something it can't support or that doesn't make sense.
So if you have a repro case for this (especially if it still
repros with current QEMU head-of-git) I can look at fixing it
(probably to print an error message rather than asserting).
But since this isn't going to be on the path to getting you a
working setup I understand if you'd rather just ignore it and
move on in the direction that gets you going :-)

thanks
-- PMM