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

[Jeremy Fitzhardinge]

Eric W. Biederman wrote:
> Jeremy Fitzhardinge <jeremy@xxxxxxxx> writes:
>
>   
> > Yes, I suppose we can statically partition the irq space.  In fact the original
> > 2.6.18-xen dom0 kernel does precisely that, but runs into limitations because of
> > the compile-time limit on NR_IRQS in that kernel.  If we move to a purely
> > dynamically allocated irq space, then having a sparse allocation if irqs becomes
> > reasonable again, for msis and vectorless Xen interrupts.
> >
> >     
> > > The difference is that the xen sources are not delivered using vectors.  The cpu
> > > vector numbers we do hide and treat as an implementation detail.  And I am totally
> > > happy not going through the vector allocation path.
> > >
> > >       
> > Right.  And in the physical irq event channel case, the vector space is managed
> > by Xen, so we need to use Xen to allocate the vector, then program that into the
> > appropriate place in the ioapic.
> >     
>
> We should be able to share code with iommu for irqs handling, at first glance you
> are describing a pretty similar problem.  Now I don't know think the interrupt
> remapping code is any kind of beauty but that seems to be roughly what you
> are doing with Xen domU.  I certainly think with some careful factoring
> we can share the ioapic munging code.  And the code to pick how we program
> the ioapics.
>   

Notwithstanding the possibility that there'll be general changes to x86 
interrupt handing in the future, do you have any objection to my patches 
as they stand?  Ingo would like to see your and/or hpa's ack before 
accepting them.

Should I repost them?

Thanks,
   J
--
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/