Re: Xen modules

[John Nemeth <jnemeth%cue.bc.ca@localhost>]

On Oct 31, 11:58am, John Nemeth wrote:
}
}      As some of you may seen from my post to tech-kern, I've been
} working on getting modules to work with Xen.  At this point, I have
} build.sh building and installing Xen specific modules.  I also have
} kernels finding the appropriate modules.  amd64 fails to load
} modules due to an issue with module_map.  So, I figured I would
} work on i386 first.  This is panicing due to a failed call to
} hypervisor function.  The panic message is:
} 
} # modload example
} XXX: mapsize = 695
} panic: xpq_flush_cache, err -22
} cpu0: Begin traceback...
} 
vpanic(c05023d3,d78f8ce0,d78f8cfc,c0466846,c05023d3,ffffffea,c,c1230d40,c122f140,c057f140)
 at netbsd:vpanic+0x117
} 
panic(c05023d3,ffffffea,c,c1230d40,c122f140,c057f140,c046f260,0,d78f8d2c,c039ced2)
 at netbsd:panic+0x18
} xpq_flush_cache(0,0,1,0,0,c057f1b0,0,c1233000,c039ce60,c1233000) at 
netbsd:xpq_flush_cache+0x66
} xc_thread(c1233000,860000,c05dc200,0,c010007b,0,0,0,0,0) at 
netbsd:xc_thread+0x72
} cpu0: End traceback...
} 
} And, the code where it panics is:
} 
} void
} xpq_flush_cache(void)
} {
}       struct mmuext_op op;
}       int s = splvm(), err;
} 
}       xpq_flush_queue();
} 
}       XENPRINTK2(("xpq_queue_flush_cache\n"));
}       op.cmd = MMUEXT_FLUSH_CACHE;
}       if ((err = HYPERVISOR_mmuext_op(&op, 1, NULL, DOMID_SELF)) < 0) {
}               panic("xpq_flush_cache, err %d", err);
}       }
}       splx(s); /* XXX: removeme */
} }
} 
} As best I can tell, err -22 is EINVAL.  Anybody know what's up with this?

     Okay, I tracked the problem down.  The problem is that
sys/arch/i386/i386/kobj_machdep.c::kobj_machdep() calls wbinvd().
WBINVD is an x86 CPU instruction to invalidate writeback cache
lines.  This is not an unreasonable thing to want to do when loading
code into the kernel.  sys/arch/xen/x86/xenfunc.c::wbinvd() simply
calls xpq_flush_cache() (seen above).  The MMUEXT_FLUSH_CACHE op
is not allowed in unprivileged domains.

     Thus, this is NOT a module bug at all, but rather loading
modules tickles a latent bug in our Xen code.  For now, I ignore
the error instead of panic()ing.  It would be better not to make
the call at all, but I don't (yet) know how to test for privileges.

     Having made this change, I can now successfully load simple
modules.  I need to go on and test more complex modules.

}-- End of excerpt from John Nemeth