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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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.

Jan


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