Re: [Qemu-devel] virtual PC block driver status
Hi, > As noted before > (http://lists.gnu.org/archive/html/qemu-devel/2006-10/msg00153.html) > > Microsoft has published the format of virtual pc drive VHD. It should be > used also by xen. The specs are available here: > > http://download.microsoft.com/download/f/f/e/ffef50a5-07dd-4cf8-aaa3-442c0673a029/Virtual%20Hard%20Disk%20Format%20Spec_10_18_06.doc > > I would like to implement proper VHD support for qemu using such > information. In order to not duplicate effort, I would like to know if > some one is already working on updating current vpc block driver. You managed to do this work? I wrote the original driver, but have no interest on working on it. -- Alex
[Qemu-devel] [PATCH] Parallels disk image support
Hi,
attached patch adds support for reading from Parallels disk images.
--
Alex
Index: Changelog
===
RCS file: /sources/qemu/qemu/Changelog,v
retrieving revision 1.137
diff -u -r1.137 Changelog
--- Changelog 25 Jun 2007 11:41:37 - 1.137
+++ Changelog 27 Jul 2007 00:25:38 -
@@ -10,6 +10,7 @@
- Improved SH4 support (Magnus Damm)
- MIPS64 support (Aurelien Jarno, Thiemo Seufer)
- Preliminary Alpha guest support (J. Mayer)
+ - Read-only support for Parallels disk images (Alex Beregszaszi)
version 0.9.0:
Index: Makefile
===
RCS file: /sources/qemu/qemu/Makefile,v
retrieving revision 1.120
diff -u -r1.120 Makefile
--- Makefile 17 Jun 2007 16:41:04 - 1.120
+++ Makefile 27 Jul 2007 00:25:38 -
@@ -32,7 +32,7 @@
recurse-all: $(patsubst %,subdir-%, $(TARGET_DIRS))
-qemu-img$(EXESUF): qemu-img.c cutils.c block.c block-raw.c block-cow.c block-qcow.c aes.c block-vmdk.c block-cloop.c block-dmg.c block-bochs.c block-vpc.c block-vvfat.c block-qcow2.c
+qemu-img$(EXESUF): qemu-img.c cutils.c block.c block-raw.c block-cow.c block-qcow.c aes.c block-vmdk.c block-cloop.c block-dmg.c block-bochs.c block-vpc.c block-vvfat.c block-qcow2.c block-parallels.c
$(CC) -DQEMU_TOOL $(CFLAGS) $(CPPFLAGS) $(BASE_CFLAGS) $(LDFLAGS) $(BASE_LDFLAGS) -o $@ $^ -lz $(LIBS)
dyngen$(EXESUF): dyngen.c
Index: Makefile.target
===
RCS file: /sources/qemu/qemu/Makefile.target,v
retrieving revision 1.187
diff -u -r1.187 Makefile.target
--- Makefile.target 12 Jul 2007 09:29:18 - 1.187
+++ Makefile.target 27 Jul 2007 00:25:39 -
@@ -367,7 +367,7 @@
VL_OBJS+=cutils.o
VL_OBJS+=host-utils.o
VL_OBJS+=block.o block-raw.o
-VL_OBJS+=block-cow.o block-qcow.o aes.o block-vmdk.o block-cloop.o block-dmg.o block-bochs.o block-vpc.o block-vvfat.o block-qcow2.o
+VL_OBJS+=block-cow.o block-qcow.o aes.o block-vmdk.o block-cloop.o block-dmg.o block-bochs.o block-vpc.o block-vvfat.o block-qcow2.o block-parallels.o
VL_OBJS+=irq.o
ifdef CONFIG_WIN32
VL_OBJS+=tap-win32.o
Index: block.c
===
RCS file: /sources/qemu/qemu/block.c,v
retrieving revision 1.43
diff -u -r1.43 block.c
--- block.c 11 Feb 2007 15:06:09 - 1.43
+++ block.c 27 Jul 2007 00:25:42 -
@@ -1241,6 +1241,7 @@
bdrv_register(&bdrv_vpc);
bdrv_register(&bdrv_vvfat);
bdrv_register(&bdrv_qcow2);
+bdrv_register(&bdrv_parallels);
}
void *qemu_aio_get(BlockDriverState *bs, BlockDriverCompletionFunc *cb,
Index: vl.h
===
RCS file: /sources/qemu/qemu/vl.h,v
retrieving revision 1.256
diff -u -r1.256 vl.h
--- vl.h 11 Jul 2007 23:14:59 - 1.256
+++ vl.h 27 Jul 2007 00:25:46 -
@@ -569,6 +569,7 @@
extern BlockDriver bdrv_vpc;
extern BlockDriver bdrv_vvfat;
extern BlockDriver bdrv_qcow2;
+extern BlockDriver bdrv_parallels;
typedef struct BlockDriverInfo {
/* in bytes, 0 if irrelevant */
/*
* Block driver for Parallels disk image format
*
* Copyright (c) 2007 Alex Beregszaszi
*
* This code is based on comparing different disk images created by Parallels.
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the "Software"), to deal
* in the Software without restriction, including without limitation the rights
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
* copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice shall be included in
* all copies or substantial portions of the Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
* THE SOFTWARE.
*/
#include "vl.h"
#include "block_int.h"
/**/
#define HEADER_MAGIC "WithoutFreeSpace"
#define HEADER_VERSION 2
#define HEADER_SIZE 64
// always little-endian
struct parallels_header {
char magic[16]; // "WithoutFreeSpace"
uint32_t version;
uint32_t heads;
uint32_t cylinders;
uint32_t tracks;
uint32_t catalog_entries;
uint32_t nb_sectors;
char padding[24];
} __attribute__((packed));
typedef struct BDRVParallelsState {
int fd;
uint32_t *catalog_bitmap;
int catalog_size;
int tracks;
} BDRVPa
Re: [Qemu-devel] [PATCH] Add support for VDI images
Hi, > This patch adds support for reading, writing and creation (and thus > conversion) of VDI images (VirtualBox image format). Creation of derived > images above read-only base images also works, through a hack (the base image > filename is stored as the comment of the derived image) > It's mainly a thin wrapper around VirtualBox OSE source code. > It may not compile on non-Linux hosts, and it definitely won't work on big > endian hosts. So, there's still a bit of work to do for those interested by > running it on those platforms. What about writing a native implementation? At least with read support, for importing from Virtualbox. -- Alex
[Qemu-devel] What is the best way to control qemu on a remote box?
I'm using a command line like: qemu -vnc :4 -kernel-kqemu -std-vga -no-reboot -monitor unix:/vservers/qemu/cms1/cms1.sock,server,nowait -boot c -hda hda1.img -hdb swap.img -net nic,vlan=0,macaddr=00:16:3e:00:0f:00 -net tap,vlan=0,ifname=br0-cms1,script=/etc/qemu-ifup-br0 -m 256 I'm running linux but would like the system to feel as close to real hardware as I can get. The the shutdown process is a pain. echo -n "Asking $GUEST to stop...(sleep $WAIT_FOR_GUEST)" su $USER -c " echo 'sendkey ctrl-alt-delete' |socat - unix-connect:/$BasePath/$GUEST/$GUEST.sock " >/dev/null With some distros the guest stops and qemu exits. On Ubuntu the guest will shutdown and get to "halt", but qemu will never exit. What is the correct way to setup a remote system like this. I would like to use the qemu monitor mode better. Note: The host system is 11 hour away, and I will never sit at the hosts console. Thank you for your time. Nicholas A. Schembri state college pa usa
Re: [Qemu-devel] qemu-system-arm -M akita/terrier - which roms work? (have first patches now :)
Okay I got a little further now...
On Wed, Jul 25, 2007 at 10:13:42PM +0200, andrzej zaborowski wrote:
> On 24/07/07, Juergen Lock <[EMAIL PROTECTED]> wrote:
>> I was under the impression that -append doesnt work, is this wrong?
>> Also /proc/cmdline on the zaurus is
>> console=ttyS0 root=/dev/mtdblock2
>> mtdparts=sharpsl-nand:[EMAIL PROTECTED](smf),[EMAIL PROTECTED](root),-(home)
>> jffs2_orphaned_inodes=delete EQUIPMENT=5 LOGOLANG=1 DEFYEAR=2007 LOGO=1
>> LAUNCH=q
>> and even when I do pass that with -append to qemu I still dont get
>> anything on the serial console. So maybe the problem is just missing
>> kernel commandline... Can -append be fixed?
>
> No, not in qemu :( zaurus kernels don't accept any parameters from
> bootloaders, that's because they use the
> arch/arm/boot/compressed/head-sharpsl.S file instead of the generic
> arm head.S. Set the parameters in your .config.
Actually... at least the sharp kernel does in fact take args as
I found out, but it wants them in the old-style struct param_struct
as defined in linux/include/asm-arm/setup.h (because of
CONFIG_SHARPSL_BOOTLDR_PARAMS e.g. in linux/arch/arm/mach-pxa/corgi.c)
I've prepared a patch that adds an -old-param flag to qemu (to be used
together with -append), see patch-arm-oldparms (attached). And the
reason I got nothing on ttyS0 was simply that the sharp kernel had
CONFIG_SERIAL_CONSOLE unset... (as seen e.g. in
linux/arch/arm/def-configs/terrier-j)
>
>> Could be, but can `info jit' also show no change then? (qemu is still
>> using all the cpu time it can get.)
>
> Oh, then maybe it really hangs. I have only tested 2.6 kernels from
> different trees (but they were all descendants of linus' tree more
> than Sharp's) and OpenBSD (some post 4.0 cvs checkout). It's possible
> that Sharp kernels depend on something that is set up by the Sharp
> PROM code, which is closed-source (the one that runs the japanese
> menu). It should be possible to run it in qemu though.
I've managed to build a sharp kernel with a modified config now
(sidux live cd to the rescue!) and then saw that its hanging after the
sound init. built a cross gdb (which was easier than I thought, luckily
qemu's gdbserver listens on the network so I didn't even have to build
a qemu snapshot on linux :), and found it hanging in a tight loop
waiting for bit 0 (TNF) of SASR0 in corgi_i2s_write in
linux/drivers/sound/pxa-i2s_spitz.c . Patched that (not sure its
right but it works for me, see patch-pxa-audio), and now I get lots of
nand ecc errors and mount failures, I guess the mtdparts= arg isnt right
yet and/or the raw2flash.c source needs fixing...
>
>> > Installing debian however should not
>> >depend on what rom you use, afterall debian is supposed to replace the
>> >contents.
>>
>> Well I dont want to replace the contents, I want to run debian in
>> addition to the sharp stuff in a chroot :) See e.g. here,
>> http://wiki.debian.org/PocketWorkstation
>> and under `Installing Debian/PocketWorkstation' here:
>> http://www.users.on.net/~hluc/myZaurus/jumbo/xqtjumbo.html
>> (these instructions and packages are a bit dated and not directly for
>> c3200 which is one of the reasons i'd like to test/prepare things
>> using qemu.)
>
> I still think that debian shouldn't care about what was your original
> distribution or what distribution hosts the chroot environment.
In an ideal world... At least it interacts with the (old in this case)
kernel, and also the xserver (x/qt) that will run outside the chroot.
Thanx,
Juergen
Index: qemu/hw/arm_boot.c
@@ -76,6 +76,76 @@
stl_raw(p++, 0);
}
+static void set_kernel_args_old(uint32_t ram_size, int initrd_size,
+const char *kernel_cmdline,
+target_phys_addr_t loader_start)
+{
+uint32_t *p;
+unsigned char *s;
+
+/* see linux/include/asm-arm/setup.h */
+p = (uint32_t *)(phys_ram_base + KERNEL_ARGS_ADDR);
+/* page_size */
+stl_raw(p++, 4096);
+/* nr_pages */
+stl_raw(p++, ram_size / 4096);
+/* ramdisk_size */
+stl_raw(p++, 0);
+#define FLAG_READONLY 1
+#define FLAG_RDLOAD4
+#define FLAG_RDPROMPT 8
+/* flags */
+stl_raw(p++, FLAG_READONLY | FLAG_RDLOAD | FLAG_RDPROMPT);
+/* rootdev */
+stl_raw(p++, (31 << 8) | 0); /* /dev/mtdblock0 */
+/* video_num_cols */
+stl_raw(p++, 0);
+/* video_num_rows */
+stl_raw(p++, 0);
+/* video_x */
+stl_raw(p++, 0);
+/* video_y */
+stl_raw(p++, 0);
+/* memc_control_reg */
+stl_raw(p++, 0);
+/* unsigned char sounddefault */
+/* unsigned char adfsdrives */
+/* unsigned char bytes_per_char_h */
+/* unsigned char bytes_per_char_v */
+stl_raw(p++, 0);
+/* pages_in_bank[4] */
+stl_raw(p++, 0);
+stl_raw(p++, 0);
+stl_raw(p++, 0);
+stl_raw(p++, 0);
+/* pages_in_vram */
+stl_raw(p++, 0);
+/* initrd_start */
+if (initrd_size)
+ stl_raw(
[Qemu-devel] qemu configure
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski 07/07/26 20:41:46 Modified files: . : configure Log message: gcc32 may well be a 4.x version for a 32bit target, so add an additional check, hopefully not too strict. Probe also gcc-3.3.6 to make Gentoo users happy. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/configure?cvsroot=qemu&r1=1.149&r2=1.150
Re: [Qemu-devel] QEmu as a Device Software Optimization tool
-snap- >Personally though I don't see much benefit to simple syntax config >files over C files, that are being used now. Config files implies a self check process. A better question might be, has qemu grown to the point where an outsider is going to define a new platform? Could an arm based cell phone manufacture use the config files to define the hardware for the emulator without a full port? Iphone anyone :) Nicholas A. Schembri state college pa usa
Re: [Qemu-devel] QEmu as a Device Software Optimization tool
Hi, On 26/07/07, Paul Borman <[EMAIL PROTECTED]> wrote: QEmu Target Configuration - I would like to define a configuration file syntax (I cannot help but think back to my BSDi days and the BSD/ OS kernel configuration file) that would define the hardware from the outside. Device drivers would either need to be already linked in, or be able to be dynamically loaded. I would expect that things such as the memory map, type of interrupt controller, the various devices along with their io port and memory addresses and interrupts would be defined here. Again, this would not replace the current system, but would essentially be a new init module. I do not want to see any working configurations break. There is some interesting work being done on a similar project by Paul Sokolovsky for his and Maria Zabolotnaya's Google Summer Of Project. In their approach machine descriptions (but not only) are written in python, which lets you hope that they can have a simple syntax, practically like a config file, if desired, or a much more powerful one, so it seems to be a better idea than plain config files. Personally though I don't see much benefit to simple syntax config files over C files, that are being used now. Regards
Re: [Qemu-devel] QEmu as a Device Software Optimization tool
On Thursday 26 July 2007 18:34:36 Paul Borman wrote: > Paravirtualization - I have written a "device driver" for QEmu that > allows the guest system to essentially make function calls right into > the host (dealing with data representation, etc). A prime example > for use of this is OpenGL. OpenGL is pretty much done in hardware > these days, and most embedded devices do not use X11 as a graphics > system. By providing an OpenGL library on the target OS that > basically calls straight into the hosts OpenGL library it should be > possible to greatly increase the performance of the target without > having to try and export the real graphics hardware into QEmu. Along > with this I have done the necessary work to allow QEmu to use dlopen > () to load in arbitrary shim layers to libraries. As far as OpenGL is concerned, I don't know if you have already looked at it, but you may be interested by my OpenGL patch. Even if it uses a specific guest <--> host communication hack, this may save you the quite tidious process of serializing/deserializing OpenGL calls between guest and host. For more details, see : http://qemu-forum.ipi.fi/viewtopic.php?t=2984
Re: [Qemu-devel] QEmu as a Device Software Optimization tool
Paul Borman wrote: > Greetings, > > I have been working with QEmu for a few months now at Wind River. I am > sure many of you already know Jason Wessel and Alex deVries who championed > QEmu as a tool for our Linux product. It is my goal to demonstrate the > power of QEmu for embedded software development (excuse me, DSO - Device > Software Optimization). I have identified several areas in which some work > needs to be done to make QEmu more appropriate for embedded development. I > am interested in comments or pointers to existing work for several areas (I > have also done work in many of these areas already). I have been working > mainly with PowerPC targets and X86 Linux as a host. > > System Clock - Currently it appears to me that QEmu attempt to sync the > "system clock" with realtime resulting in a different number of emulated > "clock" cycles per clock interrupt. In the embedded environment we are > typically much more interested in a deterministic result from the clock. > For the PowerPC I have implemented an alternate implementation of the TB > and Decrementer that increments the time base based on the number of > emulated instructions that have been processed. It is not perfect, but at > least now the timer interrupt is triggered when the decrementer goes > negative. Have others worked on this problem? I think this goes in the more general area of instruction/cycle counting, which would be also useful for basic performance analysis. IMHO the alternatives should be switchable at runtime (from the monitor and via command line), with host clock synchronization staying the default. So far I haven't thought much about the other topics you raise. Thiemo
[Qemu-devel] QEmu as a Device Software Optimization tool
Greetings, I have been working with QEmu for a few months now at Wind River. I am sure many of you already know Jason Wessel and Alex deVries who championed QEmu as a tool for our Linux product. It is my goal to demonstrate the power of QEmu for embedded software development (excuse me, DSO - Device Software Optimization). I have identified several areas in which some work needs to be done to make QEmu more appropriate for embedded development. I am interested in comments or pointers to existing work for several areas (I have also done work in many of these areas already). I have been working mainly with PowerPC targets and X86 Linux as a host. System Clock - Currently it appears to me that QEmu attempt to sync the "system clock" with realtime resulting in a different number of emulated "clock" cycles per clock interrupt. In the embedded environment we are typically much more interested in a deterministic result from the clock. For the PowerPC I have implemented an alternate implementation of the TB and Decrementer that increments the time base based on the number of emulated instructions that have been processed. It is not perfect, but at least now the timer interrupt is triggered when the decrementer goes negative. Have others worked on this problem? QEmu Target Configuration - I would like to define a configuration file syntax (I cannot help but think back to my BSDi days and the BSD/ OS kernel configuration file) that would define the hardware from the outside. Device drivers would either need to be already linked in, or be able to be dynamically loaded. I would expect that things such as the memory map, type of interrupt controller, the various devices along with their io port and memory addresses and interrupts would be defined here. Again, this would not replace the current system, but would essentially be a new init module. I do not want to see any working configurations break. Paravirtualization - I have written a "device driver" for QEmu that allows the guest system to essentially make function calls right into the host (dealing with data representation, etc). A prime example for use of this is OpenGL. OpenGL is pretty much done in hardware these days, and most embedded devices do not use X11 as a graphics system. By providing an OpenGL library on the target OS that basically calls straight into the hosts OpenGL library it should be possible to greatly increase the performance of the target without having to try and export the real graphics hardware into QEmu. Along with this I have done the necessary work to allow QEmu to use dlopen () to load in arbitrary shim layers to libraries. There are other areas as well, such as deterministic execution, etc. If anyone else is interested in these topics, please let me know. Paul Borman Principal Technologist Wind River Systems
Re: [Qemu-devel] IBM makes AIX 6 beta available for download for everyone
El jue, 19-07-2007 a las 00:46 +0200, Andreas Färber escribió: > Am 18.07.2007 um 18:26 schrieb Blue Swirl: > > >> > It looks like open hack'ware is pretty much stalled, so its hard > >> > telling > >> > what progress will be made futurewise. > >> > >> Might it be possible to replace it with OpenBIOS? > > > > Sure, and as both are GPL useful, code can be shared. But some PPC > > developers are needed. It may still be easier to fix the OHW bugs than > > start over anew. > > Not sure I understand... I thought Open Firmware was based on > platform independent Forth code? > I'm running on ppc64 and could try to compile something under Linux > in case that's the problem. Yes, OF is basically a Forth-interpreter. Of course this Forth-interpreter is in C and compile to machine code :p Then you can add modules in F-Code machine independent code. Try to compile OpenBIOS under Linux/PPC (using 32bit compiler, not ppc64) and comment us.
