Question about ITS Retry Behavior after Stalled MAPD Command

Hello,

While testing various features of the GICv3 ITS, I came across some behavior regarding the ITS retry mechanism and wanted to ask a couple of questions.

After a command causes the ITS to stall, I observed that writing 1 to the GITS_CWRITER.retry bit causes the GITS_CREADR value to catch up with GITS_CWRITER.

In my setup (kernel 5.10.y) with dummy device, the ITS always stalls at the MAPD command during MSI setup.

As a result, the system fails to complete the MAPD and MAPTI commands during boot.

However, after issuing a retry, GITS_CREADR catches up with GITS_CWRITER, and when I trigger the MSI (via an INT command), the interrupt handler is correctly called.

I have two questions:

1. Why does the ITS always stall at the MAPD command? (Could this be because I'm testing with a dummy device?)

2. After retrying the stalled command, everything appears to work normally — is it safe to assume that the commands completed successfully without issues?

Thank you in advance!