Kevin Lawton wrote:
> 
> Ulrich Weigand wrote:
> >
> > > I would have tried to debug the interrupt problem tonight,
> > > but it all went wrong.  The problem is that my base development
> > > PC (this one) is an SMP box, and your kernel module made it go
> > > all wrong with the IPIs, because you don't forward those
> > > to the kernel !
> >
> > Yup, INT 0x30  ('IRQ 16') needs to be forwarded as well.
> > AFAICT you'd only need to add it to mon_irq_handler table ...
> > (It is a little ugly, though :-/)
> 
> OK, let me know if anyone confirms adding this works on an SMP
> machine.  I need to learn more about the APIC, and the
> special IPI messaging.

I'll give it a go.
 
> > > Another thing, it may be that linux expects interrupts to be
> > > on when an interrupt occurs --- I don't know whether it really
> > > matters, but I wouldn't hestitate to make such an assumption
> > > in MY OS code, if I needed to :).  So it may be nice to
> > > sti() BEFORE forwarding the interrupt to the host kernel.
> >
> > Eh?  Linux uses interrupt gates as hardware IRQ vectors, so
> > the interrupt flag is turned *off* before calling the handler.
> > And I'd bet Linux relies on it being off ...
> 
> True enough.  I went groping through the Linux kernel
> sources to see what they were using.

Heh, I was confused, my own code always uses trap gates for IRQs :)
 
> I guess out of anal-ness, and to get in a good habit
> for other host OSes, we should set IF just before calling
> the INT instruction.  It should be the instruction exactly
> one before the INT instruction though.

We shouldn't set IF for an interrupt gate...  but we should for
a trap gate.

What I have in mind is this:  in stead of hardcoding all the
stuff about IRQs and the PIC in monitor.c, we create an
array of structures for each host (in host-*.c) which contains
info on all the interrupts that need to be reflected back
to the host OS, and whether these interrupts are interrupt
or trap gates, etc.  This is the most general way I can think
of.  Then monitor.c loops through this array and generates
interrupt stubs for the interrupts to be reflected from a
standard template.

What do you think ?  Is this a good idea ?  If so, I'll implement
this as part of the cleanup :)

Ramon

Reply via email to