kernel: supervisor trap asynchronous system trap, code=0

Hi,
I've been working on the Xen interrupt code, especially to
fix the places
where it reenable interrupts without checking for pending
interrupts
(which could cause interrupts to be deffered until the next
IRQ
or hypercall), see attached diff.

With this, I get a
kernel: supervisor trap asynchronous system trap, code=0
when running a HVM guest (it may not be related to the HVM
code, it may just
be because of the high interrupt load).
The trap consistenly hapens in i386_copyin, on the loop
copying the data,
called from syscall_plain() through the uvm and ffs code.
As I understand it, AST should only happen for user context,
and here it
seems to occur in a kernel context. I'm not sure why this
happens and
I can't see how my patch would change anything in this area
(it can just
make a bug shows up more easily by calling the interrupt
handlers more
agressively). Especially it doesn't add any movl $T_ASTFLT
AFAIK.
Any idea ?

-- 
Manuel Bouyer <bouyerantioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la
difference
--

On Thu, Jun 28, 2007 at 12:18:44AM +0200, Manuel Bouyer
wrote:
> Hi,
> I've been working on the Xen interrupt code, especially
to fix the places
> where it reenable interrupts without checking for
pending interrupts
> (which could cause interrupts to be deffered until the
next IRQ
> or hypercall), see attached diff.
> 
> With this, I get a
> kernel: supervisor trap asynchronous system trap,
code=0
> when running a HVM guest (it may not be related to the
HVM code, it may just
> be because of the high interrupt load).
> The trap consistenly hapens in i386_copyin, on the loop
copying the data,
> called from syscall_plain() through the uvm and ffs
code.
> As I understand it, AST should only happen for user
context, and here it
> seems to occur in a kernel context. I'm not sure why
this happens and

I found it: in alltraps, if there was pending interrrupt the
code would jump
back to processing ASTs without checking if it's a user or
kernel context.

The attached diff works fine for me, and includes the fix
for the
read_psl() == 0 assertion failure proposed by Kazushi
Marukawa (fixed to
handle deffered interrupts).

I'll commit it in a few hours, but it would still be good if
someone could
double-check it 

-- 
Manuel Bouyer, LIP6, Universite Paris VI.          
Manuel.Bouyerlip6.fr
     NetBSD: 26 ans d'experience feront toujours la
difference
--