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>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20210920122535.269988-1-eric.auger@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
When running device-introspect-test, a memory leak occurred in the pl031_init
function, this patch use timer_free() in the finalize function to fix it.
ASAN shows memory leak stack:
Direct leak of 48 byte(s) in 1 object(s) allocated from:
#0 0xffffab97e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0)
#1 0xffffab256800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800)
#2 0xaaabf5621cfc in timer_new_full qemu/include/qemu/timer.h:523
#3 0xaaabf5621cfc in timer_new qemu/include/qemu/timer.h:544
#4 0xaaabf5621cfc in timer_new_ns qemu/include/qemu/timer.h:562
#5 0xaaabf5621cfc in pl031_init qemu/hw/rtc/pl031.c:194
#6 0xaaabf6339f6c in object_initialize_with_type qemu/qom/object.c:515
#7 0xaaabf633a1e0 in object_new_with_type qemu/qom/object.c:729
#8 0xaaabf6375e40 in qmp_device_list_properties qemu/qom/qom-qmp-cmds.c:153
#9 0xaaabf5a95540 in qdev_device_help qemu/softmmu/qdev-monitor.c:283
#10 0xaaabf5a96940 in qmp_device_add qemu/softmmu/qdev-monitor.c:801
#11 0xaaabf5a96e70 in hmp_device_add qemu/softmmu/qdev-monitor.c:916
#12 0xaaabf5ac0a2c in handle_hmp_command qemu/monitor/hmp.c:1100
Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: Gan Qixin <ganqixin@huawei.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20210112112705.380534-2-ganqixin@huawei.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
The current PL031 RTCICR register implementation always clears the
IRQ pending status on a register write, regardless of the value the
guest writes.
To justify that behavior, it references the ARM926EJ-S Development
Chip Reference Manual (DDI0287B) and indicates that said document
states that any write clears the internal IRQ state. It is indeed
true that in section 11.1 this document says:
"The interrupt is cleared by writing any data value to the
interrupt clear register RTCICR".
However, later in section 11.2.2 it contradicts itself by saying:
"Writing 1 to bit 0 of RTCICR clears the RTCINTR flag."
The latter statement matches the PL031 TRM (DDI0224C), which says:
"Writing 1 to bit position 0 clears the corresponding interrupt.
Writing 0 has no effect."
Let's assume that the self-contradictory DDI0287B is in error, and
follow the reference manual for the device itself, by making the
register write-one-to-clear.
Reported-by: Hendrik Borghorst <hborghor@amazon.de>
Signed-off-by: Alexander Graf <graf@amazon.com>
Message-id: 20191104115228.30745-1-graf@amazon.com
[PMM: updated commit message to note that DDI0287B says two
conflicting things]
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The PL031 is a Real Time Clock, not a timer.
Move it under the hw/rtc/ subdirectory.
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Acked-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20191003230404.19384-3-philmd@redhat.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
