WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Qing He <qing.he@xxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 0/6] MSI-INTx interrupt translation for HVM
From: Shohei Fujiwara <fujiwara-sxa@xxxxxxxxxxxxxxx>
Date: Wed, 14 Jan 2009 17:26:11 +0900
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 14 Jan 2009 00:26:43 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20090114073846.GA25230@ub-qhe2>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20090114153841.865B.CB716985@xxxxxxxxxxxxxxx> <20090114073846.GA25230@ub-qhe2>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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