]> xenbits.xensource.com Git - qemu-xen.git/commit
hw/intc/arm_gicv3: ICC_PMR_EL1 high bits should be RAZ
authorBen Dooks <ben.dooks@codethink.co.uk>
Thu, 16 Nov 2023 17:28:18 +0000 (17:28 +0000)
committerPeter Maydell <peter.maydell@linaro.org>
Mon, 20 Nov 2023 15:11:35 +0000 (15:11 +0000)
commit70726a15bc7e61d16f3efe5bfd9b061ca077f533
tree5d0d5ab67d4706df7bc4ec387484fb28e93f6aa8
parente867a1242ebab8b7dbab99da8187b7813407d395
hw/intc/arm_gicv3: ICC_PMR_EL1 high bits should be RAZ

The ICC_PMR_ELx and ICV_PMR_ELx bit masks returned from
ic{c,v}_fullprio_mask should technically also remove any
bit above 7 as these are marked reserved (read 0) and should
therefore should not be written as anything other than 0.

This was noted during a run of a proprietary test system and
discused on the mailing list [1] and initially thought not to
be an issue due to RES0 being technically allowed to be
written to and read back as long as the implementation does
not use the RES0 bits. It is very possible that the values
are used in comparison without masking, as pointed out by
Peter in [2], if (cs->hppi.prio >= cs->icc_pmr_el1) may well
do the wrong thing.

Masking these values in ic{c,v}_fullprio_mask() should fix
this and prevent any future problems with playing with the
values.

[1]: https://lists.nongnu.org/archive/html/qemu-arm/2023-11/msg00607.html
[2]: https://lists.nongnu.org/archive/html/qemu-arm/2023-11/msg00737.html

Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Message-id: 20231116172818.792364-1-ben.dooks@codethink.co.uk
Suggested-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
hw/intc/arm_gicv3_cpuif.c