On Fri, Jun 19, 2020 at 11:55:42AM +0200, Philippe Mathieu-Daudé wrote:
> Since commit d70c996df23f, when enabling the PMU we get:
>
> $ qemu-system-aarch64 -cpu host,pmu=on -M virt,accel=kvm,gic-version=3
> Segmentation fault (core dumped)
>
> Thread 1 "qemu-system-aar" received signal SIGSEGV, Segmentation fault.
> 0x0000aaaaaae356d0 in kvm_ioctl (s=0x0, type=44547) at
> accel/kvm/kvm-all.c:2588
> 2588 ret = ioctl(s->fd, type, arg);
> (gdb) bt
> #0 0x0000aaaaaae356d0 in kvm_ioctl (s=0x0, type=44547) at
> accel/kvm/kvm-all.c:2588
> #1 0x0000aaaaaae31568 in kvm_check_extension (s=0x0, extension=126) at
> accel/kvm/kvm-all.c:916
> #2 0x0000aaaaaafce254 in kvm_arm_pmu_supported (cpu=0xaaaaac214ab0) at
> target/arm/kvm.c:213
> #3 0x0000aaaaaafc0f94 in arm_set_pmu (obj=0xaaaaac214ab0, value=true,
> errp=0xffffffffe438) at target/arm/cpu.c:1111
> #4 0x0000aaaaab5533ac in property_set_bool (obj=0xaaaaac214ab0,
> v=0xaaaaac223a80, name=0xaaaaac11a970 "pmu", opaque=0xaaaaac222730,
> errp=0xffffffffe438) at qom/object.c:2170
> #5 0x0000aaaaab5512f0 in object_property_set (obj=0xaaaaac214ab0,
> v=0xaaaaac223a80, name=0xaaaaac11a970 "pmu", errp=0xffffffffe438) at
> qom/object.c:1328
> #6 0x0000aaaaab551e10 in object_property_parse (obj=0xaaaaac214ab0,
> string=0xaaaaac11b4c0 "on", name=0xaaaaac11a970 "pmu", errp=0xffffffffe438)
> at qom/object.c:1561
> #7 0x0000aaaaab54ee8c in object_apply_global_props (obj=0xaaaaac214ab0,
> props=0xaaaaac018e20, errp=0xaaaaabd6fd88 <error_fatal>) at qom/object.c:407
> #8 0x0000aaaaab1dd5a4 in qdev_prop_set_globals (dev=0xaaaaac214ab0) at
> hw/core/qdev-properties.c:1218
> #9 0x0000aaaaab1d9fac in device_post_init (obj=0xaaaaac214ab0) at
> hw/core/qdev.c:1050
> ...
> #15 0x0000aaaaab54f310 in object_initialize_with_type (obj=0xaaaaac214ab0,
> size=52208, type=0xaaaaabe237f0) at qom/object.c:512
> #16 0x0000aaaaab54fa24 in object_new_with_type (type=0xaaaaabe237f0) at
> qom/object.c:687
> #17 0x0000aaaaab54fa80 in object_new (typename=0xaaaaabe23970
> "host-arm-cpu") at qom/object.c:702
> #18 0x0000aaaaaaf04a74 in machvirt_init (machine=0xaaaaac0a8550) at
> hw/arm/virt.c:1770
> #19 0x0000aaaaab1e8720 in machine_run_board_init (machine=0xaaaaac0a8550)
> at hw/core/machine.c:1138
> #20 0x0000aaaaaaf95394 in qemu_init (argc=5, argv=0xffffffffea58,
> envp=0xffffffffea88) at softmmu/vl.c:4348
> #21 0x0000aaaaaada3f74 in main (argc=<optimized out>, argv=<optimized out>,
> envp=<optimized out>) at softmmu/main.c:48
>
> This is because in frame #2, cpu->kvm_state is still NULL
> (the vCPU is not yet realized).
>
> KVM has a hard requirement of all cores supporting the same
> feature set. We only need to check if the accelerator supports
> a feature, not each vCPU individually.
>
> Fix by kvm_arm_<FEATURE>_supported() functions take a AccelState
> argument (already realized/valid at this point) instead of a
> CPUState argument.
This is no longer what's being done.
>
> Reported-by: Haibo Xu <haibo...@linaro.org>
> Suggested-by: Paolo Bonzini <pbonz...@redhat.com>
> Signed-off-by: Philippe Mathieu-Daudé <phi...@redhat.com>
Fixes: d70c996df23f ("target/arm/kvm: Use CPUState::kvm_state in
kvm_arm_pmu_supported()")
Analyzed-by: Andrew Jones <drjo...@redhat.com>
> ---
> v2: Use global kvm_state (bonzini)
>
> Paolo, does this break migration of encrypted memory assumptions?
>
> Cc: Dr. David Alan Gilbert <dgilb...@redhat.com>
> Supersedes: <20200617130800.26355-1-phi...@redhat.com>
> ---
> target/arm/kvm_arm.h | 21 +++++++++------------
> target/arm/cpu.c | 2 +-
> target/arm/cpu64.c | 10 +++++-----
> target/arm/kvm.c | 4 ++--
> target/arm/kvm64.c | 14 +++++---------
> 5 files changed, 22 insertions(+), 29 deletions(-)
With the above
Reviewed-by: Andrew Jones <drjo...@redhat.com>
