[Qemu-devel] Release: VMKNOPPIX(20070328) with Trusted Boot
Dear, We released VMKNOPPIX(20070328) with Trusted Boot. http://unit.aist.go.jp/itri/knoppix/vmknoppix/index-en.html VMKnoppix is a collection of Virtual Machine Software, Xen, KVM, VirtualBox, QEMU, KQEMU(QEMU with Accelerator) and UserModeLinux. This version includes Trusted Boot (Trusted GRUB and IMA: Integrity Measured Architecture). === Features == VM Collection: Xen3.0.4-1(DomainU HVM Domain), KVM16, VirtualBox, QEMU, KQEMU(QEMU with Accelerator) and UserModeLinux. There are many techniques of Virtual Machine, para-virtualization, full-virtualization with virtualization instruction(IntelVT or AMD-V), dynamic translation etc. The VM softwares runs with OS images offered by some sites(For instance OSZoo's QEMU images).Have fun with the techniques! Trusted Boot: Trusted GRUB and IMA(Integrity Measured Architecture) on TPM(Trusted Platform Module)1.2. Caution: The BIOS must deal with Trusted Boot to enable this function. Trusted GRUB: http://trousers.sourceforge.net/grub.html IMA: http://domino.research.ibm.com/comm/research_people.nsf/pages/sailer.ima.html ***Help us***: If you have vTPM on your virtual machine, please boot with this ISO image and report. If possible we want to integrate vTPM on our VMKnoppix and OS Circular. OS Circular: VMKNOPPIX includes Internet Client OS Circular environment. OS Circular enables to boot OSes on Xen with a globalized virtual disk HTTP-FUSE CLOOP. Benchmark: VMKNOPPIX includes benchmark softwares. Pi calculation for CPU benchmark http://h2np.net/pi/pi_quick_start.tar.gz dbench for IO benchmark tbench for Network benchmark Xengine for Graphic Benchmark OProfile: VMKNOPPIX includes xenoprifle to take profile of HVM Domain OS. Quick Boot: VMKNOPPIX is optimized by LCAT for fast CD boot. GRUB Menu: includes three items; Xen3.04-1(kernel 2.6.16.33), IMA(kerenel2.6.19.1) and normal KNOPPIX (kernel 2.6.19). === How to use Virtual Machine = * Xen Boot with the first option KNOPPIX/Xen3.0.4-1 of GRUB. To run DomainU with KNOPPPIX. # knoppixU To run HVM Domain with KNOPPPIX on IntelVT or AMD-V. # knoppixHVM Caution) Add nofirewire kernel option at GRUB Menu for Intel MAC. * OS Circular Boot with the first option KNOPPIX/Xen3.0.4-1 of GRUB on IntelVT or AMD-V. # pump -i eth0 # /etc/inint.d/xend start # httpfuse-hvm.sh Selection Menu will be appeared. Select a near site. Contents Menu will be appeared. Select your favorite image. The OS will be appeared. Current Debian Etch has accounts, root/http-fuse or http-fuse/http-fuse. Caution) Add nofirewire kernel option at GRUB Menu for Intel MAC. Caution) The console must be wider than 80x24to run httpfuse-hvm.sh, because dialog requires wide console. If the console is small, the message httpstoraged is ready ... will continue. The technical detail was presented Virtualization Miniconf at LinuxConfAu07. http://virtminiconf.linux.hp.com/program/os-circulation-environment-201ctrusted-http-fuse-xenoppix201d Slide PDF http://unit.aist.go.jp/itri/knoppix/20070118-LCA-HTTP-FUSE.pdf * VirtualBox Boot with the third option KNOPPIX(normal kernel) on GRUB. # modprobe vboxdrv # VBoxSVC # VirtualBox After that, setup VM environment interactively. The CD-Drive is setup at the main menu after Interactive setup. * kqemu/KVM/QEMU Boot with the third option KNOPPIX(normal kernel) on GRUB. Script qemu-knoppix.sh prepares network environment, shared memory for KQEMU, and drivers for KVM or KQEMU. The priority is as follows. 1) If kvm drivers effective, kvm runs. 2) If kqemu is effective, kqemu runs. 3) If kvm and kqemu aren't available, qemu runs. qemu-knoppix.sh aslo accepts the follwing options. -no-kvm : disable KVM kernel module usage -no-kqemu : disable KQEMU kernel module usage -no-module: disable all kernel module usage For examples, the following command runs kqemu. # qemu-knoppix.sh -no-kvm * UML: UserModeLinux (2.6.18) Boot with the third option KNOPPIX(normal kernel) on GRUB. Script umlknx.sh prepares the environment for UML. # umlknx.sh -no-kvm === How to use Trusted Boot = Trusted GRUB and IMA(Integrity Measured Architecture) on TPM1.2 (Trusted Platform Module). The devices, blocks and files, which are used at boot time, are measured and registered at PCRs(Platform Configuration Register) of the secure chip TPM (Trusted Platform Module). Boot with the second option KNOPPIX(2.6.19.1+ima) on
Re: [Qemu-devel] Simtec BAST emulation
On Tue, 2007-04-03 at 01:04 +0200, andrzej zaborowski wrote: We have also implemented emulation of the S3C2410x SoC. I hope we can merge both implementations to come up with better emulation. Our tree is accessible at http://svn.openmoko.org/trunk/src/host/qemu-neo1973/ and our main target machine is the FIC Neo1973 which you mention above. The tree is still heavily a work-in-progress but the processor part (S3C2410 with on-chip preripherals) is quite mature. Perhaps we should work together to get your processor core merged into QEMU proper? I could work on patching our BAST stuff against your core and then together we could look at getting it merged. All of the on-chip peripherals described in the S3C2410A User Manual rev 1.0 except the Watchdog timer and USB Slave are emulated with high level of detail. The OHCI USB uses the same routine as the PXA2xx emulator. That sounds excellent. Far further than we had gotten thus-far. Things that are tested to work: OpenMoko firmware from the real device boots as a NAND Flash image. Cool. Is the NAND format with, or without OOB? The OpenMoko rootfs can also be booted off the emulated SD card. We use the u-boot and kernel images from the original device. Input is through GPIO buttons or touchscreen connected to the on-chip ADC, output through on-chip UARTs and LCD. Audio through a codec connected to on-chip I2C and I2S busses. Out of interest, which codec is it? There is also an SPI-connected peripheral (can be driven either through the on-chip SPI interface or GPIO bit-banging). *nod* S3C2410 idle mode is supported. Aha, this is wonderful news. There's no save/restore support. Hmm, perhaps we could work on that together. Apparently there's some code duplication, which is sad but I hope we can get both machines (BAST and Neo1973) to use common code. Briefly looking at your patch, the openmoko tree seems to have a more complete/specs-conformant S3C2410 part. Yes, our S3C2410 part was only as far as we needed to get Linux and ABLE booting on the emulator. Yours is much more mature and really deserves to be merged once we can get a system emulation in place which you're happy to offer for merging. I assume you too have noticed that the longer you leave it before offering patches for merging, the scarier the diff becomes. I will take a look at your tree and at how hard it will be to merge the Simtec board emulation into it. Thanks, Daniel. -- Daniel Silverstone http://www.simtec.co.uk/ PGP mail accepted and encouraged.Key Id: 2BC8 4016 2068 7895
Re: [Qemu-devel] Simtec BAST emulation
On Mon, 2007-04-02 at 18:45 +0100, Paul Brook wrote: A few issues with the patch, which I think need to be resolved before it can be applied: - You're using global structures to store machine state. While it's debatable whether you'll ever have more than one s3c2410, I think it's definitely still worth allowing for this possibility, and encapsulating the state in a structure, like all the other hardware emulation does. Right, I've basically decided that we're going to go with the OpenMoko core emulation if it turns out to be sensible. However the global state comment is a good one. It's one thing I wasn't quite happy with, but in the end we did it for simplicity since having more than one s3c2410 would be strange. - For the device emulation (dm9000 and ide, maybe others) you should use pic_set_irq_new, instead of passing a separate set_irq function. Other ARM boards already support arbitrary routing of interrupts via hw/arm_pic.[ch]. Right, the interrupt controller on the S3C2410 didn't seem to fit with the hw/arm_pic stuff, but yes, perhaps the separate set_irq stuff was a touch heavy handed. - usb_ohci_mmap_init should look more like (or even be the same function as) usb_ohci_init_pxa. Aha, I'd not spotted that, thanks. The emulation is complete enough to start Simtec's ABLE boot loader (downloadable from www.simtec.co.uk) and also is capable of being direct-booted with a linux kernel/initrd combination as per the versatile etc. What is the licence for ABLE? Would we be able to distribute it with qemu? Unfortunately I don't think so. However I could ask my boss. D. -- Daniel Silverstone http://www.simtec.co.uk/ PGP mail accepted and encouraged.Key Id: 2BC8 4016 2068 7895
[Qemu-devel] qemu/hw mips_malta.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/04/03 14:05:42 Modified files: hw : mips_malta.c Log message: Fix Malta tty2 UART registers. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_malta.c?cvsroot=qemur1=1.20r2=1.21
Re: [Qemu-devel] Simtec BAST emulation
Hi, On 03/04/07, Daniel Silverstone [EMAIL PROTECTED] wrote: On Tue, 2007-04-03 at 01:04 +0200, andrzej zaborowski wrote: We have also implemented emulation of the S3C2410x SoC. I hope we can merge both implementations to come up with better emulation. Our tree is accessible at http://svn.openmoko.org/trunk/src/host/qemu-neo1973/ and our main target machine is the FIC Neo1973 which you mention above. The tree is still heavily a work-in-progress but the processor part (S3C2410 with on-chip preripherals) is quite mature. Perhaps we should work together to get your processor core merged into QEMU proper? I could work on patching our BAST stuff against your core and then together we could look at getting it merged. Agreed, that would be very nice. I'm going to try to add the watchdog timer this week and get the S3C2410 part of the tree into some clean state. The watchdog timer is very low priority but Linux uses it for rebooting, so let's have it in for completeness as it's not so easy to get improvements merged into qemu tree later. My concern with preparing and submitting patches at this moment, or even syncing the openmoko tree with CVS changes, is that we submitted patches for PXA2xx SoC processors emulation some two weeks ago and the S3C2410 uses a number of the same structures as PXA2xx (e.g the NAND emulator, SD card, I2C framework, some GPIO bits). These patches have not been merged, but also have not been rejected. Paul Brook (*poke*) expressed that he is willing to merge them when he has time, and I know that he will make lots of changes when he's applying them (which is good), so the openmoko tree will have to be rebased anyway. All of the on-chip peripherals described in the S3C2410A User Manual rev 1.0 except the Watchdog timer and USB Slave are emulated with high level of detail. The OHCI USB uses the same routine as the PXA2xx emulator. That sounds excellent. Far further than we had gotten thus-far. Things that are tested to work: OpenMoko firmware from the real device boots as a NAND Flash image. Cool. Is the NAND format with, or without OOB? Normally it is with OOB. Here's how it works: On init, hw/nand.c takes only the manufacturer and chip IDs as arguments and based on a table of chip IDs it looks up the size of the chip. Now, if a NAND image was given on commandline with -mtblock it will read and write data to this image, otherwise the initial state of the memory is filled with 0xff bytes and changes are only stored in memory. Now, if the size of the image is greater or equal (number of pages) * (page size + OOB size) then the image is interpreted as page data interleaved with OOB data. If it's below this value then it is taken the image contains only page data, and OOB part is malloc()ed, initially filled with 0xff bytes. The OpenMoko rootfs can also be booted off the emulated SD card. We use the u-boot and kernel images from the original device. Input is through GPIO buttons or touchscreen connected to the on-chip ADC, output through on-chip UARTs and LCD. Audio through a codec connected to on-chip I2C and I2S busses. Out of interest, which codec is it? It's the Wolfson Microsystems WM8753. The tree also has WM8750. There is also an SPI-connected peripheral (can be driven either through the on-chip SPI interface or GPIO bit-banging). *nod* S3C2410 idle mode is supported. Aha, this is wonderful news. There's no save/restore support. Hmm, perhaps we could work on that together. This would be very nice. Apparently there's some code duplication, which is sad but I hope we can get both machines (BAST and Neo1973) to use common code. Briefly looking at your patch, the openmoko tree seems to have a more complete/specs-conformant S3C2410 part. Yes, our S3C2410 part was only as far as we needed to get Linux and ABLE booting on the emulator. Yours is much more mature and really deserves to be merged once we can get a system emulation in place which you're happy to offer for merging. I assume you too have noticed that the longer you leave it before offering patches for merging, the scarier the diff becomes. Yes, but I also notice the way qemu tree is maintained, release early, realease often wouldn't work very well. I will take a look at your tree and at how hard it will be to merge the Simtec board emulation into it. I hope it's not too difficult, we're trying to use APIs similar to those in the rest of qemu. Maybe looking at hw/neo1973.c can help getting some things right if you're willing to rebase the BAST board to use S3C2410 from openmoko tree. This would very nice as then we could work with only one implementation of S3C2410. To quickly get a working Neo1973 emulator, I've put some demo instructions at http://wiki.openmoko.org/wiki/OpenMoko_under_QEMU Regards, Andrzej
[Qemu-devel] qemu hw/apic.c target-i386/cpu.h target-i386/he...
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/04/03 16:38:34 Modified files: hw : apic.c target-i386: cpu.h helper.c Log message: i386 return APIC ID with cpuid, by Bernhard Kauer. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/apic.c?cvsroot=qemur1=1.12r2=1.13 http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/cpu.h?cvsroot=qemur1=1.42r2=1.43 http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/helper.c?cvsroot=qemur1=1.77r2=1.78
[Qemu-devel] Re: SDL audio and AIO hogging each other's signals
On Tue, 3 Apr 2007, andrzej zaborowski wrote: Hi, with QEMU_AUDIO_DRV set to sdl and booting from CD-ROM with AIO on a Linux host and with SDL 1.2.11, qemu locks up in sigwait() (the main thread) and SDL_SemWait() (the audio thread) as soon as music is playing and CD-ROM is being read at the same time. It appears that audio/sdlaudio.c:sdl_callback is called by SDL when it shouldn't be called, and block-raw.c is trying to flush the AIO operations, so it would seem that the SIGUSR2 which is intended to wake up the sigwait is instead captured by SDL and SDL tries to be smart and calls sdl_callback. sdl_callback has a sanity check but this check is *after* SDL_SemWait() so it is not triggered. The strange thing is that using a different signal (tried SIGUSR1 and SIGPOLL) for AIO doesn't help. Does SDL catch all signals? I could be totally wrong because I don't know SDLAudio at all. If my reading of SDLs sources are correct then it shouldn't be trying to catch any signals when explicitly instructed not to do so (which is done in sdl.c (SDL_INIT_NOPARACHUTE flag)). Any ideas about the exact reason why this is happening and how to fix it? Given the semantics of signal delivery in POSIX what you describe might happen, what is a little surprising is that SDL (btw. which backend SDL uses?) doesn't complain. Here's my theory: signal will be delivered to the arbitrary thread that happens to not block it, for whatever reason, the thread SDL created to do audio processing is picked up, which leads to some system call being interrupted(eventually) and -1 (errno == EINTR), SDL happily continues calling stuff. One solution would be to explicitly block everything upon entering sdl_callback for the first time. This is ugly and can have any consequences one cares to imagine, but that's SDL for you (any particular reason why you are using it?) P.S. Quoting PTHREAD_SIGNAL(3) NOTES For !sigwait! to work reliably, the signals being waited for must be blocked in all threads, not only in the calling thread, since otherwise the POSIX semantics for signal delivery do not guarantee that it's the thread doing the !sigwait! that will receive the signal. The best way to achieve this is block those signals before any threads are created, and never unblock them in the program other than by calling !sigwait!. -- vale
[Qemu-devel] Is it possible to boot qemu-system-ppc with -kernel?
I've been trying several variants of: qemu-system-ppc -M prep -nographic -hda ext2.img -kernel zImage \ -append rw init=/tools/bin/sh panic=1 PATH=/tools/bin root=/dev/hda console=/dev/ttyS0 My miniconfig is attached. (You can make a full-sized .config out of it with make allnoconfig KCONFIG_ALLSYMS=miniconfig-linux, I still need to get the miniconfig patch in so there's a better UI.) I'm trying to boot the zImage file that produces. Unfortunately, I've never managed to boot a ppc kernel under qemu with -kernel. I've got to be doing something wrong, but I don't know what it is. Could you offer any hints? Here's the output I get: Could not configure '/dev/rtc' to have a 1024 Hz timer. This is not a fatal error, but for better emulation accuracy either use a 2.6 host Linux kernel or type 'echo 1024 /proc/sys/dev/rtc/max-user-freq' as root. init_ppc_proc: PVR 0004 mask = 0004 register PCI host 'pci-bridge' 'pci' 'null' 'PREP Host PCI Bridge - Motorola Raven' register 'pci-bridge' 'pci' 'null' 'PREP Host PCI Bridge - Motorola Raven' 0x8000 in 'device-tree' 0x Done 582b000 582b880 PCI device 'null' 0 11 0 has no reg properties: PCI device 'null' 0 11 0 has no assigned addresses properties: register pci device 'Qemu VGA' 000c 'display' 'VGA' 'Qemu VGA' register 'Qemu VGA' 'display' 'VGA' 'Qemu VGA' 0x000c in 'pci-bridge' 0x8000 Done 582b880 582b980 PCI device 'Qemu VGA' 0 12 0 reg properties: addr: 82006010 f000 size: 0080 PCI device 'Qemu VGA' 0 12 0 assigned addresses properties: addr: 82006010 f000 size: 0080 PPC Open Hack'Ware BIOS for qemu version 0.4.1 Build 2005-07-06 23:10:57 Copyright 2003-2005 Jocelyn Mayer Memory size: 144 MB. Booting from device m ide0: drive 0: Hard Disk ERROR: OF_property_copy cannot get property 'hd' for aliases ide0: drive 1: CD-ROM ERROR: OF_property_copy cannot get property 'cd' for aliases ERROR: ATAPI TEST_UNIT_READY : status 41 != 0x40 ide1: drive 0: none ide1: drive 1: none Probe partitions for device c ERROR: No MSDOS signature (0 0 0 0) Boot partition: 0 9401fff8 9401fff8 0 Probe partitions for device m ERROR: No MSDOS signature (38 0 0 0) Use bloc device as raw partition Boot partition: 0 9401fff8 9401fff8 0 ERROR: OF_property_copy cannot get property 'alias' for null boot device: 5833180 image 100 size 1106232 ERROR: No MSDOS signature (7f 45 0 0) Use bloc device as raw partition Boot partition: 0 9401fff8 9401fff8 0 boot device: 5833180 ERROR: Found no boot partition! ERROR: BUG caught... BIOS execution exception nip=0x0580 msr=0x2000 dar=0x dsisr=0x Stopping execution It's not getting _to_ the kernel. (I tried booting vmlinux instead of bzImage, but it made no difference.) Thanks, Rob -- Penguicon 5.0 Apr 20-22, Linux Expo/SF Convention. Bruce Schneier, Christine Peterson, Steve Jackson, Randy Milholland, Elizabeth Bear, Charlie Stross... CONFIG_PPC_CHRP=y CONFIG_SWAP=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LSF=y CONFIG_BINFMT_ELF=y CONFIG_PM=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_BLK_DEV_LOOP=y CONFIG_IDE=y CONFIG_BLK_DEV_IDE=y CONFIG_BLK_DEV_IDEDISK=y CONFIG_IDE_GENERIC=y CONFIG_BLK_DEV_IDEPCI=y CONFIG_BLK_DEV_GENERIC=y CONFIG_NETDEVICES=y CONFIG_NET_ETHERNET=y CONFIG_NET_PCI=y CONFIG_NE2K_PCI=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y CONFIG_SQUASHFS=y
Re: [Qemu-devel] Is it possible to boot qemu-system-ppc with -kernel?
To boot the prep machine you need to configure the kernel for prep and use the zImage.prep file. IE: CONFIG_PPC_PREP=y Right now you selected CONFIG_PPC_CHRP In any kernel 2.6.20 there is a bug where no PCI interrupts go to sleep and the default prep loader has a size limit. I worked around this by modifying the prep loader to accept a bigger image, as well as to process the kernel arguments passed by QEMU. So yes it is definitely possible to boot a prep image, but there some tricks. I also only use the serial ports, so I am not certain if the frame buffer actually works. Jason. Rob Landley wrote: I've been trying several variants of: qemu-system-ppc -M prep -nographic -hda ext2.img -kernel zImage \ -append rw init=/tools/bin/sh panic=1 PATH=/tools/bin root=/dev/hda console=/dev/ttyS0 My miniconfig is attached. (You can make a full-sized .config out of it with make allnoconfig KCONFIG_ALLSYMS=miniconfig-linux, I still need to get the miniconfig patch in so there's a better UI.) I'm trying to boot the zImage file that produces. Unfortunately, I've never managed to boot a ppc kernel under qemu with -kernel. I've got to be doing something wrong, but I don't know what it is. Could you offer any hints? Here's the output I get: Could not configure '/dev/rtc' to have a 1024 Hz timer. This is not a fatal error, but for better emulation accuracy either use a 2.6 host Linux kernel or type 'echo 1024 /proc/sys/dev/rtc/max-user-freq' as root. init_ppc_proc: PVR 0004 mask = 0004 register PCI host 'pci-bridge' 'pci' 'null' 'PREP Host PCI Bridge - Motorola Raven' register 'pci-bridge' 'pci' 'null' 'PREP Host PCI Bridge - Motorola Raven' 0x8000 in 'device-tree' 0x Done 582b000 582b880 PCI device 'null' 0 11 0 has no reg properties: PCI device 'null' 0 11 0 has no assigned addresses properties: register pci device 'Qemu VGA' 000c 'display' 'VGA' 'Qemu VGA' register 'Qemu VGA' 'display' 'VGA' 'Qemu VGA' 0x000c in 'pci-bridge' 0x8000 Done 582b880 582b980 PCI device 'Qemu VGA' 0 12 0 reg properties: addr: 82006010 f000 size: 0080 PCI device 'Qemu VGA' 0 12 0 assigned addresses properties: addr: 82006010 f000 size: 0080 PPC Open Hack'Ware BIOS for qemu version 0.4.1 Build 2005-07-06 23:10:57 Copyright 2003-2005 Jocelyn Mayer Memory size: 144 MB. Booting from device m ide0: drive 0: Hard Disk ERROR: OF_property_copy cannot get property 'hd' for aliases ide0: drive 1: CD-ROM ERROR: OF_property_copy cannot get property 'cd' for aliases ERROR: ATAPI TEST_UNIT_READY : status 41 != 0x40 ide1: drive 0: none ide1: drive 1: none Probe partitions for device c ERROR: No MSDOS signature (0 0 0 0) Boot partition: 0 9401fff8 9401fff8 0 Probe partitions for device m ERROR: No MSDOS signature (38 0 0 0) Use bloc device as raw partition Boot partition: 0 9401fff8 9401fff8 0 ERROR: OF_property_copy cannot get property 'alias' for null boot device: 5833180 image 100 size 1106232 ERROR: No MSDOS signature (7f 45 0 0) Use bloc device as raw partition Boot partition: 0 9401fff8 9401fff8 0 boot device: 5833180 ERROR: Found no boot partition! ERROR: BUG caught... BIOS execution exception nip=0x0580 msr=0x2000 dar=0x dsisr=0x Stopping execution It's not getting _to_ the kernel. (I tried booting vmlinux instead of bzImage, but it made no difference.) Thanks, Rob CONFIG_PPC_CHRP=y CONFIG_SWAP=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LSF=y CONFIG_BINFMT_ELF=y CONFIG_PM=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_BLK_DEV_LOOP=y CONFIG_IDE=y CONFIG_BLK_DEV_IDE=y CONFIG_BLK_DEV_IDEDISK=y CONFIG_IDE_GENERIC=y CONFIG_BLK_DEV_IDEPCI=y CONFIG_BLK_DEV_GENERIC=y CONFIG_NETDEVICES=y CONFIG_NET_ETHERNET=y CONFIG_NET_PCI=y CONFIG_NE2K_PCI=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y CONFIG_SQUASHFS=y -- Jason Wessel, SMTS Linux Products, Wind River direct +1.630.971.6420 mobile +1.630.715.4615 fax +1.630.971.6433
[Qemu-devel] unable to boot Linux PPC live CD
After failing to boot my Beige G3 from http://www.sysresccd.org/ the system rescue CD, I decided to try the PPC version on Qemu. when using both 0.9.0 and the CVS tree, the bootloader says that the bootstrap partition type is Apple_HFS but it should be Apple_Bootstrap. It also shows OF_Property_copy errors, but it scrolls by so fast that I can't read them. I get as far as the Tux Penguin on the upper left-hand size, then it freezes.
Re: [Qemu-devel] SDL audio and AIO hogging each other's signals
andrzej zaborowski [EMAIL PROTECTED] wrote: Hi, with QEMU_AUDIO_DRV set to sdl and booting from CD-ROM with AIO on a Linux host and with SDL 1.2.11, qemu locks up in sigwait() (the main thread) and SDL_SemWait() (the audio thread) as soon as music is playing and CD-ROM is being read at the same time. It appears that audio/sdlaudio.c:sdl_callback is called by SDL when it shouldn't be called, and block-raw.c is trying to flush the AIO operations, so it would seem that the SIGUSR2 which is intended to wake up the sigwait is instead captured by SDL and SDL tries to be smart and calls sdl_callback. sdl_callback has a sanity check but this check is *after* SDL_SemWait() so it is not triggered. The strange thing is that using a different signal (tried SIGUSR1 and SIGPOLL) for AIO doesn't help. Does SDL catch all signals? I could be totally wrong because I don't know SDLAudio at all. Any ideas about the exact reason why this is happening and how to fix it? On Solaris 10/11 x86, I was seeing a bunch of semphore errors emitted from SDL when using SDL audio. I'll track this down and report back. Ben
[Qemu-devel] Detecting an assembly instruction in QEMU
Hi All, I am inserting movl %eax, %eax instruction within the assembly code of a program and I am running the code on QEMU which is configured for i386 and is running linux-0.2.img. I want to detect this assembly instruction within the QEMU code in order to perform a specific operation e.g. when ever QEMU finds this instruction a specific function is called. Could anyone please tell me which QEMU files should I modify in order to add this functionality. I looked through almost all the C files but was unable to figure it out. I will really appreciate any help. Thanks, Atif
