Re: xen interrupt system

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

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. 

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

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. 

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