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] Move some of the PCI device manage/control into pciback?

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, Shohei Fujiwara <fujiwara-sxa@xxxxxxxxxxxxxxx>, "Cui, Dexuan" <dexuan.cui@xxxxxxxxx>
Subject: RE: [Xen-devel] Move some of the PCI device manage/control into pciback?
From: "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>
Date: Tue, 20 Jan 2009 14:08:29 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "'xen-devel@xxxxxxxxxxxxxxxxxxx'" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "He, Qing" <qing.he@xxxxxxxxx>
Delivery-date: Mon, 19 Jan 2009 22:09:00 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C595F0A4.21065%keir.fraser@xxxxxxxxxxxxx>
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: <E2263E4A5B2284449EEBD0AAB751098401C4F933E4@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C595F0A4.21065%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acl3ARGOElD8xodYiEqGOngli7SaRwAoO5DQAAPaIQgAxO6FQA==
Thread-topic: [Xen-devel] Move some of the PCI device manage/control into pciback?
Keir Fraser <mailto:keir.fraser@xxxxxxxxxxxxx> wrote:
> On 16/01/2009 06:18, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx> wrote:
> 
>>> I'd rather have all accesses mediated through pciback. I don't think PCI
>>> config accesses should be on any data path anyway, and you've already
>>> taken the hit of trapping to qemu in that case.
>> 
>> There is one exception: The mask bit for MSI/MSI-X. Maybe we need add some
>> mechanism for HVM domain to mask/unmask the virtual interrupt directly,
>> like what DomU did for evtchn. But that will be tricky.
> 
> Yes, that did occur to me. We already have plenty of special emulation code
> for MSI/MSI-x. I guess we may explicitly paravirtualise that
> aspect in a
> different way which would allow ioemu to interact direct with
> Xen. Actually
> if mask/unmask happens on every IRQ, we may need to push
> support for the PCI
> MSI registers right down into Xen itself to get decent speed?
> Because going
> to qemu with any great frequency is not very high performance.

We plan to do this for MSI-X firstly, since currently qemu does not present 
mask support for MSI interrupt.
And we do notice such issue for some OS (at least for those based on kernel 
2.6.18).

> 
> -- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel