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