Re: [PATCH 30 of 38] xen: implement io_apic_ops

[Eric W. Biederman]

Jeremy Fitzhardinge <jeremy@xxxxxxxx> writes:

> Ingo Molnar wrote:
>> * Jeremy Fitzhardinge <jeremy@xxxxxxxx> wrote:
>>
>>
>>> Writes to the IO APIC are paravirtualized via hypercalls, so implement
>>> the appropriate operations.
>>>
>>> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@xxxxxxxxxx>
>>> ---
>>>  arch/x86/xen/Makefile    |    3 +-
>>> arch/x86/xen/apic.c | 66 ++++++++++++++++++++++++++++++++++++++++++++++
>>>  arch/x86/xen/enlighten.c |    2 +
>>>  arch/x86/xen/xen-ops.h   |    2 +
>>>  4 files changed, 72 insertions(+), 1 deletion(-)
>>>
>>
>> hm, why is the ioapic used as the API here, and not an irqchip?
>>
>
> In essence, the purpose of the series is to break the 1:1 relationship between
> Linux irqs and hardware GSIs.

Bad idea (I think).  We have a 1:1 relationship between the linux irq number and
the GSI because it makes the code dramatically simpler, and it took significant
work to get there.  The concept of an intermediate mapping layer sounds nasty.
But I haven't yet read the patch.

> If the x86 interrupt layer in general decouples irqs from GSIs, then I can
> probably make use of that to clean things up.  A general irq allocator along
> with some way of attaching interrupt-source-specific information to each irq
> would get me a long way, I think.  I'd still need hooks to paravirtualize the
> actual ioapic writes, but at least I wouldn't need to have quite so much
> delicate hooking.

I know that is where I thought the sparse irq code was going.

Eric

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/