Understanding hwclock behavior with QEMU's rtc

[Nathan Vander Wilt]

Like many others before, I am having trouble with the clock in my
guest OS getting out of sync with the rest of the world after the host
machine sleeps. This isn't in itself unexpected, but what is throwing
me off is that when this happens, the hardware clock of my VM is wrong
too, somehow?

After waking up my laptop the system clock of my VM guest OS is way
behind, as expected, but frequently the guest hwclock device itself is
ALSO wrong! For example:

```
me@host-laptop:~$ date -u
Wed Jan 12 16:37:56 UTC 2022

vmuser@guest:~$ date -u
Tue Jan 11 22:05:38 UTC 2022
vmuser@guest:~$ sudo /sbin/hwclock
2022-01-12 00:18:02.825091+00:00         # aka "Wed Jan 12 00:18:02 UTC 2022"
```

That is, not only the system clock of the guest OS is off but also the
guest's hwclock too! I run VMs on my laptop via `qemu-system-aarch64`
with the `-rtc base=utc,clock=host` option. These are under macOS an
M1 host if that's relevant, via Hypervisor framework, i.e. `-machine
virt,highmem=off,accel=hvf` also used among the options.

Since the RTC "hardware" is provided by QEMU itself iiuc, I would have
expected `sudo /sbin/hwclock` to report [approximately] the same time
as the host. But instead it often ends up reporting some _other_ way
wrong time — neither that of the guest OS nor the host OS!

Is this a bug in QEMU or its hvf driver that its hwclock device would
report times so far off from the host time? Or am I misunderstanding
how `-rtc base=utc,clock=host` is intended to work?

thanks,
-natevw