RE: [Xen-devel] [PATCH 2/3][RFC] MSI/MSI-X support fordom0/driver domain

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx]
>Sent: 2007年5月28日 18:20
>>
>> Who is the very owner to allocate per-domain pirq, domain itself or
>Xen?
>> Or do you mean both sides can allocate by either "caller to specify "
>> or '-1' for auto-allocation?
>
>I mean the caller can decide whether he allocates or whether Xen
>allocates.
>My thinking is that if we made it so that this command needed to be used
>to
>'wire up' MSIs into dom0's pirq namespace, and we're already implicitly
>mapping PHYSDEVOP_alloc_irq_vector()-allocated IRQs into dom0's
>pirq
>namespace, it may be that dom0 has a region of its irq namespace that it
>would like to use for MSIs and, if so, it is best placed to specify the pirq
>parameter for itself. But I would expect that in many/most cases we'd be
>happy to leave the allocation to Xen.
>
>If we wanted to just support one or the other doing the allocation, I would
>say we should leave it to Xen, and make pirq an output-only field (rather
>than in/out, as I specified it).
>
> -- Keir

I have the concern on xen to be involved in pirq allocation. Consider 
the current case where pirq == irq, for INTx type devices of dom0, the 
pirq number is always derived from ACPI table though static, and Xen 
doesn't know such static number before dom0 requests to bind. How 
about a MSI device enabled before an INTx only device? Also xen 
doesn't know the pirq number to be used in the future like hotplug 
case. 

Unless the pirq namespace is really split from irq namespace by a 
non unity mapping style which however also impose changes to other 
INTx devices since all devices need to request pirq allocation from 
Xen then.

So I think it's reasonable to always let dom0 to own the allocation of 
pirq namespace and then notify Xen to register even for MSI type 
device.

Native linux 2.6.18 has a messed namespace management, to 
actually have both vector and irq shared in same space. Later 2.6.20 
keeps them cleanly separate, with each MSI vector also allocated with 
an irq number. Then the syntax of irq in __do_IRQ always indicates the 
irq number and vector is only used when writing to MSI cap fields.

Attached patch for Xen also sticks to 2.6.20 style, to always allocate an
irq number bound with a MSI vector. By this way, Xen still does 
permission control on irq namespace and within dom0 evtchn is still 
mapped to irq namespace. Is it cleaner? :-)

Thanks,
Kevin

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