Re: [patch 23/26] x64, x2apic/intr-remap: MSI and MSI-X support for interrupt remapping infrastructure

[Eric W. Biederman]

Suresh Siddha <suresh.b.siddha@xxxxxxxxx> writes:

>> 
>> Can we simplify this a little.  In particular have a function
>> 
>> struct IOAPIC_ROUTE_entry x86_map_irq(irq, mask);
>> 
>> Where x86_map_irq would ultimately figure out the path to the cpu.
>> In the simple case it would just call assign_irq_vector();
>> When irqs are remapped it would perform the additional
>
> But we already know that the irq's are remapped, as we are using different
> irq_chip's when irq's are remapped.
>
>> map_irq_to_irte_handle();
>> modify_irte(irq, &irte);
>> 
>> And then have the generic msi code and the ioapic code.
>> Map from the struct IOAPIC_ROUTE_entry or whatever to the appropriate bits for
> the hardware
>> they control.
>> 
>> That should allows us a lot more flexibility going forward with less code then
> is in your
>> patches.
>
> Are you talking about the setup code or the migration code? Because in migration
> code, we don't even touch MSI/IO-apic devices (for edge atleast) and we
> already use different irq_chip's for that.

I guess I was looking at the setup code.

At any rate the way the code is currently factored does not lend itself easily
to adding another iommu, and things that could be common aren't so maintenance
is harder then it should be.  If we continue on the current path I'm scared
of what that code will look like when we add Xen, VMware, kvm, lguest, and
AMD iommu support in the coming months.

ppc64 and sparc64 seem to have a subarch model where the chipset and
cpu capabilities are pretty standard.  Unfortunately x86 (as usual)
looks like it will become much more pick and choose so I don't think
we can just reuse any of the techniques those other architectures have
done.

What I am ultimately looking for is the x86 iommu irq mapping api.
And how we handle irqs in the context of it.

So as a start I think we can create x86_map_irq, as I suggested.
Since we have the pci dev to lookup the iommu then we really shouldn't
need multiple irq_chip structures (although it may be worth it if we
can detect we can optimize irq migration).

I just don't want to have a MxN problem where we have to implement
every kind of irq chip handler with every kind of iommu if I can help
it.  Even Mx2 starts looking pretty nasty.

> For initial setup, I agree that it can use some simplifications. It's getting
> late here and I will look at all your suggestions tomorrow.

Sounds good.

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/