Re: [Qemu-devel] Config file support
Hi, On Tue, 24 Oct 2006, Rob Landley wrote: On Tuesday 24 October 2006 6:47 am, Flavio Visentin wrote: At this point it's really cleaner and maybe simpler to use XML Have you ever implemented a validating XML parser? I have. It only _looks_ clean and simple. +1 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] How to get guestOS's information
Hello, It is impolite to write an unexpected letter. I am a college student in Japan. I belong to information processing system laboratory, and I work on intrusion detection system. We are developing intrusion detection system using system calls. Now, it operates only on Linux. I would like to operate it in more platforms. I think it is possible to found guest OS’s abnormality by observing it from the hostOS. I would be extremely happy if it could be operated on the Qemu. Do you think that it is possible? Now, my system uses only processID and frequency of system calls. In a word, I would like to know how to get gestOS’s information (processID and frequency of system calls). Any help would be greatly appreciated. Regards, kazuya ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] proprietary MIPS based ASIC
Hello, I am a software developer working in a chip maker. One of our chips - dual MIPS 4Kec with GPON/BPON related peripherals, DDR, interrupt contorller, SPI, I2C and UART. This is SoC (System ooon Chip) which should run small chunk of software, like proprietary protocol stack, small RTOS (may be commercial one like Velosity or OSS like eCOS) How hard it is going to be to emulate full system like this ? Any examples/tutorials where to start ? Any experience of porting QEMU to other platforms ? Let's say MIPS+DDR+simple interrupt controller and no other peripherals ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] proprietary MIPS based ASIC
On Thursday 26 October 2006 08:50, [EMAIL PROTECTED] wrote: Hello, I am a software developer working in a chip maker. One of our chips - dual MIPS 4Kec with GPON/BPON related peripherals, DDR, interrupt contorller, SPI, I2C and UART. This is SoC (System ooon Chip) which should run small chunk of software, like proprietary protocol stack, small RTOS (may be commercial one like Velosity or OSS like eCOS) How hard it is going to be to emulate full system like this ? Any examples/tutorials where to start ? Any experience of porting QEMU to other platforms ? Let's say MIPS+DDR+simple interrupt controller and no other peripherals I suggest you look at the existing targets. e.g. the existing mips and ARM targets. IMHO it's not that hard to add new boards. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Config file support
On Wednesday 25 October 2006 11:01 am, Paul Brook wrote: Oh, c'mon, Rob! I really didn't want to ask Paul Brook that, but sure you'll fix my cluelessness right here, right now - tell me, tell me, why Linux has dynamic-loadable modules support, which clueless passers-by like me call plugins? It must be closed-source diversion, no? Linux has genuine reasons for wanting modules. Kernel size is important because (a) it has to be loaded by the bootloader, often from a small, slow device (eg. floppy, flash or network). (b) The whole kernel is permanently locked into ram. It you've ever tried to build a kernel with everything enable you'll know the result is unreasonably large. Modules allow the same kernel to work on a wide variety of large and small machines. It also avoids a reboot cycle when you want to debug small changes to drivers (assuming you didn't crash). Restarting a userspace app (like qemu) takes five seconds. Restarting the kernel can take a minute and change, and often involves pressing a button on a machine that's shoved under a desk and hard to get at. I've found avoiding the reboot cycle to be a nice thing with qemu (and User Mode Linux), but alas you can't test a driver for hardware qemu doesn't emulate. Nice for filesystems and VM stuff, though... Rob -- Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away. - Antoine de Saint-Exupery ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] How to get guestOS's information
On Thursday 26 October 2006 3:23 am, KazuyaMatsunaga wrote: Hello, It is impolite to write an unexpected letter. Compared to the mountains of spam I get every day? Not really. :) I am a college student in Japan. I belong to information processing system laboratory, and I work on intrusion detection system. We are developing intrusion detection system using system calls. Now, it operates only on Linux. I would like to operate it in more platforms. I think it is possible to found guest OS’s abnormality by observing it from the hostOS. I would be extremely happy if it could be operated on the Qemu. Do you think that it is possible? Now, my system uses only processID and frequency of system calls. In a word, I would like to know how to get gestOS’s information (processID and frequency of system calls). If your guest os is using sysenter you could hook that and see how often it's getting called. Or perhaps intercept interrupt 80. That's about the end of my useful suggestions, though. Unfortunately ProcessID is an abstraction that QEMU doesn't know anything about (it's translating machine language instructions and emulating hardware; what it's _doing_ is another matter). Trying to get QEMU to do it is a bit like trying to add hardware to your system to determine which user accounts are accessing your hard drive. Your PCI bus doesn't know what a user account is: it's at the wrong level and that information just isn't present there. You'd have to modify the OS you're running to collect that info, unless you can figure out execatly where in memory it's stored and add some kind of trace to monitor that memory location. (And that location could easily change each time you reboot the system.) I'm guessing you modified Linux to collect this information. To get Windows or Solaris to do it, you'd have to modify those OSes too. Rob -- Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away. - Antoine de Saint-Exupery ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] How to get guestOS's information
Hi, On 26/10/06, KazuyaMatsunaga [EMAIL PROTECTED] wrote: Hello, It is impolite to write an unexpected letter. I am a college student in Japan. I belong to information processing system laboratory, and I work on intrusion detection system. We are developing intrusion detection system using system calls. Now, it operates only on Linux. I would like to operate it in more platforms. I think it is possible to found guest OS's abnormality by observing it from the hostOS. I would be extremely happy if it could be operated on the Qemu. Do you think that it is possible? Now, my system uses only processID and frequency of system calls. In a word, I would like to know how to get gestOS's information (processID and frequency of system calls). This is a bit difficult because these things are not standarised in any way across architectures and across operating systems. If you know that your guest OS is Linux, though, you can quite easily extract this information if you have the kernel's sources (but still not in an architecture independent way), without modifying the kernel or qemu. For example I recently found that on ARM the list of processes and any associated information can be obtained in gdb with: (gdb) print ((struct task_struct *) (((void *) ((struct thread_info *) ($sp ~8191))-task-tasks-next) - 0x6c))-comm then (gdb) print ((struct task_struct *) (((void *) ((struct thread_info *) ($sp ~8191))-task-tasks-next-next) - 0x6c))-comm and so on iterating until you hit the same process again, provided that the kernel's symbol table is loaded. The number 6c is the offset of the field tasks inside the struct task_struct which is defined in include/linux/sched.h which [the offset] is architecture dependent, and the ($sp ~8191) part is the text of the current_thread_info() function, defined in include/asm-arm/thread_info.h and is also arch dependent but should be something similar on i386. The advantage that using gdb has over ps is that it works even before the kernel starts userspace and even after a kernel crash. Now to intercept syscalls it's enough to set breakpoints in the right places. This can be done using gdb or you can make a very simple program that talks to qemu over the gdb protocol. If you're willing to modify qemu, several architectures have a special instruction used for syscalls, like swi on arm and int on i386, which you can easily trap, but it's not obligatory for an OS to use this instruction. As Rob said the only *correct*, and the easiest way is to modify the guest kernel. hth, Andrzej ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] How to get guestOS's information
On 26/10/06, andrzej zaborowski [EMAIL PROTECTED] wrote: Hi, On 26/10/06, KazuyaMatsunaga [EMAIL PROTECTED] wrote: Hello, It is impolite to write an unexpected letter. I am a college student in Japan. I belong to information processing system laboratory, and I work on intrusion detection system. We are developing intrusion detection system using system calls. Now, it operates only on Linux. I would like to operate it in more platforms. I think it is possible to found guest OS's abnormality by observing it from the hostOS. I would be extremely happy if it could be operated on the Qemu. Do you think that it is possible? Now, my system uses only processID and frequency of system calls. In a word, I would like to know how to get gestOS's information (processID and frequency of system calls). This is a bit difficult because these things are not standarised in any way across architectures and across operating systems. If you know that your guest OS is Linux, though, you can quite easily extract this information if you have the kernel's sources (but still not in an architecture independent way), without modifying the kernel or qemu. For example I recently found that on ARM the list of processes and any associated information can be obtained in gdb with: (gdb) print ((struct task_struct *) (((void *) ((struct thread_info *) ($sp ~8191))-task-tasks-next) - 0x6c))-comm then (gdb) print ((struct task_struct *) (((void *) ((struct thread_info *) ($sp ~8191))-task-tasks-next-next) - 0x6c))-comm and so on iterating until you hit the same process again, provided that the kernel's symbol table is loaded. The number 6c is the offset of the field tasks inside the struct task_struct which is defined in include/linux/sched.h which [the offset] is architecture dependent, and the ($sp ~8191) part is the text of the current_thread_info() function, defined in include/asm-arm/thread_info.h and is also arch dependent but should be something similar on i386. The advantage that Yep. Now that I checked, exactly the same except you probably have to replace sp with esp and if you're using 4K stacks then it's 4095 instead of 8191. using gdb has over ps is that it works even before the kernel starts userspace and even after a kernel crash. Now to intercept syscalls it's enough to set breakpoints in the right places. This can be done using gdb or you can make a very simple program that talks to qemu over the gdb protocol. If you're willing to modify qemu, several architectures have a special instruction used for syscalls, like swi on arm and int on i386, which you can easily trap, but it's not obligatory for an OS to use this instruction. As Rob said the only *correct*, and the easiest way is to modify the guest kernel. hth, Andrzej -- balrog 2oo6 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu vs gcc4
On Wed, Oct 25, 2006 at 03:39:18PM -0400, Rob Landley wrote: gcc -Wall -O2 -g -fno-strict-aliasing -I. -I.. -I/home/landley/qemu/nowt.dyndns.org/qemu/target-sparc -I/home/landley/qemu/nowt.dyndns.org/qemu -I/home/landley/qemu/nowt.dyndns.org/qemu/host-i386 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I/home/landley/qemu/nowt.dyndns.org/qemu/fpu -I/home/landley/qemu/nowt.dyndns.org/qemu/slirp -c -o tcx.o /home/landley/qemu/nowt.dyndns.org/qemu/hw/tcx.c /home/landley/qemu/nowt.dyndns.org/qemu/hw/tcx.c: In function ???tcx_draw_line32???: /home/landley/qemu/nowt.dyndns.org/qemu/hw/tcx.c:94: error: invalid lvalue in increment /home/landley/qemu/nowt.dyndns.org/qemu/hw/tcx.c: In function ???tcx_draw_line16???: /home/landley/qemu/nowt.dyndns.org/qemu/hw/tcx.c:106: error: invalid lvalue in increment This is an unrelated problem, and much easier to fix. Don't increment casts. -- Daniel Jacobowitz CodeSourcery ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] proprietary MIPS based ASIC
There exists a QEMU system emulation for AR7 based DSL routers. AR7 is a SoC based on MIPS 4KEc, so some part of the work needed for your system was done there. See http://ar7-firmware.berlios.de/ for more information. Patched QEMU sources are in Subversion on BerliOS. Regards Stefan [EMAIL PROTECTED] schrieb: Hello, I am a software developer working in a chip maker. One of our chips - dual MIPS 4Kec with GPON/BPON related peripherals, DDR, interrupt contorller, SPI, I2C and UART. This is SoC (System ooon Chip) which should run small chunk of software, like proprietary protocol stack, small RTOS (may be commercial one like Velosity or OSS like eCOS) ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] arm-test updated to linux-2.6.18
Hello, I updated the arm-test testcase (from Paul Brook) for linux-2.6.18 (instead of 2.6.17-rc3). See http://free-electrons.com/pub/qemu/demos/arm/arm-test/linux-2.6.18/ I tested it successfully with qemu-0.8.2. Note that I never managed to make the graphics work with the 2.6.17-rc3 version (whatever the qemu version). With this version, everything works great. You may want to update the version on http://qemu.org/download.html with this new one. Cheers, Michael. -- Michael Opdenacker, Free Electrons Free Embedded Linux Training Materials on http://free-electrons.com/training (More than 1000 pages!) ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] How to get guestOS's information
Am Donnerstag, den 26.10.2006, 16:23 +0900 schrieb KazuyaMatsunaga: Hello, It is impolite to write an unexpected letter. I am a college student in Japan. I belong to information processing system laboratory, and I work on intrusion detection system. We are developing intrusion detection system using system calls. Now, it operates only on Linux. I would like to operate it in more platforms. I think it is possible to found guest OS’s abnormality by observing it from the hostOS. I would be extremely happy if it could be operated on the Qemu. Do you think that it is possible? Now, my system uses only processID and frequency of system calls. In a word, I would like to know how to get gestOS’s information (processID and frequency of system calls). Any help would be greatly appreciated. Regards, kazuya hello kazuya! some people here commented on the system call problems. i'd like to say some words about processIDs: You might want to consider useing the Page Directory Base Register (PDBR aka cr3 or in qemu-x86 env-cr[3]) to idenify differnet processes. afaik it is then OS-dependant how to get the corresponding PID. I did this for windows and i assume it's a lot easier to do the same for linux/*BSD (as the source is available). Since you probably will need to check for the current process quite often, the shorter access times for this information might come in handy. cheers m. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] How to get guestOS's information
maestro wrote: You might want to consider useing the Page Directory Base Register (PDBR aka cr3 or in qemu-x86 env-cr[3]) to idenify differnet processes. afaik it is then OS-dependant how to get the corresponding PID. I did this for windows and i assume it's a lot easier to do the same for linux/*BSD (as the source is available). Since you probably will need to check for the current process quite often, the shorter access times for this information might come in handy. Good idea. However, on Linux cr3 is not updated for every process. Specifically, it is not updated for kernel threads which don't have any user-space mappings of their own. This is to avoid unnecessary TLB flushes. -- Jamie ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[FreeSBIE LVC] Re: [Qemu-devel] qemu/hw ide.c
In article [EMAIL PROTECTED] you write: CVSROOT: /sources/qemu Module name: qemu Changes by:Fabrice Bellard bellard 06/08/07 21:36:34 Modified files: hw : ide.c Log message: use AIO for DMA transfers - enabled DMA for CDROMs Hi! I just tried FreeSBIE LVC (see announcement here: http://www.riondabsd.net/2006/10/13/announce-freesbie-lvc-is-out/ ) with qemu cvs (using this experimental port update: http://docs.freebsd.org/cgi/mid.cgi?20061026201752.GA51540 ) and it hung, printing: atapi_poll called! repeatedly on the console. Disabling USE_DMA_CDROM in hw/ide.c made it boot. So this seems to be a variation of the old problem of the cdrom dma patch being incompatible with FreeBSD atapicam. (FreeSBIE still has atapicam in the kernel, and back when the first cdrom dma patch was posted it caused the cd being detected as a disk (da) on an older FreeBSD atapicam guest...) ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
