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
>
> Thanks,
> --
> Shohei Fujiwara
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home