WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: [PATCH 02/18] xen: hook io_apic read/write operations

To: Ingo Molnar <mingo@xxxxxxx>
Subject: [Xen-devel] Re: [PATCH 02/18] xen: hook io_apic read/write operations
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Mon, 11 May 2009 11:25:16 -0700
Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, the arch/x86 maintainers <x86@xxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Jeremy Fitzhardinge <jeremy.fitzhardinge@xxxxxxxxxx>
Delivery-date: Mon, 11 May 2009 11:25:51 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20090511111904.GK4648@xxxxxxx>
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>
References: <1241730883-4917-1-git-send-email-jeremy@xxxxxxxx> <1241730883-4917-3-git-send-email-jeremy@xxxxxxxx> <20090509084201.GF3656@xxxxxxx> <20090509084324.GA5158@xxxxxxx> <4A05A408.3020006@xxxxxxxx> <20090511111904.GK4648@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.21 (X11/20090320)
Ingo Molnar wrote:
Hm, every time you see this code, you always have this quasi-Pavlovian response.

Yep, my reaction to ugly code is pretty predictable, and (hopefully!) repeatable. So calling it Pavlovian is an implicit (albeit, i suspect, unintended ;-) compliment.

My frustration is that you've generally not replied, and so we haven't been able to discuss it. Could you be more specific about what's triggering the reaction? Is it that the change is happening at the io-apic level, or that its some explicit Xen code pasted in here rather than via an io_apic_ops?

You say "use an irqchip".  I say:

   * We already use irqchip
   * but most of the interesting IO apic accesses (routing) are not
     done via the irqchip interface
   * so irqchip doesn't help

I dont see the problem. All APIs within Linux are kept minimalistic and are extended on the fly, on an on-demand basis.

Sure, where it makes sense. One wouldn't start extending an API in a completely different direction. irq_chip currently only deals with "irqs"; what those irqs mean and connect to are not its business because that has all been set up elsewhere. If you start adding interrupt routing, then it starts needing to know about devices, busses, etc. I can't see how that makes much sense at all, particularly for an arch-independent interface.


Well, my main task at this stage is to point out ugly code. I might be able to do research for you and come up with a plan for you, but that's really a courtesy in general and is not always possible for maintainers. You might argue "of all possible solutions this is the cleanest" but i havent seen you make that point.

I'd love to, but Plato isn't taking my calls so I can't check.

But I do think hooking the io-apic operations makes more sense than any other solution because we explicitly want all the other code above it. The *only* difference between a Xen io-apic and a native io-apic is that we need to access the registers with hypercalls rather than mmio. Same registers, same meanings, same settings made at the same time. So the io-apic accessors are at precisely the right level of abstraction for our needs; introducing something higher-level would be an abstraction impedance mismatch, and would be no better for it.

An io_apic_ops makes sense to me, if adding it would stop triggering your ugly-code detector. But that's specifically what HPA objected to in this series...

   J

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