Re: xen interrupt system

[Christoph Egger <Christoph_Egger%gmx.de@localhost>]

On Thursday 20 August 2009 14:02:49 Manuel Bouyer wrote:
> On Thu, Aug 20, 2009 at 01:04:17PM +0200, Christoph Egger wrote:
> > - SMP-safety for the SMP feature
>
> I'm not sure it's a lot of work to add this to the actual system.
> It's mostly a matter of adding locks at the right place.
> Anyway I think improvements are possible here, especially in the say
> masked interrupts are handled. Using bitmasks of pending SPLs doens't
> work great any more as the number of possible levels are quite low now.
> I think 2 ways needs to be investigated:
> - using Xen's interrupt pending bitmasks from spllower(). The
>   advantage is that masked interrupts won't cause a context switch
>   from hypervisor to guest any more. The downside is an increased
>   complexity of spllower() and doreti which needs to check pending Xen
>   interrupts in addition to software interrrupts. As this would be
>   increased complexity in a criticial path, this needs to be carefully
>   benchmarked.
> - Keeping a code similar to the one we have now, but with a hash
>   to map xen's interrupts to more bits in the bitmap we have now.
>   The hash function needs to be carefully though for proper
>   distribution.
>
> At this time I've not decided which one is better.
>
> > - must be able to coexist with any native interrupt system (PV drivers
> > for HVM guests)
>
> This is a lot of work. As I already said, it doens't affect only Xen
> but also x86, and quite deeply. The x86 interrupt system isn't designed to
> coexist with anything else. I don't think this is the way to go.
>
> 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.

> > - 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.

> I think the last issue is orthogonal to the first two of them.
> The way ioapics are setup is quite independant from how interrupts are
> handled when they come it.

Yes, you are right.

Christoph