From mboxrd@z Thu Jan 1 00:00:00 1970 From: Qing He Subject: Re: [PATCH 0/6] MSI-INTx interrupt translation for HVM Date: Wed, 14 Jan 2009 15:38:46 +0800 Message-ID: <20090114073846.GA25230@ub-qhe2> References: <20090113175932.EA8A.CB716985@necst.nec.co.jp> <20090113092813.GA9499@ub-qhe2> <20090114153841.865B.CB716985@necst.nec.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20090114153841.865B.CB716985@necst.nec.co.jp> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Shohei Fujiwara Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org 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 >