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

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

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?

Note that the physical line is already automatically deasserted (on the PIRQ
layer), so this just deasserts the guest line which IMHO Xen shouldn't care at
all (at the end the guest is free to not deassert it, and it shouldn't affect
Xen at all).

Roger.

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