On 6/19/20 12:23 PM, Andrew Jones wrote:
> 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.
:S
>
>>
>> Reported-by: Haibo Xu <haibo.xu@xxxxxxxxxx>
>> Suggested-by: Paolo Bonzini <pbonzini@xxxxxxxxxx>
>> Signed-off-by: Philippe Mathieu-Daudé <philmd@xxxxxxxxxx>
>
> Fixes: d70c996df23f ("target/arm/kvm: Use CPUState::kvm_state in
> kvm_arm_pmu_supported()")
> Analyzed-by: Andrew Jones <drjones@xxxxxxxxxx>
Not sure this tag passes checkpatch.pl, else I'll replace by
a 'Reported-by'.
>
>> ---
>> v2: Use global kvm_state (bonzini)
>>
>> Paolo, does this break migration of encrypted memory assumptions?
>>
>> Cc: Dr. David Alan Gilbert <dgilbert@xxxxxxxxxx>
>> Supersedes: <20200617130800.26355-1-philmd@xxxxxxxxxx>
>> ---
>> 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 <drjones@xxxxxxxxxx>
Thanks, I'll wait Paolo/Dave review before respinning.
Regards,
Phil.
