RE: [Xen-devel] Re: APIC rework

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

Keir Fraser wrote:
> On 18/11/2009 03:25, "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx> wrote:
> 
>>> For modern dom0 don't we already assume that dom0 pirq == irq == gsi
>>> (see comments in ioapic_guest_write)? Perhaps we should just have
>>> that relationship set up by default: I think only NetBSD dom0 has
>>> different, and it will establish different relationship via legacy
>>> method of PHYSDEVOP_alloc_irq_vector and paravirtualised IOAPIC
>>> writes?
>> 
>> The assumption should be right for dom0 today, but it still needs to
>> register this info to dom0's private data(d->arch.{pirq_irq,
>> irq_pirq). 
>> And I think maybe we should clean up the logic and let hypervisor
>> knows the assumption, when consulting this relationship.
> 
> Well, it strikes me that existing MAP_PIRQ_TYPE_GSI fills this role
> already, as it is, doesn't it? Seems to me that is its whole purpose.
> :-) 
> 
> 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. 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. 
Xiantao

Attachment: x86-add-a-new-physdev_op.patch
Description: x86-add-a-new-physdev_op.patch

Attachment: 0001-x86-ioapic-Remove-Xen-s-specific-changes-about-ioa.patch
Description: 0001-x86-ioapic-Remove-Xen-s-specific-changes-about-ioa.patch

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