qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2] hw/rtc/pl031: Send RTC_CHANGE QMP event


From: Paolo Bonzini
Subject: Re: [PATCH v2] hw/rtc/pl031: Send RTC_CHANGE QMP event
Date: Mon, 15 Nov 2021 13:48:50 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0

On 11/1/21 17:04, Peter Maydell wrote:
On Thu, 23 Sept 2021 at 14:29, Peter Maydell <peter.maydell@linaro.org> wrote:

On Mon, 20 Sept 2021 at 13:25, Eric Auger <eric.auger@redhat.com> wrote:

The PL031 currently is not able to report guest RTC change to the QMP
monitor as opposed to mc146818 or spapr RTCs. This patch adds the call
to qapi_event_send_rtc_change() when the Load Register is written. The
value which is reported corresponds to the difference between the guest
reference time and the reference time kept in softmmu/rtc.c.

For instance adding 20s to the guest RTC value will report 20. Adding
an extra 20s to the guest RTC value will report 20 + 20 = 40.

The inclusion of qapi/qapi-types-misc-target.h in hw/rtl/pl031.c
require to compile the PL031 with specific_ss.add() to avoid
./qapi/qapi-types-misc-target.h:18:13: error: attempt to use poisoned
"TARGET_<ARCH>".

Signed-off-by: Eric Auger <eric.auger@redhat.com>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

Thanks. This looks plausible to me (well, it would ;-)) but
I would appreciate review from Paolo or somebody else who
understands the rtc_change feature and handling.

Ping? Review from somebody who understands rtc_change would
still be nice...

The change looks good to me (sorry I missed this v2). x86 also has some logic in the migration post-load, that might end up sending the event. However, that's best done separately after understanding and documenting exactly what x86 is doing.

Paolo




reply via email to

[Prev in Thread] Current Thread [Next in Thread]