Re: [Xen-devel] Re: APIC rework

[Jeremy Fitzhardinge <jeremy@xxxxxxxx>]

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?

>  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?

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

Thanks,
    J

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