On Wed, 14 Jan 2009 15:38:46 +0800
Qing He <qing.he@xxxxxxxxx> wrote:
> 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.
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.
Thanks,
--
Shohei Fujiwara
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home