xen-devel
Re: [Xen-devel] Re: APIC rework
To: |
"Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>, Jeremy Fitzhardinge <jeremy@xxxxxxxx> |
Subject: |
Re: [Xen-devel] Re: APIC rework |
From: |
Keir Fraser <keir.fraser@xxxxxxxxxxxxx> |
Date: |
Wed, 18 Nov 2009 09:37:00 +0000 |
Cc: |
Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Han, Weidong" <weidong.han@xxxxxxxxx>, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx> |
Delivery-date: |
Wed, 18 Nov 2009 01:37:31 -0800 |
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
In-reply-to: |
<706158FABBBA044BAD4FE898A02E4BC201CD3207E0@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> |
List-help: |
<mailto:xen-devel-request@lists.xensource.com?subject=help> |
List-id: |
Xen developer discussion <xen-devel.lists.xensource.com> |
List-post: |
<mailto:xen-devel@lists.xensource.com> |
List-subscribe: |
<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> |
List-unsubscribe: |
<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> |
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
Thread-index: |
AcpnRahRKdY8JG4aRBKJtSOrmCF95gAPb6tAAADLjVUAAFOzQAANzk5eAA9qNnAADXnVJA== |
Thread-topic: |
[Xen-devel] Re: APIC rework |
User-agent: |
Microsoft-Entourage/12.19.0.090515 |
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.
-- Keir
_______________________________________________
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, 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
- Re: [Xen-devel] Re: APIC rework, Konrad Rzeszutek Wilk
|
|
|