RE: [Xen-devel] Re: APIC rework

["Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>]

Keir Fraser wrote:
> On 17/11/2009 12:46, "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx> wrote:
> 
>>> If Xen can set the interrupt triggering by itself, why would it ever
>>> need dom0 to do it?  Couldn't it just preconfigure all the pins, and
>>> then wait for dom0 to provide/request the pirq<->evtchn mapping?
>> 
>> After reviewing the logic, I think we can use DOMID_SELF to identify
>> new dom0. In linux-2.6.18 dom0, only qemu uses this hypercall for
>> device assginment, so map->domid shouldn't be dom0.  If old
>> dom0/qemu with this hypercall, keeps the logic unchanged, and only
>> change the logic for new dom0 when call into it. Attached the patch.
> 
> Don't like it (subtle semantic difference based on domid field is
> very odd and could bite us later), and actually now I look closer I
> don't like the original patch much either, if only because it does
> clearly change the interface for MAP_PIRQ_TYPE_GSI by adding
> trigger/polarity flags (and not documented or exported properly in
> the physdev.h header file). 
> 
> I need to take a step back and work out what in fact you're trying to
> achieve. I'm going to revert the original patch from xen-unstable. If
> such an interface extension is really required, I think at least the
> new interface should be a new subtype of MAP_PIRQ_TYPE_xxx, properly
> described in the header file. But like I say, I don't know what the
> patch is even really trying to do or overcome. 

Originally, this patch is target to get rid of ioapic changes in dom0. Before 
this patch, GSI irq should be mapped and setup through dom0 programming ioapic 
entries, but it depends on using ioapic logic in dom0. And if we remove ioapic 
logic from dom0,  we need to find new way how to setup GSI irq.  And this patch 
comes out under this situation.  The idea is from that in Xen the interface 
MAP_PIRQ_TYPE_MSI is used to build the pirq and irq mapping for MSI IRQ for 
each domain. Since MSI IRQ can be setup through this hypercall, and I think  we 
also can leverage the interface MAP_PIRQ_TYPE _GSI to build the mapping for GSI 
irq. Further analysis showes that this interface is only used for assigning 
devices to HVM domain in qemu, and I think it should be Okay for dom0 building 
the mapping between its pirq and irq. One different thing for GSI irq is that 
more info should be provided in the call, since GSI IRQ has different 
trigger-mode and polarity (originally it is provided by ioapic write in dom0). 
Certainly, I also think we need to document the related info, and if you agree 
to the change, I am happy to add it. 
Xiantao
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel