Re: [Qemu-devel] qvm86
kernel: qvm86: unsupported module, tainting kernel. kernel: qvm86: Module loaded kernel: qvm86: Created device 10.62 When I start qemu, it runs without qvm86 acceleration. I have no idea, why it isn't running with qvm86 on this machine. (Doing the same procedure on a debian system, everything is running perfect!) Probably you're not using udev or devfs, so the device node doesn't get created. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qvm86
Hi! I tried to install qvm86 under SuSE Linux Enterprise Server 9 running on a Dual Pentium III with Kernel 2.6.5-7.139-smp. After compiling the module: modprobe qvm86 chmod 666 /dev/qvm86 In /var/log/messages I get the following output: kernel: qvm86: unsupported module, tainting kernel. kernel: qvm86: Module loaded kernel: qvm86: Created device 10.62 When I start qemu, it runs without qvm86 acceleration. I have no idea, why it isn't running with qvm86 on this machine. (Doing the same procedure on a debian system, everything is running perfect!) Thanks for your help! Chris -- Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko! Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qvm86 fails to load (undefined cleanup_module / init_module)
Hi, With current qemu CVS + current qvm86 CVS, after appliing qvm86 patch, I get this build warning: [...] Building modules, stage 2. MODPOST *** Warning: cleanup_module [/tmp/qemu/qemu/qvm86/qvm86.ko] undefined! *** Warning: init_module [/tmp/qemu/qemu/qvm86/qvm86.ko] undefined! CC /tmp/qemu/qemu/qvm86/qvm86.mod.o LD [M] /tmp/qemu/qemu/qvm86/qvm86.ko [...] And then, attempting to load module: $ sudo insmod ./qvm86/qvm86.ko insmod: error inserting './qvm86/qvm86.ko': -1 Invalid module format $ file ./qvm86/qvm86.ko ./qvm86/qvm86.ko: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped I'm using Debian GNU/Linux unstable with kernel-headers-2.6.11-1-k7. Any idea what's going on? -- Robert Millan ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] QVM86, SKAS.. many modules, one vision?
Hi, I recently spent some effort working out what Separate Kernel Address Space (SKAS) did for user-mode-linux (UML). The results of this keen be seen here: http://news.gmane.org/group/gmane.linux.uml.devel/last=/force_load=t on the thread Using SKAS, any examples? the conclusion to this is that with SKAS you can create separate address spaces and map pages (possibly shared) into them. You can then use ptrace to control the execution of something in that separate address space. This is all well and good, but when emulating one instruction set on another the executing code needs to peek and poke the separate address space. With SKAS this can only be done by using a page with a shared mapping, or by executing some host machine code in the separate address space. What would be good is if multi-segments could be enabled and then cs/ds/es could be used by the emulator and fs/gs could map to higher in the linear address space and onto the separate address spaces. These address spaces would then be addressable with just a segment over-ride. It seems these goals are likely in part to be shared by qvm86 and kqemu. Is it worth working toward a unified Linux module specifically for emulation? Regards, Ian Rogers - http://www.cs.manchester.ac.uk/apt/projects/jamaica - http://www.binarytranslator.org/ ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QVM86, SKAS.. many modules, one vision?
Paul Brook wrote: For user-mode emulation the largest chunk of address space is the translated code buffer. This needs to be able to directly address the guest memory space, so sharing a VM with the host qemu process isn't really a problem. We just map the host qemu out of the way somewhere. This is different from native UML where with SKAS you can run applications without any foreign areas mapped into the guest address space. Yup, but if you are emulating more than just a user process (ie a whole OS), or you can't guarantee the security of the user process (ie it could go messing with the translation cache), then just mapping things elsewhere is just adopting the ostrich position. Multi-segments are an obvious way to solve this but currently there's little support in the OS. modify_ldt works quite well, you can hide the translation cache below it, but it means you can't map pages at the end of the address space. That's why some module support would be good. Regards, Ian Rogers ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QVM86, SKAS.. many modules, one vision?
On Monday 09 May 2005 10:09, Ian Rogers wrote: Hi, I recently spent some effort working out what Separate Kernel Address Space (SKAS) did for user-mode-linux (UML). The results of this keen be seen here: http://news.gmane.org/group/gmane.linux.uml.devel/last=/force_load=t on the thread Using SKAS, any examples? the conclusion to this is that with SKAS you can create separate address spaces and map pages (possibly shared) into them. You can then use ptrace to control the execution of something in that separate address space. This is all well and good, but when emulating one instruction set on another the executing code needs to peek and poke the separate address space. With SKAS this can only be done by using a page with a shared mapping, or by executing some host machine code in the separate address space. What would be good is if multi-segments could be enabled and then cs/ds/es could be used by the emulator and fs/gs could map to higher in the linear address space and onto the separate address spaces. These address spaces would then be addressable with just a segment over-ride. It seems these goals are likely in part to be shared by qvm86 and kqemu. Is it worth working toward a unified Linux module specifically for emulation? IIUC SKAS doesn't give you access to the full address space. It just creates a new process, giving you a clean linux userspace. For full system emulation this isn't sufficient, you need to full address space. For user-mode emulation the largest chunk of address space is the translated code buffer. This needs to be able to directly address the guest memory space, so sharing a VM with the host qemu process isn't really a problem. We just map the host qemu out of the way somewhere. This is different from native UML where with SKAS you can run applications without any foreign areas mapped into the guest address space. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
