Re: [Qemu-devel] Re: KVM call agenda for Jan 25
On the other hand, I think the starting point for a generic in-place converter would be a loop that does something like bdrv_is_allocated() but translates the guest position in the block device into an offset into the image file. That, together with some sort of free map or space allocation bitmap would allow a generic approach to figuring out the data mapping and which parts of the file can be safely used. We can discuss the detailed API later, but I agree that the critical thing to convert is the mapping. You would probably open the file with the source format driver read-only and with the destination driver read-write. For qcow2 you would start with writing a refcount table that marks the whole file as used, other formats use the file size anyway. Then you can start creating L1 and L2 tables and copy the mapping over. Once this is done, you do an fsck to free the metadata of the old format. One thing that may become tricky is the image header which both drivers may want to use and which is fixed at offset 0. And of course, you must make sure that the image is safe at any point if the converter crashes. For image header issue, this is the approach that comes to mind. Lets say, destination format is qcow2. BDRVQcowState is responsible for header fields inside BlockDriverState. We need qcow2 image header to initiliaze all the fields of BDRVQcowState, which is done by bdrv_open(qcow2_open()). So initially, for the qcow2 driver, we do not copy the qcow2 image header (we keep the source header). We can then manually set fields of BDRVQcowState with the desired header fields. And after all other metadata has been copied for the qcow2 format, we can replace the source image header with the qcow2 header. Thanks, Dushyant
Re: [Qemu-devel] Re: KVM call agenda for Jan 25
1. header_size: variable in qed, equals to cluster size in qcow2:
When will it be larger than 1 cluster in qed? So, what will happen to
that extra data on qed-qcow2 conversion.
If you have an feature that is used in the original image, but cannot be
represented in the new format, I think you should just get an error.
2. L2 table size: equals to L1 table size in qed, equals to cluster size
in qcow2:
we need to take it into account during conversion.
Right. I think we'll have to rewrite all of the metadata.
I wonder if we can manage to have a nice block driver interface for
in-place image conversions so that we don't only get a qed-qcow2
converter, but also can implement the interface in e.g. VMDK and get
VMDK-qcow2 and VMDK-qed as well.
3. refcount table:
qcow2-qed:we do not keep refcount structure
qed-qcow2: initialize refcount structure
Yes, refcounts can be rebuilt after the mapping has been converted.
So, a qcow2-qed-qcow2 conversion means if earlier, qcow2 image was
using additional features{1-4}, all information related to that will be
lost.
We shouldn't lose anything but just abort if a conversion isn't
possible. The user can still use qemu-img convert for the more
complicated cases, for example for removing encryption or compression.
Thanks for clearing up those issues.
--
Dushyant
Re: [Qemu-devel] Re: KVM call agenda for Jan 25
Nice that qemu-img convert isn't that far out by default on raw :).
About Google Summer of Code, I have posted my take on applying and
want to share that with you and qemu-devel:
http://blog.vmsplice.net/2011/03/advice-for-students-applying-to-google.html
Thanks for sharing your experiences.
After reading about qcow2 and qed and how they organize data (thanks to
the newly added qcow2 doc and discussions on the mailing list), this is
what I understand.
So, the main difference between qed and qcow2 is the absence of
reference count structure in qed(means less meta data).
It improves performance due to:
1. For write operations, less or no metadata to update.
2. Data write and metadata write can be in any order
This also means these features are no longer supported:
1. Internal snapshots,
2. CPU/device state snapshots,
3. Compression,
4. Encryption
Now, coming to qed--qcow2 conversion, I want to clarify some things.
1. header_size: variable in qed, equals to cluster size in qcow2:
When will it be larger than 1 cluster in qed? So, what will happen to
that extra data on qed-qcow2 conversion.
2. L2 table size: equals to L1 table size in qed, equals to cluster size
in qcow2:
we need to take it into account during conversion.
3. refcount table:
qcow2-qed:we do not keep refcount structure
qed-qcow2: initialize refcount structure
So, a qcow2-qed-qcow2 conversion means if earlier, qcow2 image was
using additional features{1-4}, all information related to that will be
lost.
What do you think? Please correct me if I am making some incorrect
statement.
Thanks,
Dushyant
Re: [Qemu-devel] Qemu support on android
On Saturday 05 March 2011 04:30 PM, Mahesh Shivhare wrote: Hi all, Is there any way by which we can run qemu on android-x86 OS.does qemu needs any modification to run on android-x86 I'm trying to build QEMU with --static option but when m trying to run on android it's getting stuck with the message VNC srver running on 127.0.0.1:' It is working fine. You need a vnc viewer to connect to it. Try vncviewer 127.0.0.1:. -- Dushyant
Re: [Qemu-devel] Re: KVM call agenda for Jan 25
On Sunday 27 February 2011 04:19 PM, Stefan Hajnoczi wrote: On Sat, Feb 26, 2011 at 9:50 PM, Dushyant Bansal cs5070...@cse.iitd.ac.in wrote: Disk block size is usually 512 bytes and in qemu-img, sector size is also 512B. And, this change would copy n sectors even if only one of them actually contains data (while cp checks and copies one block(=sector) at a time). Therefore, it will end up writing more data than cp. cp(1) from GNU coreutils 8.5 works in units of 32 KB on my system. It reads 32 KB and checks for all zeroes. If there are all zeroes, it seeks ahead 32 KB in the output file. Otherwise it writes the entire 32 KB. You can check what cp(1) is doing using strace(1). yes, you are right. I was reading from a much older coreutils source. virtual size: 10G (10737418240 bytes) disk size: 569M convert- original time0m52.522s convert- modified (resultant disk size: 5.3G) time2m12.744s cp time0m51.724s (same disk size) --- virtual size: 10G (10737418240 bytes) disk size: 3.6G convert- original time1m52.249s convert- modified (resultant disk size: 7.1G) time3m2.891s cp time1m55.320s (same disk size) --- In these results, we can see that resultant disk size has increased. If I'm reading this correctly then qemu-img convert is within a few seconds of cp(1) for you? I have collected and attached some more time results for different operations on a 2.2G image. qemu-img convert is close to cp. qemu(modified): IO_BUF_SIZE = (2 * 1024 ) if any sector is non-null, write all sectors -- Dushyant results.xls Description: MS-Excel spreadsheet
Re: [Qemu-devel] Re: KVM call agenda for Jan 25
In cp, it just copies all the disk blocks actually occupied by the file. And, with qemu-img convert, it checks all the sectors and copy those, which contains atleast one non-NUL byte. The better performance of cp over qemu-img convert is the result of overhead of this checking. How did you find out what cp(1) and qemu-img do? How does cp(1) know which disk blocks are actually occupied? I have looked into their source code. Yes, that was not correct. cp also checks each block and copy those which contains non-null byte. qemu-img does the same thing with sectors. I tried a few variations: 1. just copy all the sectors without checking So, actual size becomes equal to virtual size. Did that make qemu-img faster for the image file you tested? No, in fact it becomes slower. I guess it is due to the increase in disk write. 2. In is_allocated_sectors,out of n sectors, if any sector has a non-NUL byte then break and copy all n sectors. As expected, resultant raw image was quite large in size. This is kind of like what cp(1) does, except it limits n to 32 KB maximum at a time. Maybe if you add this tweak they will show similar performance. The drawback is that the output image is larger than with the current approach. Stefan Disk block size is usually 512 bytes and in qemu-img, sector size is also 512B. And, this change would copy n sectors even if only one of them actually contains data (while cp checks and copies one block(=sector) at a time). Therefore, it will end up writing more data than cp. virtual size: 10G (10737418240 bytes) disk size: 569M convert- original time0m52.522s convert- modified (resultant disk size: 5.3G) time2m12.744s cp time0m51.724s (same disk size) --- virtual size: 10G (10737418240 bytes) disk size: 3.6G convert- original time1m52.249s convert- modified (resultant disk size: 7.1G) time3m2.891s cp time1m55.320s (same disk size) --- In these results, we can see that resultant disk size has increased. Thanks, Dushyant
Re: [Qemu-devel] Stupid question?
On Sunday 27 February 2011 03:45 AM, Frans de Boer wrote: Hi all, This is the only QEMU list, so I put my question her. How can I copy the contents of a *.raw image to a real HD partition or vice versa. I often use a virtual image using qemu/kvm to test some OS's and want to migrate them to a HD partition if the time is right. Also, I like to preserve old partitions for future use/reference. Any suggestions? Regards, Frans. You can mount it using losetup. http://blog.piotrj.org/2009/03/mounting-raw-kvmqemu-image.html Thanks, Dushyant
[Qemu-devel] Re: qemu compiling error on ppc64: kvm.c:81: error: 'struct kvm_sregs' has no member named 'pvr'
On Wednesday 16 February 2011 02:39 PM, Avi Kivity wrote: On 02/15/2011 05:59 PM, Dushyant Bansal wrote: 2. How to configure makefiles to get output of printk statements inside kvm/arch/powerpc/kvm/trace.h Better don't make them printks - just use the tracing framework. I'd write up a small howto here myself, but I'm pretty much on the jump to my plane for vacation. Avi, could you please guide him a bit on how to get data out of tracepoints? Thanks for the quick reply :) I have added some more trace parameters in the tracing framework and currently, it is working fine. 1. Add new field in struct kvm_vcpu_stat (kvm_host.h) 2. Add corresponding entry in struct kvm_stats_debugfs_item debugfs_entries[] (book3s.c) 3. Increment or Decrement that field where ever necessary. Those aren't tracepoints; they're deprecated debug statistics. For tracepoints, see include/trace/events/kvm.h (general kvm tracepoints) arch/powerpc/kvm/trace.h (ppc specific tracepoints) arch/powerpc/kvm/book3s_mmu_hpte.c (examples of use, look for trace_kvm_*) Documentation/trace/tracepoints.txt (documentation, likely outdated) Thanks a lot for the information. Dushyant
Re: [Qemu-devel] Re: KVM call agenda for Jan 25
On Saturday 29 January 2011 04:20 PM, Dushyant Bansal wrote: Or this: which is faster, qemu-img convert -fformat -Oformat src-image dst-image or cpsrc-image dst-image? What about for raw images, shouldn't that be the same speed as cp(1)? Poke around the source code, profile it, understand what it's doing, think about ways to improve it. No need to do everything, just doing part of this will give you background on QEMU's block layer. Contributing patches is a good way get up to speed and show your skills. If time doesn't permit that, just think about the problem and how you intend to solve it, and feel free to bounce ideas off me. I explored 'qemu-img create and convert' and got a basic understanding of how they work. cp faster than qemu-img convert For raw-raw In cp, it just copies all the disk blocks actually occupied by the file. And, with qemu-img convert, it checks all the sectors and copy those, which contains atleast one non-NUL byte. The better performance of cp over qemu-img convert is the result of overhead of this checking. I tried a few variations: 1. just copy all the sectors without checking So, actual size becomes equal to virtual size. 2. In is_allocated_sectors,out of n sectors, if any sector has a non-NUL byte then break and copy all n sectors. As expected, resultant raw image was quite large in size. Looking forward to your comments. Thanks, Dushyant
Re: [Qemu-devel] Instruction count with QEMU
On Thursday 17 February 2011 04:03 PM, Marco Boni wrote: Hi all, I am pretty new to QEMU development. To get involved in this, I have been asked by my supervisor to do a simple modification to QEMU. We would like to count the number of instructions the virtual machine processes. In other words, it's all about to declare a counter and increment it every time a guest instruction has to be executed. Can you please give me some hints on how to realize it, i.e. which files I should put my hands on? Thanks a lot A guide to help you get started. www.ecs.syr.edu/faculty/yin/Teaching/TC2010/Proj4.pdf Dushyant
[Qemu-devel] Re: qemu compiling error on ppc64: kvm.c:81: error: struct kvm_sregs has no member named pvr
Hrm. This means that your kernel headers in /usr/include/linux are too old. Can you try and find out which kernel version they are from please Yes, kernel headers version is 2.6.32. For the time being, I copied some of the header files from kvm/arch/powerpc/include/asm/ to kernel headers and qemu build was successful. Thanks a lot. Awesome! I'm eager to hear how well it works for you :) I collected some performance stats using kvm_stat. To get more information about exit counts of individual instructions, I configured CFLAGS_emulate.o with DDEBUG flag. Now, I can see output of pr_debug(Emulating opcode %d / %d\n, get_op(inst), get_xop(inst)); instruction in kernel logs. I have two queries: 1. The count of Emulating opcode statement in /var/log/kern.log (3 million) is coming out to be much less than emulated_inst_exits (22 million) using kvm_stat. 2. How to configure makefiles to get output of printk statements inside kvm/arch/powerpc/kvm/trace.h Also, every time I start kvm, I get this error KVM: Couldn't find level irq capability. Expect the VM to stall at times. After some time, the VM just hangs. I traced this output to qemu/target-ppc/kvm.c Is there any way to avoid it. Thanks, Dushyant
[Qemu-devel] Re: qemu compiling error on ppc64: kvm.c:81: error: 'struct kvm_sregs' has no member named 'pvr'
On Tuesday 15 February 2011 08:03 PM, Alexander Graf wrote: On 15.02.2011, at 15:21, Dushyant Bansal wrote: Hrm. This means that your kernel headers in /usr/include/linux are too old. Can you try and find out which kernel version they are from please Yes, kernel headers version is 2.6.32. For the time being, I copied some of the header files from kvm/arch/powerpc/include/asm/ to kernel headers and qemu build was successful. Thanks a lot. Awesome! I'm eager to hear how well it works for you :) I collected some performance stats using kvm_stat. To get more information about exit counts of individual instructions, I configured CFLAGS_emulate.o with DDEBUG flag. Now, I can see output of pr_debug(Emulating opcode %d / %d\n, get_op(inst), get_xop(inst)); instruction in kernel logs. I have two queries: 1. The count of Emulating opcode statement in /var/log/kern.log (3 million) is coming out to be much less than emulated_inst_exits (22 million) using kvm_stat. The kernel log ring buffer is probably faster filled than read :). 2. How to configure makefiles to get output of printk statements inside kvm/arch/powerpc/kvm/trace.h Better don't make them printks - just use the tracing framework. I'd write up a small howto here myself, but I'm pretty much on the jump to my plane for vacation. Avi, could you please guide him a bit on how to get data out of tracepoints? Thanks for the quick reply :) I have added some more trace parameters in the tracing framework and currently, it is working fine. 1. Add new field in struct kvm_vcpu_stat (kvm_host.h) 2. Add corresponding entry in struct kvm_stats_debugfs_item debugfs_entries[] (book3s.c) 3. Increment or Decrement that field where ever necessary. I can see stats for the new parameter in kvm_stat output. I guess, this approach is okay. This means exactly what it means. There are two possible causes: 1) Your kernel is too old and doesn't support the capability 2) Qemu was compiled with kernel headers that don't know the capability yet If it's 2, just copy some of the kvm*.h files from your kernel source over to /usr/include/linux or /usr/include/asm-powerpc and fix them up to compile (remove __user). I think, its reason 2. I'll try this. Thanks, Dushyant
[Qemu-devel] qemu compiling error on ppc64: kvm.c:81: error: struct kvm_sregs has no member named pvr
Hi, I am trying to install kvm on ppc64 system (imac G5). I have built kernel with kvm module. When I try to install qemu, I am getting this error $ ./configure --enable-kvm --target-list=ppc-softmmu $ make [...] CCslirp/tftp.o CClibdis/ppc-dis.o GEN config-target.h CCppc-softmmu/arch_init.o CCppc-softmmu/cpus.o GEN ppc-softmmu/hmp-commands.h GEN ppc-softmmu/qmp-commands.h CCppc-softmmu/monitor.o CCppc-softmmu/machine.o CCppc-softmmu/gdbstub.o CCppc-softmmu/balloon.o CCppc-softmmu/virtio-blk.o CCppc-softmmu/virtio-balloon.o CCppc-softmmu/virtio-net.o CCppc-softmmu/virtio-serial-bus.o CCppc-softmmu/virtio-pci.o CCppc-softmmu/vhost_net.o CCppc-softmmu/rwhandler.o CCppc-softmmu/kvm.o /home/user/project/qemu/target-ppc/kvm.c: In function kvm_arch_init_vcpu: /home/user/project/qemu/target-ppc/kvm.c:81: error: struct kvm_sregs has no member named pvr make[1]: *** [kvm.o] Error 1 make: *** [subdir-ppc-softmmu] Error 2 qemu-version: 0.13.5, 0.13.0 Other information: Host os : ubuntu-desktop-10.04-powerpc $ uname -a Linux user-desktop 2.6.37-rc6 #2 SMP Fri Feb 4 16:29:05 IST 2011 ppc64 GNU/Linux $ cat /proc/cpuinfo processor : 0 cpu : PPC970FX, altivec supported clock : 2100.00MHz revision: 3.1 (pvr 003c 0301) timebase: platform: PowerMac model : PowerMac12,1 machine : PowerMac12,1 motherboard : PowerMac12,1 MacRISC4 Power Macintosh detected as : 337 (iMac G5 (iSight)) pmac flags : L2 cache: 512K unified pmac-generation : NewWorld Thanks, Dushyant
[Qemu-devel] Re: qemu compiling error on ppc64: kvm.c:81: error: struct kvm_sregs has no member named pvr
On Friday 04 February 2011 08:13 PM, Alexander Graf wrote: On 04.02.2011, at 14:25, Dushyant Bansalcs5070...@cse.iitd.ernet.in wrote: Hi, I am trying to install kvm on ppc64 system (imac G5). I have built kernel with kvm module. When I try to install qemu, I am getting this error $ ./configure --enable-kvm --target-list=ppc-softmmu $ make [...] CCslirp/tftp.o CClibdis/ppc-dis.o GEN config-target.h CCppc-softmmu/arch_init.o CCppc-softmmu/cpus.o GEN ppc-softmmu/hmp-commands.h GEN ppc-softmmu/qmp-commands.h CCppc-softmmu/monitor.o CCppc-softmmu/machine.o CCppc-softmmu/gdbstub.o CCppc-softmmu/balloon.o CCppc-softmmu/virtio-blk.o CCppc-softmmu/virtio-balloon.o CCppc-softmmu/virtio-net.o CCppc-softmmu/virtio-serial-bus.o CCppc-softmmu/virtio-pci.o CCppc-softmmu/vhost_net.o CCppc-softmmu/rwhandler.o CCppc-softmmu/kvm.o /home/user/project/qemu/target-ppc/kvm.c: In function ‘kvm_arch_init_vcpu’: /home/user/project/qemu/target-ppc/kvm.c:81: error: ‘struct kvm_sregs’ has no member named ‘pvr’ Hrm. This means that your kernel headers in /usr/include/linux are too old. Can you try and find out which kernel version they are from please Yes, kernel headers version is 2.6.32. For the time being, I copied some of the header files from kvm/arch/powerpc/include/asm/ to kernel headers and qemu build was successful. Thanks a lot. -- Dushyant
Re: [Qemu-devel] Re: KVM call agenda for Jan 25
http://www.google-melange.com/document/show/gsoc_program/google/gsoc2011/timeline I'd like to see an in-place QCOW2- QED image converter with tests. I'm interested in mentoring this year. Stefan Hi, I am interested in working on this project as part of gsoc. I have prior experience working with qemu. After reading some basic information on qcow2 and qed from: 1. http://lists.nongnu.org/archive/html/qemu-devel/2010-09/msg00310.html 2. http://people.gnome.org/~markmc/qcow-image-format.html I am now planning to start reading their source code. What do you suggest? Are there any other specific things that I should read about? P.S. I just found out another new qemu image format FVD(http://wiki.qemu.org/Features/FVD/Compare). I will try to read it too. Regards, Dushyant
Re: [Qemu-devel] TCG flow vs dyngen
On Monday 24 January 2011 08:26 PM, Stefano Bonifazi wrote: On 01/24/2011 03:32 PM, Peter Maydell wrote: Being a JIT doesn't prohibit counting target instructions executed. It just means that counting them generally requires generating code to do the counting at runtime, so it's a more complicated change to make than it would be in a non-JIT emulator. What do you mean? Should I change the code of qemu-user for counting the instructions, or should I add code into the target binaries? You should see this pdf (www.ecs.syr.edu/faculty/yin/Teaching/TC2010/Proj4.pdf). It talks about tracing the instructions. -- Dushyant
Re: [Qemu-devel] TCG flow vs dyngen
You should see this pdf (www.ecs.syr.edu/faculty/yin/Teaching/TC2010/Proj4.pdf). It talks about tracing the instructions. -- Dushyant Wow thank you! It sounds incredibly interesting!! What we really need is to insert a function call into the translated code, so when each instruction is executed at runtime, our inserted function will be executed. Again wow!! Is that really possible? Some sort of callback triggered at every instruction execution? Yes, this mechanism works. I have written a code to count different kinds of instructions. Do you have any another document explaining that? No. But maybe you can try to understand this through qemu source code. Here are some resources for that http://stackoverflow.com/questions/4501173/a-call-to-those-who-have-worked-with-qemu This pdf just gives instructions on how to do it on an old version of qemu (disas_insn doesn't exist at all on my code now), and does not explain what it is, what's behind that suggested code .. Also the code for single step would be of great help to me! I really needed that.. but when I tried it on qemu-user didn't work at all.. It exists in file qemu/target-i386/translate.c You are also talking about qemu source code privided here http://wiki.qemu.org/Download, right? If you need, I can give the source code of counting implementation with some documentation. Hope this helps. -- Dushyant
[Qemu-devel] Emulating powerpc 440EP with qemu-system-ppcemb
Hi all, I have configured and built qemu with device tree support. qemu-version: 0.13.50 I have built kernel image (uImage) for bamboo using powerpc-440 toolchain. kernel-version: 2.6.37-rc6+ When I try to run this command, # qemu-system-ppcemb -nographic -m 128 -M bamboo -kernel uImage -append I get the following output and qemu just hangs there: Trying to read privileged spr 947 3b3 at 1028 Trying to read invalid spr 62 03e at 0778 Has anyone tried to emulate bamboo with qemu before ? Thanks, Dushyant
Re: [Qemu-devel] Emulating powerpc 440EP with qemu-system-ppcemb
On Monday 24 January 2011 12:12 AM, Rob Landley wrote: On 01/23/2011 06:59 AM, Dushyant Bansal wrote: Hi all, I have configured and built qemu with device tree support. qemu-version: 0.13.50 I have built kernel image (uImage) for bamboo using powerpc-440 toolchain. kernel-version: 2.6.37-rc6+ When I try to run this command, # qemu-system-ppcemb -nographic -m 128 -M bamboo -kernel uImage -append I get the following output and qemu just hangs there: Trying to read privileged spr 947 3b3 at 1028 Trying to read invalid spr 62 03e at 0778 Has anyone tried to emulate bamboo with qemu before ? Thanks, Dushyant In my Aboriginal Linux project (http://landley.net/aboriginal) I have a config that builds a ppc440 cross compiler and builds a root filesystem and kernel with it, but the kernel .config is bog standard 32 bit PPC (mac99 board I think). It boots and runs, gives you a shell prompt, but occasionally misbehaves you try to do anything fancy with it. I am also using http://www.landley.net/aboriginal/downloads/binaries/cross-compiler-powerpc-440fp.tar.bz2cross-compiler-powerpc-440fp from the aboriginal project (http://www.landley.net/aboriginal/downloads/binaries/) to build the kernel image :). Last I checked, the bamboo board was implemented for KVM not QEMU, and QEMU didn't have a ppc440 processor emulation. But that was over a year ago, things could easily have changed... Yes, qemu supports ppc440(bamboo). $ qemu-system-ppcemb -M ? Supported machines are: mpc8544ds mpc8544ds bamboo bamboo ref405ep ref405ep taihu taihu mac99 Mac99 based PowerMAC g3beigeHeathrow based PowerMAC (default) prep PowerPC PREP platform What kernel .config are you using for the bamboo kernel? Rob I am using arch/powerpc/configs/44x/bamboo_defconfig. Thanks, Dushyant
Re: [Qemu-devel] Emulating powerpc 440EP with qemu-system-ppcemb
Those are board emulations. Does it have a 440 _cpu_ emulation? ./qemu-system-ppc -cpu ? | grep 440 This is the output. PowerPC 440-Xilinx PVR 7ff21910 Is this right for my requirement? This is qemu version 0.13.50. And, it seems this support has been added recently. It is missing in qemu version 0.12.5. I have one more query. You said 440 was supported in kvm. But kvm also uses qemu as its userspace component. So, 440 was supported through kvm kernel module? -- Dushyant
Re: [Qemu-devel] Emulating powerpc 440EP with qemu-system-ppcemb
On Monday 24 January 2011 01:22 AM, Andreas Färber wrote: Am 23.01.2011 um 19:42 schrieb Rob Landley: On 01/23/2011 06:59 AM, Dushyant Bansal wrote: When I try to run this command, # qemu-system-ppcemb -nographic -m 128 -M bamboo -kernel uImage -append I get the following output and qemu just hangs there: Trying to read privileged spr 947 3b3 at 1028 Trying to read invalid spr 62 03e at 0778 Last I checked, the bamboo board was implemented for KVM not QEMU, and QEMU didn't have a ppc440 processor emulation. But that was over a year ago, things could easily have changed... Matches my info. No ppc440 series since then. Andreas $ ./qemu-system-ppc -cpu ? | grep 440 This is the output. PowerPC 440-Xilinx PVR 7ff21910 qemu version: 0.13.50. Will it work for ppc440 processor emulation? Dushyant
[Qemu-devel] Error running qemu on powerpc
Hi, I have installed qemu on x86 system. I downloaded debian-powerpc image from http://people.debian.org/~aurel32/qemu/powerpc/ and used it with qemu-system-ppc. This is the cpuinfo of the guest os (debian-507-powerpc (2.6.26-1-powerpc) ) processor: 0 cpu: 740/750 temperature : 62-64 C (uncalibrated) clock: 1000.00MHz revision: 3.1 (pvr 0008 0301) bogomips: 33.02 timebase: 16600733 platform: PowerMac model: Power Macintosh machine: Power Macintosh motherboard: AAPL,PowerMac G3 MacRISC detected as: 49 (PowerMac G3 (Silk)) pmac flags: pmac-generation: OldWorld Now, I installed qemu on that guest os , and tried to run the same debian-powerpc image using qemu-system-ppc -nographic on it. After giving some messages about building device tree strings and structure, the boot process got stuck at: Calling quiesce Returning from prom init Thanks, Dushyant
