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

[Qing He <qing.he@xxxxxxxxx>]

On Wed, 2009-01-14 at 14:39 +0800, Shohei Fujiwara wrote:
> I think adding blacklist now is better, because it is easy to specify
> an unsuitable device when it is found. But I don't know what other
> developers think about this.

I'm OK either way

> 
> 
> BTW, I found a issue when I read your code.
> 
> MSI-INTx translation is enabled when guest domain is started.
> When guest OS enables MSI/MSI-X, MSI-INTx translation is disabled.
> But when guest OS disables MSI/MSI-X, MSI-INTx translation isn't re-enabled.
> This means normal INTx interrupt is used.
> 
> I think the results should be the same at all times,
> so it is good to re-enable MSI-INTx translation.

There is a complication here. Some guests, notably certain versions of
Linux (2.6.25 for instance) uses MSI enable bit as mask, like:

>>  static void msi_set_mask_bit(unsigned int irq, int flag)
>>  {
>>      ...
>>      switch (entry->msi_attrib.type) {
>>      case PCI_CAP_ID_MSI:
>>              if (entry->msi_attrib.maskbit) {
>>                      ...
>>              } else {
>>                      msi_set_enable(entry->dev, !flag);
>>              }
>>              break;
>>      ...

(It is said not work for some devices since pending msi may be lost in
this way, so it got reverted in later versions)

If the guest extensively uses this technique, re-enabling MSI-INTx during
mask would be a pain, since it needs several hypercalls and thus hurts
performance.


Furthermore, why a guest driver would want to disable MSI if it can benefit
from it (Maybe because MSI doesn't work:-)? The presumption behind not
re-enabling the translation is that it's seldom that guest would want to
disable-after-enable the MSI. And it's more efficient for
guests like linux-2.6.25.

> 
> Thanks,
> --
> Shohei Fujiwara
> 

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