Re: xen interrupt system

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Thu, Aug 20, 2009 at 02:40:45PM +0200, Christoph Egger wrote:
> > I think the best way to handle this is to use a software interrupt (or
> > maybe two if we need something else than IPL_VM interrupts). The impact to
> > the x86 code would be minimal. The Xen interrupt handler would just
> > trigger the software interrupt , this would be very minimal code.
> >
> > We would then have 3 interrupts systems: the x86 interrupt system,
> > the Xen full-PV interrupt system and the Xen interrupt system for
> > PV drivers in x86.
> 
> I know it is a lot of work. That's why noone has taken this TODO item.
> And doing it doesn't give us the said features automatically but is a
> major step forward in getting them.

At first glance I think rototilling the current interrupt system isn't even a
step in this direction (or if it is, a very small one) because the
2 systems will be different anyway.

> 
> > > - improve ioapic handling (I get below Xen messages during boot)
> >
> > This is the real issue for recent Xen, because they changed the way
> > ioapics are handled. We need to understand how it was changed.
> 
> These are the relevant diffs:
> http://xenbits.xensource.com/staging/xen-unstable.hg/rev/722c7e94e764
> http://xenbits.xensource.com/staging/xen-unstable.hg/rev/d33e9aae74c6
> 
> > I'd say that, at first glance, disabling the ioapic at attach time
> > using vector 0 doens't work any more. This is probably requiring a minor
> > rework of x86/x86/ioapic.c
> 
> Why are we doing this in first place ?
> Disabling ioapics doesn't really sound to be right.

Because we don't know the state of the system. So we first
disable all interrupt pins, and then reenable the ones we use.
Maybe this could be skipped in the Xen case. It's probably worth a try.


-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--