On Fri, 24 Sept 2021 at 13:21, Markus Armbruster <arm...@redhat.com> wrote: > ... this isn't really *target*-specific, it's *device*-specific: some > devices implement the event, some don't. > > Ideally, we'd just fix that.
Would you want to tell the far end "this machine simply does not have an RTC device at all (because the hardware it's emulating doesn't have one) and so you won't get RTC_CHANGE events" ? A good first step for getting more devices to implement the RTC_CHANGE support would be if there was any documentation on how to do it. The JSON schema says the offset should be "offset between base RTC clock (as specified by -rtc base), and new RTC clock value", but there aren't any hints (either there or elsewhere) as to how a device is supposed to determine that value, and there's no documentation of what the behaviour or intent is of the qemu_timedate_diff() function that the existing implementations use to calculate the offset. Side note: probably the JSON schema should document the units for 'offset'. Code inspection suggests it wants seconds. Side side note: the JSON event doesn't seem to contemplate the possibility that a machine might have more than one RTC... thanks -- PMM
