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

[Xen-devel] RE: [PATCH] bind passthroug pci device interrupt pins to INT

To: "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx>
Subject: [Xen-devel] RE: [PATCH] bind passthroug pci device interrupt pins to INTA
From: "He, Qing" <qing.he@xxxxxxxxx>
Date: Tue, 20 May 2008 17:23:49 +0800
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 20 May 2008 02:25:40 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C4585066.20D96%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: <37E52D09333DE2469A03574C88DBF40F01E37EEE@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C4585066.20D96%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Aci6Mr/R/n520XTdTZqyrk6Z5fIzOwAJGc7yAAALffA=
Thread-topic: [PATCH] bind passthroug pci device interrupt pins to INTA

>-----Original Message-----
>From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
>Sent: 2008年5月20日 16:55
>To: He, Qing
>Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
>Subject: Re: [PATCH] bind passthroug pci device interrupt pins to INTA
>
>
>
>
>On 20/5/08 05:34, "He, Qing" <qing.he@xxxxxxxxx> wrote:
>
>> The original scheme is to use the interrupt pin in the physical pci
>> configuration space. However, the use of interrupt pins other than INTA
>> will likely cause problem when the number of assigned devices exceeds 8,
>> e.g. dev 3, INTB and dev 11, INTA share the same girq. In this case, one
>> machine may be left untracked and masked, any devices using the same
>> machine irq (including those owned by other domains) is then blocked.
>>
>> Just wonder if there is any need to expose multifunction devices (i.e.
>> have to use INTB, etc.) to the guest in the future.
>>
>> All comments and suggestions are welcomed.
>
>Could you set the INT line to the function number? FN0->INTA, FN1->INTB,
>...? This would then work for multi-fn devices, yet still most devices have
>only fn0 and hence would use INTA as you desire.

The case that makes me want to change this is the USB assignment. If I assign 
all USB stuff to a guest, that's already 8 functions within 2 devices using all 
the INTA to INTD. Guest gsi sharing will be very likely to happen if I assign 
another one or two device.

There are other options I can think of, including
(a) support sharing of guest gsi. This may also be good for PIC guest where 
sharing is more common. However, eoi and unmask of sharing guest gsi would be a 
pain, if they have different machine irqs. The implementation is subjected to 
careful considerations of corner cases.
(b) change the device model slot allocation policy, to ensure that guest gsi 
sharing devices also have the same machine irq. This solution reduces the 
flexibility.
(c) dynamic routing table, which I assume is not desirable.


(a) may be the better way to go, but at the cost of additional complexity. 
Also, it does not look very good to me that a guest gsi has to link to multiple 
machine irqs, especially in EOI handling part. While simply pins interrupt pins 
to INTA works fine in most cases and it's stupidly simple compared with other 
options.

Thanks,
Qing
>
> -- Keir
>


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