Re: [Xen-devel] [PATCH 39/57] ARM: new VGIC: Add ACTIVE registers handlers

[Julien Grall <julien.grall@xxxxxxx>]

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.

Cheers,

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel