[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.