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.
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.
What do you think?
Thanks
--
Shohei Fujiwara
On Wed, 14 Jan 2009 17:17:52 +0800
Qing He <qing.he@xxxxxxxxx> wrote:
> On Wed, 2009-01-14 at 16:26 +0800, Shohei Fujiwara wrote:
> > > 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.
> >
> > Basically, I would not like to assume any behavior of guest OS or
> > user. User might unload device driver at runtime, and load it again
> > disabling MSI. So we still need to use I/O APIC. we are not freed
> > from sharing machine GSI problem.
>
> For the user unloading and reloading issue, if the driver uses MSI for
> both times, it works fine. If the driver uses INTx for both times
> without ever enabling MSI, it also works fine with MSI-INTx translation
> on at all time. Only if the user starts with driver in MSI mode, unloads
> it, and then reloads it in legacy irq mode, he may go back to no
> translation, but why does he want to do this? And even in this case,
> it still works correctly, just without MSI-INTx translation.
>
> This patch is never intended to be a perfect for all solution, as
> mentioned early, if the device or guest driver does something nasty, it
> would fail, that's why the option is added in the first place.
>
> Since INTx is considered leagacy regarding to MSI, the bottom line is
> that the patch should not hurt guest passthrough MSI performance, which
> is not the case if MSI-INTx is turned on when MSI is simply masked
> (implemented as disabling by some guests).
>
> Using INTx after enabling and disabling MSI may not be as fast as it
> can be (it's definitely no slower). But considering the rarity of this
> situation, I would think the trade-off is just sound.
>
> What do you think?
>
>
> Thanks,
> Qing
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home