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

RE: [Xen-devel] Re: APIC rework



Jeremy Fitzhardinge wrote:
> On 11/17/09 06:17, Zhang, Xiantao wrote:
>> 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.                 
>> 
> 
> I don't think there's any need to overload the existing interface
> though.  If we're adding new functionality then we can add a new
> interface for it (but with luck we can reuse most of the existing code
> to implement it).

> If you're already considering a "treat this differently" flag in the
> argument, then that's a strong pointer that a new interface is
> warranted. 

Agree, and I also don't object to add a similar interface.  
Since this existing interface is only used for hvm domain before, and  just 
want to re-use it for dom. 


> But also consider the question whether Xen needs to get triggering
> info from dom0 at all, or whether it can correctly derive that info
> from its own parsing of the relevant tables.

Xen should have the ability to parse the info, but may need more logic porting 
to hyervisor. 

Xiantao


_______________________________________________
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®.