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. > > Thanks, > drew >