Re: [Xen-devel] [PATCH 0/6] MSI-INTx interrupt translation for HVM

[Qing He <qing.he@xxxxxxxxx>]

On Fri, 2009-01-09 at 12:26 +0800, Shohei Fujiwara wrote:
> There is the assumption that Guest OS handles all causes which happen
> before Guest OS receives the interrupt. But is the assumption right for
> all OS?
> 
> In the case of level-triggerd interrupt, I/O device asserts interrupt
> line, when the cause of interrupt happens. OS handles the cause,
> I/O device de-asserts interrupt, and OS sends EOI to APICs.
> 
> When I/O APIC receives EOI, I/O APIC re-transmits interrupt to Local APIC 
> if some interrupt line is asserted.
> 
> Some OS might rely on this re-transmittion by I/O APIC. 
> 

> 
> But other OS might have the code like the following:
> 
>       do {
>               ret = action->handler(irq, action->dev_id, regs);
>               if (ret == IRQ_HANDLED) {
>                       status |= action->flags;
>                       retval |= ret;
>                       break;
>                       ^^^^^^
>               }
>               action = action->next;
>       } while (action);
> 
Hmm, I think now I understand what you mean. If the guest irq is shared by
a normal IRQ and a MSI-INTx translated IRQ, two sources may assert the
pin while they both get pending. When this irq is injected, if the guest
only handles one irq source each time, and issues EOI right after it
clears the normal IRQ, the MSI is lost. Is it what you mean?

There is logic to avoid this from happening, see
hvm_irq->gsi_assert_count[gsi]. Basically, it's used to count how many
sources have asserted a shared pin. And at the time of  EOI, after the
decrement of the counter, if it's still not 0, the LAPIC is re-asserted.
This may result in some spurious interrupts to guest, but that's better
than losing interrupts.

The sharing of guest irq is generally not a good idea, in fact, this is
not even well supported in current Xen code. You may have seen something
like "girq[ggsi].mirq = mirq". That way, we are already stuck.
Currently, if the number of assigned devices is <= 8, there should be no
sharing, otherwise, very weird things may happen...

Uncommon devices of OS does have the possibility to fail MSI-INTx, for
example, if the device doesn't behave the same way using INTx and MSI,
or the guest OS doesn't always clear guest source before issuing EOI.
That's why I add the per-device disable function: if a device or OS
doesn't work properly, just turn it off. Fortunately, this is extremely
rare.

Btw, AFAIK, Windows handles all irq sources in one ISR, similar to
Linux.

Thanks,
Qing
> 
> This code will work on real machine, because I/O APIC re-transmits
> interrupt, if the cause to be handled remains.  If some OS has the
> code like the above, the assumption isn't right.
> 
> Actually, my concern is whether the assumption is right for Windows,
> or not. Do you know about this, or does your patch works well with
> Windows guest?
> 
> Thanks,
> --
> Shohei Fujiwara
> 
> > Generally, it's easy to "translate" an edged interrupt to a level one,
> > but not the other way.
> > 
> > Thanks,
> > Qing
> > > 
> > > What do you think?
> > > 
> > > Thanks,
> > > --
> > > Shohei Fujiwara
> > > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxxxxxxxx
> > http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel