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

[Qing He <qing.he@xxxxxxxxx>]

On Thu, 2009-01-15 at 10:35 +0800, Shohei Fujiwara wrote:
> I think MSI-INTx translation can be enhanced.
> 
> In case of using MSI enable bit as mask, guest OS need to set interrupt
> disable bit to prevent device from asserting INTx. Actually, linux
> 2.6.25 set interrupt disable bit in
> drivers/pci/msi.c:msi_capability_init.  If interrupt disable bit is 1,
> we can assume guest OS might use MSI enable bit as mask. If interrupt
> disable bit is 0 and MSI enable bit is 0, we can assume guest OS uses
> INTx.

This should be better, but cannot garauntee it. Since INTx disable bit
was added in PCI 2.3. Early guests may exist not using it. Also, some
devices have problems, that setting INTx disable bit also completely
disables MSI from signalling, so OS may not touch INTx disable bit of
these devices.

Theoretically, MSI-enable-as-masking is not correct and should not be
used in the first place. If that were true it would be much easier for
us. However, the existing (and widely used) guest complicates this matter...

> 
> I think we can archive both of good performance and not-using INTx, if
> we control MSI-INTx translation as follows.
> 
> MSI/MSI-X  | Interrupt   | MSI-INTx    | Note
> enable bit | disable bit | translation |
> -----------+-------------+-------------+------------------------------
> 0          | 0           | enable      | Re-enabling MSI-INTx 
>            |             |             | translation is needed.
> -----------+-------------+-------------+------------------------------
> 0          | 1           | disable     | Guest OS might use MSI enable
>            |             |             | bit as mask.
> -----------+-------------+-------------+------------------------------
> 1          | 0           | disable     | Guest OS use MSI/MSI-X.
> -----------+-------------+-------------+------------------------------
> 1          | 1           | disable     | Guest OS use MSI/MSI-X.
> 
> It is great if we can guarantee INTx interrupt isn't used.
> We don't need to consider sharing machine gsi. We don't need to consider
> hot-pluging I/O APIC. In long term, It will be possible even to to remove
> I/O APIC from real machine.

I am not against it, it does look more symmetric, though in the cost of
a little overhead (4 hypercalls for a mask operation) in the worst
(but rare) case. I'll ack the patch if you add it now, or you can wait
for me to add it at some later time.

Thanks,
Qing

> 
> What do you think?
> 
> Thanks
> --
> Shohei Fujiwara
> 

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