RE: [Xen-devel] Re: APIC rework

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

Jeremy Fitzhardinge wrote:
> On 11/24/09 02:04, Zhang, Xiantao wrote:
>>> Shoehorning trig/pol information into it as well is kind of nasty.
>>> And I think on any PC system it should suffice to assume GSI 0-15
>>> are ISA edge-triggered active-high, GSI 16+ are PCI level-triggered
>>> active-low, and any exceptions are parsed out of MADT or MPBIOS. We
>>> pretty much have all that code, it just might need plumbing back in
>>> a little bit. Yunhong points out that ACPI DSDT can have overriding
>>> objects in the _PRT, but I don't know it ever actually gets used on
>>> real-world PC systems. So I would try without, but if we do end up
>>> needing to get this info from dom0, I think it should be via a new
>>> physdev_op. 
>>> 
>> At least dom0 parses this info from DSDT, so we can't have the
>> assuption whether it is used or not, I think. 
> 
> Could you clarify this?  Are you saying that Xen can't use the DSDT
> because dom0 does?

Dsdt parsing needs AML interpreter, and Xen hasn't this interpreter, so it 
can't get the info.

>>  And I also agree to add a new physdev_op to handle this case, and
>> it should be better way to go. 
>> Based on this idea, I worked out the patch, attached!  In this
>> patch, we introduced a new physdev_op PHYSDEVOP_setup_gsi for each
>> GSI setup, and each domain can require to map each GSI in this case.
>> In addition, I believe it is very safe to port the hypervisor patch
>> to xen-3.4-x tree and keeps pv_ops dom0 running on it, since no
>> logic is changed.  BTW, I also tested apic and non-apic cases, they
>> works fine after applying the patches.   
> 
> Could you resend the Linux patch as a delta against your previous
> patch?  It makes it easier both to see how things are evolving, and
> also so I can reuse previous merges.
> 
> What branch/version is your diff against?

I'm against the branch origion/xen/master instead of origin/xen/master-xiantao. 
 And the base commit is 
"b9160b12ecc71 ". 

> Do we still need the dummy APIC mappings?  Can anything end up
> touching them?

Yes, we still have the dummy mapping in this patch, since ioapic logic and 
ioapic info(such as GSI info, the info device link with ioapic) parsing are not 
split separately in current Linux. 
If we want to end up this, we have to modify much logic in upstream. 
Xiantao


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