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 1/5] Add MSI support to XEN

To: "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx>, "Shan, Haitao" <haitao.shan@xxxxxxxxx>, "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>, "xen-devel" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH 1/5] Add MSI support to XEN
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Fri, 28 Mar 2008 17:49:05 +0800
Cc: "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>, "Li, Xin B" <xin.b.li@xxxxxxxxx>
Delivery-date: Fri, 28 Mar 2008 02:54:53 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C4126BCE.1E73F%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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <D470B4E54465E3469E2ABBC5AFAC390F024D9145@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C4126BCE.1E73F%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AciP14w6vOjg7j6MRbadB0OfiPPBYwAAB/ewADZXTlgAAM4IUAAAnY8YAABghBA=
Thread-topic: [Xen-devel] [PATCH 1/5] Add MSI support to XEN
>From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx] 
>Sent: 2008年3月28日 17:33
>
>On 28/3/08 09:23, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
>
>> I think the reverse. :-) Here IRQ is just a namespace which 
>is allocatable
>> and not bound to platform hard-wired logic. Each MSI just 
>requires one
>> IRQ placeholder to gear to evtchn core with the latter on 
>top of IRQ name-
>> space. However GSI or ISA IRQ more indicates platform attribute which
>> doesn't fit the purpose here, though GSI can be also tweaked in some
>> version of Linux kernel.
>
>I don't understand you. Do you mean *PIRQ* is just a namespace which is
>allocatable? I fully agree with that. I was talking about the
>MAO_IRQ_TYPE_IRQ binding type -- here I believe 'IRQ' does 
>refer to a real
>platform resource, but 'IRQ' is not a well-defined 
>architectural namespace
>like 'GSI' or 'ISA IRQ'. So the interface should be fixed imo.

Oh, I jumped in too early. Sorry and you're right.

>
>> This should work, and may solve the issue Yunhong described in
>> another mail by giving Xen ability to mask device directly upon
>> spurious interrupts. And... seems like less change to Linux code?
>> The only concern is how complex the interface may finally go,
>> and in this case Xen still needs to sync PCI config space access
>> for port I/O style.
>
>Yes, the synchronisation is pretty easy though. We just have 
>to add a layer
>of emulation to PV guest accesses to 0xcf8/0xcfc.

Yes, a small tricky however is, the owner vcpu may be scheduled
out between 0xcf8 and 0xcfc access, when another pcpu is trying
to access PCI config space like masking MSI within do_IRQ...
Maybe Xen need to emulate 0xcf8/0xcfc pair without return to 
guest in the middle. :-)

Thanks,
Kevin

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