Created attachment 1804717 [details] aarch64_guest.xml Description of problem: virsh event can't capture aarch64 guest rtc-change events. I verified that x86_64 works well. Version-Release number of selected component (if applicable): libvirt-7.5.0-1.module+el8.5.0+11664+59f87560.aarch64 How reproducible: 100% Steps to Reproduce: 1. Start aarch64 guest with <clock offset='utc'/> 2. Create a new terminal and run 'virsh event --loop --event rtc-change' 3. Login guest and run 'hwclock --systohc' Actual results: virsh event can't capture rtc-change Expected results: virsh event could capture rtc-change E.g. Refer to x86_64 ``` # virsh event --loop --event rtc-change event 'rtc-change' for domain 'avocado-vt-vm1': 0 ``` Additional info: I verified on x86_64 with same libvirt version, virsh event could capture rtc-change.
Created attachment 1804718 [details] x86_64_guets.xml
Since I don't have access to an aarch64 box. Please attach the debug log of libvirtd from when you've attempted to reproduce the bug. I need to see the QMP interactions to see whether qemu actually delivered the event.
Hi, Peter Sorry for the late reply (In reply to Peter Krempa from comment #2) > Since I don't have access to an aarch64 box. Please attach the debug log of > libvirtd from when you've attempted to reproduce the bug. I need to see the > QMP interactions to see whether qemu actually delivered the event. I set libvirtd as below ``` log_level = 1 log_filters="2:qemu.qemu_monitor 3:*" log_outputs="1:file:/var/log/libvirt/libvirtd.log" ``` Reproduce steps ``` [root@hpe-moonshot-02-c25 tmp]# ssh root.122.171 root.122.171's password: Last login: Mon Jul 26 04:08:21 2021 from 192.168.122.1 [root@atest-guest ~]# hwclock --systohc [root@atest-guest ~]# hwclock --systohc [root@atest-guest ~]# shutdown now Connection to 192.168.122.171 closed by remote host. Connection to 192.168.122.171 closed. ``` libvirtd.log please check attachment.
Created attachment 1805806 [details] libvirtd
Created attachment 1805808 [details] libvirtd.log2 Change filter level to log_filters="1:qemu.qemu_monitor 3:*"
From the debug log these are the QMP events emitted by qemu during the lifetime of the VM: 2021-07-26 08:18:52.718+0000: 50872: info : qemuMonitorJSONIOProcessLine:237 : QEMU_MONITOR_RECV_EVENT: mon=0xffff301eb180 event={"timestamp": {"seconds": 1627287532, "microseconds": 718362}, "event": "RESUME"} 2021-07-26 08:19:06.789+0000: 50872: info : qemuMonitorJSONIOProcessLine:237 : QEMU_MONITOR_RECV_EVENT: mon=0xffff301eb180 event={"timestamp": {"seconds": 1627287546, "microseconds": 788252}, "event": "VSERPORT_CHANGE", "data": {"open": true, "id": "channel0"}} 2021-07-26 08:19:08.688+0000: 50872: info : qemuMonitorJSONIOProcessLine:237 : QEMU_MONITOR_RECV_EVENT: mon=0xffff301eb180 event={"timestamp": {"seconds": 1627287548, "microseconds": 688385}, "event": "NIC_RX_FILTER_CHANGED", "data": {"name": "net0", "path": "/machine/peripheral/net0/virtio-backend"}} 2021-07-26 08:20:05.372+0000: 50872: info : qemuMonitorJSONIOProcessLine:237 : QEMU_MONITOR_RECV_EVENT: mon=0xffff301eb180 event={"timestamp": {"seconds": 1627287605, "microseconds": 372540}, "event": "VSERPORT_CHANGE", "data": {"open": false, "id": "channel0"}} 2021-07-26 08:20:10.225+0000: 50872: info : qemuMonitorJSONIOProcessLine:237 : QEMU_MONITOR_RECV_EVENT: mon=0xffff301eb180 event={"timestamp": {"seconds": 1627287610, "microseconds": 225214}, "event": "SHUTDOWN", "data": {"guest": true, "reason": "guest-shutdown"}} 2021-07-26 08:20:10.311+0000: 50872: info : qemuMonitorJSONIOProcessLine:237 : QEMU_MONITOR_RECV_EVENT: mon=0xffff301eb180 event={"timestamp": {"seconds": 1627287610, "microseconds": 311569}, "event": "STOP"} 2021-07-26 08:20:10.312+0000: 50872: info : qemuMonitorJSONIOProcessLine:237 : QEMU_MONITOR_RECV_EVENT: mon=0xffff301eb180 event={"timestamp": {"seconds": 1627287610, "microseconds": 312377}, "event": "SHUTDOWN", "data": {"guest": false, "reason": "host-signal"}} There's no "RTC_CHANGE" event thus there's nothing for libvirt to emit the event further. I'm not sure whether aarch64 even has provisions for emitting the RTC_CHAGE event. Moving to qemu for further investigation.
Thank you for looking into this Peter! We need to check why QEMU is not emitting RTC_CHANGE for ARM...
Looks the problem is that qapi_event_send_rtc_change() is not sent from PL031 RTC when changing the offset value. Does not look like a regression to me. Working on this.
I sent [PATCH] hw/rtc/pl031: Send RTC_CHANGE QMP event upstream
Bulk update: Move RHEL-AV bugs to RHEL8. Since this is a Fujitsu tracked bug, I did not create a RHEL9 clone. If the bug is fixed and needs to be tested in RHEL9, a clone should be created.
Move to RHEL9, per Luiz
Fix "hw/rtc/pl031: Send RTC_CHANGE QMP event" is now upstream and port of qemu 6.2. Moving to POST.
Commit: 1adf528ec3bdf62ea3b580b7ad562534a3676ff5 hw/rtc/pl031: Send RTC_CHANGE QMP event
(In reply to Eric Auger from comment #12) > Fix "hw/rtc/pl031: Send RTC_CHANGE QMP event" is now upstream and port of > qemu 6.2. Moving to POST. Verified on upstream qemu. It works. Thanks. # qemu-system-aarch64 --version QEMU emulator version 6.1.90 (v6.2.0-rc0-80-g56f4f41e02) Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers
Hi @
Hi @jferlan I can't get your confidential comment due to the account permission. For the same reason, I can't set some BZ flags. So I asked Jin for help.
(In reply to Yiding Liu (Fujitsu) from comment #17) > Hi @jferlan > > I can't get your confidential comment due to the account permission. > For the same reason, I can't set some BZ flags. So I asked Jin for help. Whoops - sorry - I was updating several bugs at one time and didn't even check this was one of those OtherQA ones where the recipient couldn't read private comments. In any case, it's an internal process thing in order to get the "release+" flag set we need to set the field "Internal Target Milestone" to some value. Typically Devs and QE work together to set a value, but when we rebase our upstream package (in this case qemu-kvm) to our downstream environment the timing of that communication and the volume of changes will miss a few bugs, so I watch for it and set needinfo's. In any case, I see Jin already took care of it - so nothing to worry about!
Verified on qemu-kvm-6.2.0-1.el9.aarch64. No errors appear any more. [root@localhost ~]# hwclock --systohc [root@hpe-apache-cn99xx-09 SPECS]# virsh event --loop --event rtc-change event 'rtc-change' for domain 'avocado-vt-vm1': 0
Set the bug to verified according to Comment 19
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 (new packages: qemu-kvm), 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/RHBA-2022:2307