[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] Re: APIC rework
Keir Fraser wrote: > Xiantao, > > Responding inline below with stupid/basic questions. Just want to go > back to first principles with this and work out which of us is on the > wrong track. > > On 17/11/2009 14:17, "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx> 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. > > So dom0 doesn't write the IOAPIC *at all*? Okay. Dom0 won't write ioapic in new dom0, and all operations related to ioapic should be dummy, won't trap to hypervisor any more. >> 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. > > Why does this need to be done under dom0 control? All GSIs are > parseable by Xen by itself aren't they, from MPBIOS tables or ACPI > MADT? So at least Xen should be able to work out for itself APIC pin > -> GSI mappings, and pol/trig settings. I agree with you at this point, and Xen should has the ability to parse the info, but current Xen should doesn't have. A clean way is to do this in hyervisor and dom0 only ask the request about GSI IRQ, like MSI does today. >> 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. > > 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. Xiantao _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |