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

[Qing He <qing.he@intel.com>]

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
>