Re: Re: APIC rework

[Jeremy Fitzhardinge <jeremy@goop.org>]

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