Re: [Xen-devel] [PATCH v6 13/18] Update IRTE according to guest interrupt config changes

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 08.09.15 at 06:47, <feng.wu@xxxxxxxxx> wrote:

> 
>> -----Original Message-----
>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> Sent: Monday, September 07, 2015 7:03 PM
>> To: Wu, Feng
>> Cc: xen-devel@xxxxxxxxxxxxx 
>> Subject: RE: [PATCH v6 13/18] Update IRTE according to guest interrupt 
> config
>> changes
>> 
>> >>> On 06.09.15 at 06:54, <feng.wu@xxxxxxxxx> wrote:
>> >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> >> Sent: Friday, September 04, 2015 11:59 PM
>> >> >>> On 25.08.15 at 03:57, <feng.wu@xxxxxxxxx> wrote:
>> >>> 
>> >> > +            if ( vcpu )
>> >> > +            {
>> >> > +                rc = pi_update_irte( vcpu, info,
>> pirq_dpci->gmsi.gvec );
>> >> > +                if ( unlikely(rc) )
>> >> > +                    dprintk(XENLOG_G_INFO,
>> >> > +                            "%pv: failed to update PI IRTE,
>> >> gvec:%02x\n",
>> >> > +                            vcpu, pirq_dpci->gmsi.gvec);
>> >>
>> >> Even if only a debug build printk() - aren't you afraid that if this
>> >> ever triggers, it will trigger a lot? And hence be pretty useless?
>> >
>> > I think it reaches this debug printk rarely, but a least, when it is really
>> > failed, it
>> > can give people some hints about why we are using interrupt remapping
>> > instead
>> > of interrupt posing for the external interrupts.
>> 
>> I understand your motivation, but you don't really answer my
>> question. (And btw., if you really mean "rarely", then there's a bug
>> somewhere that you need to fix. It should _never_ trigger if
>> everything is working correctly.)
> 
> I mean pi_update_irte() can return failure theoretically, because there
> are some pointer check in it. You said, it would trigger a lot if this ever
> triggers.

I didn't say it would, I asked whether it might. That's on the basis
that often once an error like this happened, more similar errors are
likely to occur subsequently. Whether that's the case here I can't
easily tell, hence I'm asking you (supposedly having a better
understanding of what can go wrong when and how often).

> Do you mean for a specific pirq, it will always fail after the first
> failure? So what is your suggestion here? Adding an ASSERT()?

An ASSERT() would make things worse (bringing down a debug
hypervisor). Limiting the amount of printing is what I asked to
consider.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel