On 13/03/18 17:14, Julien Grall wrote:
On 13/03/18 17:02, Andre Przywara wrote:
On 08/03/18 15:39, Julien Grall wrote:
On 05/03/18 16:03, Andre Przywara wrote:
I admit the bailout is a bit weird here. You would only print the
warning for the first activated IRQ and give the impression it is fine
for the rest. So maybe you want to drop IRQ%d?
For the above reasons I wanted to keep them concise, so that we see that
the issue has happened, but avoid getting tons of error messages about
the same problem (as this may affect up to 32 IRQs).
But for debugging it might be good to know which IRQ was affected. I see
two use cases for a guest:
- (De-)activating a single IRQ: we get one message and know which IRQ it
was, so an admin can chase this down to a certain device (driver).
- (De-)activating *every* IRQ in this range (~0): we still get one
message per 32 IRQs, but can see whether it covers SPIs only (IRQ>=32)
and which ones.
So what about a compromise: I use dprintk(XENLOG_G_ERR, "%pv ...), print
the (first) IRQ and the *value* to be written. So a knowledgeable admin
can tell whether it's a single IRQ or a "clear/set-all" case. That
should also give enough info for debugging, but keeps it short.
I can't see how a knowledgeable admin will be able to know that IRQ 2 is
active with just the register value.
Does that sound OK?
I would still prefer the one per IRQ and using printk(XENLOG_G_*). I > don't
much care about the spam, see why above.
XENLOG_G_DEBUG is a good candidate actually.
Xen-devel mailing list