When handling MAPI/MAPTI, we allow the supplied interrupt ID to be
either 1023 or something in the valid LPI range. This is a mistake:
only a real valid LPI is allowed. (The general behaviour of the ITS
is that most interrupt ID fields require a value in the LPI range;
the exception is that fields specifying a doorbell value, which are
all in GICv4 commands, allow also 1023 to mean "no doorbell".)
Remove the condition that incorrectly allows 1023 here.
Signed-off-by: Peter Maydell <peter.mayd...@linaro.org>
---
This one's my fault -- Shashi's original code did the right thing,
IIRC. The spec text and pseudocode disagree here, and in code review
I backed the wrong horse. Sorry.
---
hw/intc/arm_gicv3_its.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/hw/intc/arm_gicv3_its.c b/hw/intc/arm_gicv3_its.c
index 069991f7f36..8dade9440ac 100644
--- a/hw/intc/arm_gicv3_its.c
+++ b/hw/intc/arm_gicv3_its.c
@@ -406,8 +406,7 @@ static ItsCmdResult process_mapti(GICv3ITSState *s, const
uint64_t *cmdpkt,
if ((icid >= s->ct.num_entries)
|| !dte.valid || (eventid >= num_eventids) ||
- (((pIntid < GICV3_LPI_INTID_START) || (pIntid >= num_intids)) &&
- (pIntid != INTID_SPURIOUS))) {
+ (((pIntid < GICV3_LPI_INTID_START) || (pIntid >= num_intids)))) {
qemu_log_mask(LOG_GUEST_ERROR,
"%s: invalid command attributes "
"icid %d or eventid %d or pIntid %d or"
--
2.25.1
