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