xen-devel
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
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: [Xen-devel] Re: APIC rework, (continued)
- Re: [Xen-devel] Re: APIC rework, Keir Fraser
- RE: [Xen-devel] Re: APIC rework, Zhang, Xiantao
- Re: [Xen-devel] Re: APIC rework, Keir Fraser
- RE: [Xen-devel] Re: APIC rework, Zhang, Xiantao
- Re: [Xen-devel] Re: APIC rework, Jeremy Fitzhardinge
- RE: [Xen-devel] Re: APIC rework, Zhang, Xiantao
- Re: [Xen-devel] Re: APIC rework, Konrad Rzeszutek Wilk
- RE: [Xen-devel] Re: APIC rework, Zhang, Xiantao
- Re: [Xen-devel] Re: APIC rework, Keir Fraser
- RE: [Xen-devel] Re: APIC rework, Jiang, Yunhong
- RE: [Xen-devel] Re: APIC rework,
Zhang, Xiantao <=
- Re: [Xen-devel] Re: APIC rework, Keir Fraser
- RE: [Xen-devel] Re: APIC rework, Zhang, Xiantao
- Re: [Xen-devel] Re: APIC rework, Jeremy Fitzhardinge
- RE: [Xen-devel] Re: APIC rework, Zhang, Xiantao
- Re: [Xen-devel] Re: APIC rework, Konrad Rzeszutek Wilk
- Re: [Xen-devel] Re: APIC rework, Jeremy Fitzhardinge
- Re: [Xen-devel] Re: APIC rework, Konrad Rzeszutek Wilk
- Re: [Xen-devel] Re: APIC rework, Jeremy Fitzhardinge
- Re: [Xen-devel] Re: APIC rework, Konrad Rzeszutek Wilk
- RE: [Xen-devel] Re: APIC rework, Zhang, Xiantao
|
|
|