|
xen-devel
RE: [Xen-devel] [PATCH 1/5] Add MSI support to XEN
|
To: |
"Tian, Kevin" <kevin.tian@xxxxxxxxx>, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx>, "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>, "xen-devel" <xen-devel@xxxxxxxxxxxxxxxxxxx> |
|
Subject: |
RE: [Xen-devel] [PATCH 1/5] Add MSI support to XEN |
|
From: |
"Shan, Haitao" <haitao.shan@xxxxxxxxx> |
|
Date: |
Fri, 28 Mar 2008 18:03:22 +0800 |
|
Cc: |
"Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>, "Li, Xin B" <xin.b.li@xxxxxxxxx> |
|
Delivery-date: |
Fri, 28 Mar 2008 03:03:54 -0700 |
|
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxx |
|
In-reply-to: |
<D470B4E54465E3469E2ABBC5AFAC390F024D9147@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> |
|
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> <D470B4E54465E3469E2ABBC5AFAC390F024D9147@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> |
|
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
|
Thread-index: |
AciP14w6vOjg7j6MRbadB0OfiPPBYwAAB/ewADZXTlgAAM4IUAAAnY8YAABghBAAAJu6sA== |
|
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.
I will change that name.
>
>>
>>> 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. :-)
Can we add hypercall to combine the two-time access to one?
>
> Thanks,
> Kevin
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
Home