|
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
|
|
|
Home