Re: [Xen-devel] Legacy PCI interrupt {de}assertion count

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Fri, Mar 31, 2017 at 04:46:27AM -0600, Jan Beulich wrote:
> >>> On 31.03.17 at 10:07, <roger.pau@xxxxxxxxxx> wrote:
> > On Fri, Mar 31, 2017 at 05:05:44AM +0000, Tian, Kevin wrote:
> >> > From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> >> > Sent: Monday, March 27, 2017 4:00 PM
> >> > 
> >> > >>> On 24.03.17 at 17:54, <roger.pau@xxxxxxxxxx> wrote:
> >> > > As I understand it, for level triggered legacy PCI interrupts Xen sets
> >> > > up a timer in order to perform the EOI if the guest takes too long in
> >> > > deasserting the line. This is done in pt_irq_time_out. What I don't
> >> > > understand is why this function also does a deassertion of the guest 
> >> > > view
> >> > of the PCI interrupt, ie:
> >> > > why it calls hvm_pci_intx_deassert. This AFAICT will clear the pending
> >> > > assert in the guest, and thus the guest will end up loosing one 
> >> > > interrupt.
> >> > 
> >> > Especially with the comment next to the respective set_timer() it looks 
> >> > to me
> >> > as if this was the intended effect: If the guest didn't care to at least 
> >> > start
> >> > handling the interrupt within PT_IRQ_TIME_OUT, we want it look to be 
> >> > lost in
> >> > order to not have it block other interrupts inside the guest (i.e. 
> >> > there's more
> >> > to it than just guarding the host here).
> >> > 
> >> > "Luckily" commit 0f843ba00c ("vt-d: Allow pass-through of shared
> >> > interrupts") introducing this has no description at all. Let's see if 
> >> > Kevin
> >> > remembers any further details ...
> >> > 
> >> 
> >> Sorry I don't remember more detail other than existing comments.
> >> Roger, did you encounter a problem now?
> > 
> > No, I didn't encounter any problems with this so far, any well behaved guest
> > will deassert those lines anyway, it just seems to be against the spec.  
> > AFAIK
> > on bare metal the line will be asserted until the OS deasserts it, so I was
> > wondering if this was some kind of workaround?
> 
> "OS deasserts" is a term I don't understand. Aiui it's the origin device
> which would need to de-assert its interrupt, and I think it is not
> uncommon for devices to de-assert interrupts after a certain amount
> of time. If that wasn't the case, spurious interrupts could never occur.

I recall Sander (CC-ed) here hitting this at some point. There was some device
he had (legacy?) that would very much hit this path.

But I can't recall the details, sorry.

Sanders, it was in the context of the dpci softirq work I did if that helps.

> 
> Jan
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> https://lists.xen.org/xen-devel

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