Bug 1974620

Hit this issue on my test.
Host env:
Kernel-5.13.0-0.rc4.33.el9.x86_64
qemu-kvm-6.0.0-5.el9.x86_64

Guest env:
kernel-5.13.0-0.rc4.33.el9.x86_64

Steps to Reproduce:
1.boot up guest with pvpanic device
/usr/libexec/qemu-kvm \
-name 'avocado-vt-vm1'  \
-sandbox on  \
-machine q35,memory-backend=mem-machine_mem \
-device pcie-root-port,id=pcie-root-port-0,multifunction=on,bus=pcie.0,addr=0x1,chassis=1 \
-device pcie-pci-bridge,id=pcie-pci-bridge-0,addr=0x0,bus=pcie-root-port-0  \
-nodefaults \
-device VGA,bus=pcie.0,addr=0x2 \
-m 14336 \
-object memory-backend-ram,size=14336M,id=mem-machine_mem  \
-smp 24,maxcpus=24,cores=12,threads=1,dies=1,sockets=2  \
-cpu 'Skylake-Server',+kvm_pv_unhalt \
-chardev socket,id=qmp_id_qmp1,server=on,wait=off,path=/tmp/avocado_jrcpkvev/monitor-qmp1-20210622-030919-vu7naQQm  \
-mon chardev=qmp_id_qmp1,mode=control \
-chardev socket,id=qmp_id_catch_monitor,server=on,wait=off,path=/tmp/avocado_jrcpkvev/monitor-catch_monitor-20210622-030919-vu7naQQm  \
-mon chardev=qmp_id_catch_monitor,mode=control \
-device pvpanic,ioport=0x505,id=idUEPpR9 \
-chardev socket,id=chardev_serial0,server=on,wait=off,path=/tmp/avocado_jrcpkvev/serial-serial0-20210622-030919-vu7naQQm \
-device isa-serial,id=serial0,chardev=chardev_serial0  \
-chardev socket,id=seabioslog_id_20210622-030919-vu7naQQm,path=/tmp/avocado_jrcpkvev/seabios-20210622-030919-vu7naQQm,server=on,wait=off \
-device isa-debugcon,chardev=seabioslog_id_20210622-030919-vu7naQQm,iobase=0x402 \
-device pcie-root-port,id=pcie-root-port-1,port=0x1,addr=0x1.0x1,bus=pcie.0,chassis=2 \
-device qemu-xhci,id=usb1,bus=pcie-root-port-1,addr=0x0 \
-device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1 \
-device pcie-root-port,id=pcie-root-port-2,port=0x2,addr=0x1.0x2,bus=pcie.0,chassis=3 \
-device virtio-scsi-pci,id=virtio_scsi_pci0,bus=pcie-root-port-2,addr=0x0 \
-blockdev node-name=file_image1,driver=file,auto-read-only=on,discard=unmap,aio=threads,filename=/home/kvm_autotest_root/images/rhel900-64-virtio-scsi.qcow2,cache.direct=on,cache.no-flush=off \
-blockdev node-name=drive_image1,driver=qcow2,read-only=off,cache.direct=on,cache.no-flush=off,file=file_image1 \
-device scsi-hd,id=image1,drive=drive_image1,write-cache=on \
-device pcie-root-port,id=pcie-root-port-3,port=0x3,addr=0x1.0x3,bus=pcie.0,chassis=4 \
-device virtio-net-pci,mac=9a:b9:ed:eb:a6:12,id=ides6ztL,netdev=idC13vK7,bus=pcie-root-port-3,addr=0x0  \
-netdev tap,id=idC13vK7,vhost=on  \
-qmp tcp:127.0.0.1:4445,server,nowait \
-monitor stdio \
-vnc :0  \
-rtc base=utc,clock=host,driftfix=slew  \
-boot menu=off,order=cdn,once=c,strict=off \
-enable-kvm \
-no-shutdown \
-device pcie-root-port,id=pcie_extra_root_port_0,multifunction=on,bus=pcie.0,addr=0x3,chassis=5

2.stop kdump service
3.trigger crash in guest
4.check QMP output.

Actual results:
No output in QMP

Expected results:
{"timestamp": {"seconds": 1624347802, "microseconds": 978480}, "event": "GUEST_PANICKED", "data": {"action": "pause"}}

Alse try this case with different kernel version in guest.
kernel-5.13.0-0.rc3.25.el9.x86_64  cannot get the correct event in QMP
kernel-5.13.0-0.rc2.19.el9.x86_64  cannot get the correct event in QMP
kernel-5.12.0-1.el9.x86_64         it works well

So this problem may appear from version 'kernel-5.13.0-0.rc2.19.el9.x86_64'

Assigned to Amnon for initial triage per bz process and age of bug created or assigned to virt-maint without triage.

I tested this case with latest rhel9 compose, seems this issue has been fixed.
Env:
kernel-5.13.0-0.rc7.51.el9.x86_64
qemu-kvm-6.0.0-7.el9.x86_64
Guest:
kernel-5.13.0-0.rc7.51.el9.x86_64

Test steps is same as comment1

QMP output:
{"execute":"qmp_capabilities"}
{"return": {}}
{"timestamp": {"seconds": 1625823106, "microseconds": 327872}, "event": "GUEST_PANICKED", "data": {"action": "pause"}}
{"timestamp": {"seconds": 1625823106, "microseconds": 385322}, "event": "STOP"}
{"execute":"query-status"}
{"return": {"status": "guest-panicked", "singlestep": false, "running": false}}

I noticed that the pvpanic device has a new parameter "event". I did not set this option in the qemu command, 
but this parameter is added by default to the pvpanic device (events=3). Could someone explain what this parameter does? Thanks a lot.

(qemu) info qtree
          dev: pvpanic, id "idUEPpR9"
            ioport = 1285 (0x505)
            events = 3 (0x3)

(In reply to leidwang from comment #4)
> I tested this case with latest rhel9 compose, seems this issue has been
> fixed.
> Env:
> kernel-5.13.0-0.rc7.51.el9.x86_64
> qemu-kvm-6.0.0-7.el9.x86_64
> Guest:
> kernel-5.13.0-0.rc7.51.el9.x86_64

The issue was reported with the followin env:

kernel-5.13.0-0.rc4.33.el9.x86_64
qemu-kvm-6.0.0-5.el9.x86_64

It would be interesting to know which component is responsible - qemu
or kernel as I'm unable to spot any relevant changes. The only guess
I have is that 'q35' machine type was updated.

> 
> Test steps is same as comment1
> 
> QMP output:
> {"execute":"qmp_capabilities"}
> {"return": {}}
> {"timestamp": {"seconds": 1625823106, "microseconds": 327872}, "event":
> "GUEST_PANICKED", "data": {"action": "pause"}}
> {"timestamp": {"seconds": 1625823106, "microseconds": 385322}, "event":
> "STOP"}
> {"execute":"query-status"}
> {"return": {"status": "guest-panicked", "singlestep": false, "running":
> false}}
> 
> I noticed that the pvpanic device has a new parameter "event". I did not set
> this option in the qemu command, 
> but this parameter is added by default to the pvpanic device (events=3).
> Could someone explain what this parameter does? Thanks a lot.
> 
> (qemu) info qtree
>           dev: pvpanic, id "idUEPpR9"
>             ioport = 1285 (0x505)
>             events = 3 (0x3)

'events' represents which events are supported and '3' (0b11) 
according to https://github.com/qemu/qemu/blob/master/docs/specs/pvpanic.txt
means that both

bit 0: a guest panic has happened and should be processed by the host
bit 1: a guest panic has happened and will be handled by the guest;
       the host should record it or report it, but should not affect
       the execution of the guest.

types are supported.

(In reply to Vitaly Kuznetsov from comment #5)
> (In reply to leidwang from comment #4)
> > I tested this case with latest rhel9 compose, seems this issue has been
> > fixed.
> > Env:
> > kernel-5.13.0-0.rc7.51.el9.x86_64
> > qemu-kvm-6.0.0-7.el9.x86_64
> > Guest:
> > kernel-5.13.0-0.rc7.51.el9.x86_64
> 
> The issue was reported with the followin env:
> 
> kernel-5.13.0-0.rc4.33.el9.x86_64
> qemu-kvm-6.0.0-5.el9.x86_64
> 
> It would be interesting to know which component is responsible - qemu
> or kernel as I'm unable to spot any relevant changes. The only guess
> I have is that 'q35' machine type was updated.

Maybe caused by kernel, since i tested it with same qemu version(comment1),
it works fine with kernel-5.12.0-1.el9.x86_64
> 
> > 
> > Test steps is same as comment1
> > 
> > QMP output:
> > {"execute":"qmp_capabilities"}
> > {"return": {}}
> > {"timestamp": {"seconds": 1625823106, "microseconds": 327872}, "event":
> > "GUEST_PANICKED", "data": {"action": "pause"}}
> > {"timestamp": {"seconds": 1625823106, "microseconds": 385322}, "event":
> > "STOP"}
> > {"execute":"query-status"}
> > {"return": {"status": "guest-panicked", "singlestep": false, "running":
> > false}}
> > 
> > I noticed that the pvpanic device has a new parameter "event". I did not set
> > this option in the qemu command, 
> > but this parameter is added by default to the pvpanic device (events=3).
> > Could someone explain what this parameter does? Thanks a lot.
> > 
> > (qemu) info qtree
> >           dev: pvpanic, id "idUEPpR9"
> >             ioport = 1285 (0x505)
> >             events = 3 (0x3)
> 
> 'events' represents which events are supported and '3' (0b11) 
> according to https://github.com/qemu/qemu/blob/master/docs/specs/pvpanic.txt
> means that both
> 
> bit 0: a guest panic has happened and should be processed by the host
> bit 1: a guest panic has happened and will be handled by the guest;
>        the host should record it or report it, but should not affect
>        the execution of the guest.
> 
> types are supported.
Thanks a lot.

I'm closing this as CLOSED/WORKSFORME as the issue seems to be gone. Plese reopen in case the issue reproduces again.