Eric Lowe wrote: > Roland Mainz wrote: > ... > >> As far as the install times, I think you'll see it is a lot better with > >> the kernel accelerator module. I just installed Ubuntu Dapper Drake > >> under QEMU on my AMD64 machine and it took about 20 minutes. I'm hoping > >> we can get the OpenSolaris accelerator into the next kqemu release. > > > > What about security in this case ? Does the kernel accelerator module > > execute any native code within the kernel context ? > > kqemu has two modes. In the first (and default) mode, all privileged > code is simulated and the user code runs natively. In the second mode, > the privileged code runs as a user process and the user code runs > natively. In either mode, all guest code executes in ring 3, and only > the kqemu module runs in ring 0. > > All kernel memory which is allocated by the kqemu module is zero'd for > safety. This is required by the kqemu API. > > Currently the OpenSolaris port of kqemu requires only permissions to > access the device node. Least privilege is currently not supported, and > if it was, only locked memory would need to be checked (I opted not to > add this support so that the 32-bit module can work on older kernels > like Solaris 8 without recompilation). In the future, we could add RBAC > support, so users can be given a kqemu role, and use pfexec to invoke > qemu... but I don't know if it's worth the bother, since kqemu should be > safe (with the exception of possibly causing realtime scheduling jitter).
Erm, I think the RBAC role may be better here, however the default should be a mode which is 100% safe. > If you want to debate this further I would suggest getting on the qemu > project mailing list when it is set up, I'm open to suggestions. Ok (the project isn't open yet, right ?) ... [snip] > > I've seen the 40h+ install time because I was using QEMU/AMD64 on a > > 32bit machine in the normal, "unaccerlated" interpreter mode AND QEmu > > suffers extensively from bugs in the ATA driver, kernel and other parts > > of Solaris. Examples include busy-loops after starting DMA, that the > > kernel doesn't call the x86 "HTL" instruction (which can damage emulator > > performance a lot - normal hardware just stops any execution until the > > next interrupt is hit, but an emulator than stops interpreting of the > > native instructions and does other stuff (including looking at I/O > > registers MUCH earlier (this is also a problem on laptops because it > > wastes energy))) very often and that Solaris has insane memory > > consumtion (or better: The "working set" during several 5-15min samples > > showed that the working set is sometimes beyond 100MB and that more or > > less kills emulator performance, too (unless the underlying host system > > has enougth spare bandwidth)) during install time (who had the idea to > > run JAVA duing installation ?!) ... > > Yep overall it isn't really usable without the accelerator. QEMU ATAPI > DMA support will help a lot, too, though it still doesn't work for a > Solaris guest. Note that it would be nice to ship all "qemu" variants (even those for SPARC (yes I know that they are not really usefull for end-users right now)) and not only the x86 ones. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
