@samitouri / QOSamiQemu / commits / dfabea1fe3

hw/xtensa/mx_pic: Specify xtensa_mx_pic_ops .impl settings

The xtensa mx-pic interrupt controller has a rather odd register setup, where some registers are 32 bits but are decoded at offsets only one apart from each other. The QEMU implementation handles this correctly, but it did not set .impl.unaligned = true. This has worked up til now because QEMU has entirely ignored .impl.unaligned, and just allowed through unaligned accesses when .valid.unaligned is set. To allow the possibility of properly implementing synthesis of unaligned accesses by the memory subsystem when they are valid but the device doesn't implement them, and for clarity of intention, state explicitly that this MR's read and write functions directly handle unaligned accesses, by setting .impl.unaligned = true. While we are adjusting the MemoryRegionOps, we set also the minimum and maximum allowed access sizes. Since the only way to get at this device is via the CPU's RER and WER instructions, which always operate at 32-bit sizes (see the HELPER(rer) and HELPER(wer) functions in target/xtensa/op_helper.c), we know we will always get 32-bit accesses. Specify explicitly that that is what is valid and implemented for the MR. Add a comment to clarify that the hardware behaviour here is not "true memory-mapped registers", so the odd-looking implementation is correct. Based-on-a-patch-by: CJ Chen <cjchen@igel.co.jp> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Max Filippov <jcmvbkbc@gmail.com> Link: https://lore.kernel.org/r/20260428093339.2087081-4-peter.maydell@linaro.org Signed-off-by: Peter Xu <peterx@redhat.com>

Peter Maydell committed Apr 28, 2026 at 10:33 UTC dfabea1fe397c96ebde3c530a40d06515d58034c
1 file changed +27
hw/xtensa/mx_pic.c
+27
@@ -69,6 +69,26 @@ struct XtensaMxPic {
69 } cpu[MX_MAX_CPU];
70 };
71
72 +/*
73 + * Note that decode for these registers is rather strange by the usual
74 + * MMIO standards -- the MIROUT and MIPICAUSE areas can be read and
75 + * written at 32-bit length, returning different values for each byte
76 + * offset, because the low bits of the address are treated as selecting
77 + * an IRQ or a processor:
78 + *
79 + * 00nn 0...0p..p Interrupt Routing, route IRQ n to processor p
80 + * 01pp 0...0d..d 16 bits (d) 'ored' as single IPI to processor p
81 + *
82 + * This is because (like x86 IO port in/out accesses) the offset is
83 + * not a memory-mapped address but is really a register number,
84 + * accessed via the Xtensa RER/WER "external register" instructions.
85 + *
86 + * We set .valid and .impl to both allow unaligned = true to permit
87 + * these byte-offsets. Because this device is not a true memory mapped
88 + * device but is accessible only via the Xtensa RER/WER "external
89 + * register" interface, all accesses are guaranteed 32 bits.
90 + */
91 +
92 static uint64_t xtensa_mx_pic_ext_reg_read(void *opaque, hwaddr offset,
93 unsigned size)
94 {
@@ -267,7 +287,14 @@ static const MemoryRegionOps xtensa_mx_pic_ops = {
287 .read = xtensa_mx_pic_ext_reg_read,
288 .write = xtensa_mx_pic_ext_reg_write,
289 .endianness = DEVICE_NATIVE_ENDIAN,
290 + .impl = {
291 + .min_access_size = 4,
292 + .max_access_size = 4,
293 + .unaligned = true,
294 + },
295 .valid = {
296 + .min_access_size = 4,
297 + .max_access_size = 4,
298 .unaligned = true,
299 },
300 };