Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
x86 uses the the pvpanic ISA device whereas on ARM the pvpanic-pci device is used.
libvirt must be enhanced to support its instantiation.
Comment 8yalzhang@redhat.com
2022-10-19 03:40:37 UTC
Hi Eric， Could you please help evaluate if this feature is still needed? If yes, we can extend the stale date to +6M. Or it will be closed as won't fix automatically. Thank you!
Comment 9yalzhang@redhat.com
2022-10-20 03:29:27 UTC
extend the stale date as the priority for arm increased
Comment 11Hu Shuai (Fujitsu)
2022-11-30 01:49:23 UTC
Hi, Andrea, is there any progress or plan for this new feature?
Comment 12Andrea Bolognani
2022-12-02 17:59:05 UTC
(In reply to Hu Shuai (Fujitsu) from comment #11)
> Hi, Andrea, is there any progress or plan for this new feature?
Reassigning to Kristina, who will look into it in the coming weeks.
Hi Kristina, the qemu enablement was tracked by https://bugzilla.redhat.com/show_bug.cgi?id=1747467. There, you will be able to find the test setup we used. Compared to x86 integration the specificity is the pvpanic device is a pcie device and not an ISA one. So it needs to be integrated like other PCIe end-points (maybe the virtio-iommu-pci device laterly introduced can be used as an example? But better to ask Andrea)
merged upstream as:
4bae0c8ae4 NEWS: Document new pvpanic-pci device
c98e49f82e docs: document panic device 'pvpanic-pci'
78744415fe tests: add case for pvpanic-pci without address
9f52df3a70 qemu: assign PCI address to device pvpanic-pci
f4367059d2 tests: add test cases for device pvpanic-pci
46ef87e10e conf: add panic model 'pvpanic'
741624a1a6 qemu: introduce QEMU_CAPS_DEVICE_PANIC_PCI
v9.0.0-247-g4bae0c8ae4
Comment 16Hu Shuai (Fujitsu)
2023-02-23 07:57:36 UTC
Test with upstream libvirt.
```
# git describe
v9.1.0-rc1-1-g6af048339f
```
Env:
kernel-5.14.0-268.el9.aarch64
libvirt-9.1.0-1.el9.aarch64
1. The guest can be defined and started with device panic.
1.1 Add panic device to the guest xml
```
# cat avocado-vt-vm1.xml | grep panic
<panic model='pvpanic'/>
```
1.2 Define && start the guest
```
# virsh define avocado-vt-vm1.xml
Domain 'avocado-vt-vm1' defined from avocado-vt-vm1.xml
# virsh start avocado-vt-vm1
Domain 'avocado-vt-vm1' started
```
1.3 Check the panic device of running guest
```
# virsh dumpxml avocado-vt-vm1 | grep /panic -B2
<panic model='pvpanic'>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</panic>
```
2. The guest can be shut off when triggering the guest crash through 'echo c > /proc/sysrq-trigger'.
On guest:
```
# systemctl stop kdump
# echo 1 > /proc/sys/kernel/sysrq
# echo c > /proc/sysrq-trigger
```
On host:
```
# virsh domstate avocado-vt-vm1 --reason
shut off (crashed)
```
Log from /var/log/libvirt/qemu/avocado-vt-vm1.log
```
2023-02-23 07:47:37.216+0000: shutting down, reason=crashed
2023-02-23T07:47:37.220955Z qemu-kvm: terminating on signal 15 from pid 4590 (<unknown process>)
```
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory (Moderate: libvirt security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHSA-2023:6409