On 17/06/2020 12.32, Philippe Mathieu-Daudé wrote: > On 6/17/20 10:23 AM, Philippe Mathieu-Daudé wrote: >> On 6/11/20 11:14 AM, Andrew Jones wrote: >>> On Thu, Jun 11, 2020 at 04:46:45PM +0800, Haibo Xu wrote: >>>> Hi, >>>> >>>> I met a qemu core dump issue when starting a VM with cpu feature >>>> "pmu=on" on an arm server. >>>> The commands to start the machine is: >>>> >>>> ./qemu-system-aarch64 \ >>>> -cpu host,pmu=on -M virt,accel=kvm,gic-version=3 -nographic >>>> -m 2048M \ >>>> -kernel ./Image \ >>>> -initrd /boot/initrd.img-5.6.0-rc2+ \ >>>> -append "root=/dev/vda rw console=ttyAMA0" -nodefaults -serial >>>> stdio\ >>>> -drive if=none,file=./xenial.rootfs.ext4,id=hd0,format=raw \ >>>> -device virtio-blk-device,drive=hd0 >>>> >>>> >>>> And here is the stack dump: >>>> >>>> Core was generated by `./qemu-system-aarch64 -cpu host,pmu=on -M >>>> virt,accel=kvm,gic-version=3 -nograph'. >>>> Program terminated with signal SIGSEGV, Segmentation fault. >>>> #0 kvm_ioctl (s=0x0, type=type@entry=44547) at >>> >>> s=0x0 means cpu->kvm_state is NULL >>> >>>> The root cause is in the arm_get_pmu() operation which was introduced >>>> in ae502508f83. >>> >>> Actually the root cause is d70c996df23f ("target/arm/kvm: Use >>> CPUState::kvm_state in kvm_arm_pmu_supported()"). ae502508f83 used >>> the machine kvm_state, not the cpu kvm_state, and that allows pmu=on >>> to work. d70c996df23f changed that saying that "KVMState is already >>> accessible via CPUState::kvm_state, use it.", but I'm not sure why, >>> since kvm_init_vcpu() doesn't run until the vcpu thread is created. >>> >>> Philippe? >> >> Sorry for some reason I missed this email. I'll look at this today. > > Quick reproducer: > > $ qemu-system-aarch64 -cpu host,pmu=on -M virt,accel=kvm,gic-version=3 > Segmentation fault (core dumped) > > Eduardo, I thought we had a 'machine' qtest testing for various > combination of properties, but I can't find it, do you remember? > Or maybe it was Thomas? Or Markus? =)
You probably remember the scripts/device-crash-test script? ... that's a) only testing -device options as far as I know, and b) is not run automatically during "make check", so it certainly is not suitable to detect these kind of errors automatically. Thomas