Re: [Qemu-devel] fat rw status
2007/10/17, Ricardo Almeida <[EMAIL PROTECTED]>: > Hi, > > I've sent a message 4 days ago but got no answer :( > > http://lists.gnu.org/archive/html/qemu-devel/2007-10/msg00314.html > > From: Ricardo Almeida > Subject:[Qemu-devel] fat rw > Date: Sat, 13 Oct 2007 23:50:17 +0100 > > Hi, > > I've found the fat:rw:dir option for harddrives and want to use it :) > But when I run: > > qemu-system-x86_64 -kernel-kqemu -m 256 -hda winxp.qcow -hdb > fat:rw:/media/lacie/ > > I get: > > qemu: could not open hard disk image 'fat:rw:/media/lacie/' > > I've seen in qemu forums > (http://qemu-forum.ipi.fi/viewtopic.php?p=12250) someone with a > similar problem and the following solution: > > [QUOTE] > I am not sure this the correct solution, and I have no idea of what I > am doing, but by changing the bdrv_create call in enable_write_target > to: > > Code: > > if (bdrv_create(&bdrv_qcow, >s->qcow_filename, s->sector_count, NULL, 0) < 0) > > > This causes QEMU to start correctly and writes to the virtual disk > work correctly. > [/QUOTE] > > I'm using Kubuntu Gutsy with QEmu 0.9.0 from repository package with > kqemu_1.3.0pre11, so "I can't" patch QEmu. I would like to know if > this is already fixed on CVS or what's the current status. Last time I tried to find out why :rw: didn't work I also came over this issue. I also removed the "fat:" part and indeed I was able to start qemu with fat:rw: and it did write to the virtual drive. What wasn't happening was updating the host files. All changes to that virtual drive are lost. So the above change doesn't fix write support. It probably have to do with the fact that the temporal image created above must be snapshot of (another) block_vvfat, then the original vvfat hijacks the 2'd vvfat and tries to place its routines there(and if there is no slave block device the writes would never be piped to vvfat). It's very hackish and very broken (I think cow driver always looks for file, so it tries to open "/tmp/fat:" instead and always fails). One possible solution is to special case the "fat:" opening. Or to make main block code to always create the temporal snapshot device before original vvfat creation (and not create second in case of snapshot). Still the vvfat would have to access it directly... that is still quite hackish, snapshots would still would need special handling. Another solution is to remove all hacks, fat:rw just creates temporal image and doesn't try to (re)use any automatic snapshot functionality. The block writes that vvfat cannot process will have to be stored in the temp image manually, and eventually to be found, read and freed when they can finally be processed and written on the host. I think this is the cleanest solution. Anyway, At that time, I decided it would take me quite too much time to properly fix it, so I left it after I finish my current project. I guess in week or two I may have some free time. (Of course the original author would be able to fix it faster, as he is already quite familiar with the code).
[Qemu-devel] about cache model in ARM emulation
Hello I'm a newbie in the use of ARM simulators. I got yesterday a question from my teacher and can't find the answer. I would like to know weather QEMU simulates a cache miss (cache miss holds a penalty in terms of clock cycles or clock cycles counted) for an ARM-type core. >From what I can see instructions are loaded from memory without a clock cycle >penalty, but I wanted to be sure. Thanks Gabi V. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: [Qemu-devel] about cache model in ARM emulation
On Thu, Oct 18, 2007 at 06:57:19AM -0700, Boy Dfx wrote: > From what I can see instructions are loaded from memory without a > clock cycle penalty, but I wanted to be sure. Yes. Qemu is absolutely useless for performance questions about real hardware; it does not model any cycles. -- Daniel Jacobowitz CodeSourcery
[Qemu-devel] qemu/hw mips_mipssim.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 07/10/18 15:05:11 Modified files: hw : mips_mipssim.c Log message: Only map BIOS space when it was actually loaded. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_mipssim.c?cvsroot=qemu&r1=1.1&r2=1.2
[Qemu-devel] qemu configure linux-user/elfload.c linux-user/...
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer 07/10/18 19:59:50 Modified files: . : configure linux-user : elfload.c main.c Log message: Use the new TARGET_ABI32 feature to implement a ppc64abi32-linux-user target (PowerPC 64 running in 32 bits mode). Use the new TARGET_ABI_DIR feature to implement a ppcemb-linux-user target (PowerPC 32 with 64 bits GPRs and vector extensions). CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/configure?cvsroot=qemu&r1=1.163&r2=1.164 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/elfload.c?cvsroot=qemu&r1=1.52&r2=1.53 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/main.c?cvsroot=qemu&r1=1.134&r2=1.135
[Qemu-devel] qemu configure linux-user/ppc/syscall.h linux-u...
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer 07/10/18 20:51:49 Modified files: . : configure linux-user/ppc : syscall.h syscall_nr.h Removed files: linux-user/ppc64: syscall.h syscall_nr.h target_signal.h termbits.h Log message: Use TARGET_ABI_DIR feature to unify PowerPC and PowerPC 64 definitions. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/configure?cvsroot=qemu&r1=1.164&r2=1.165 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/ppc/syscall.h?cvsroot=qemu&r1=1.5&r2=1.6 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/ppc/syscall_nr.h?cvsroot=qemu&r1=1.2&r2=1.3 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/ppc64/syscall.h?cvsroot=qemu&r1=1.4&r2=0 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/ppc64/syscall_nr.h?cvsroot=qemu&r1=1.2&r2=0 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/ppc64/target_signal.h?cvsroot=qemu&r1=1.3&r2=0 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/ppc64/termbits.h?cvsroot=qemu&r1=1.3&r2=0
[Qemu-devel] Debugging x86-64 apps from a 32bit host?
Hi, is it possible to debug e.g. a x86-64 Linux kernel running in qemu-system-x86_64 on a 32bit host from that host with GDB? I cross-compiled a version of GDB with x86-64 support, so it can load the debugging symbols from the kernel (which is an ELF64 binary) and attached that to a running qemu-system-x86_64, but it always tells me the instruction pointer is at 0x0. Is this supported by QEMU? Thanks, Simon
Re: [Qemu-devel] I got a kernel booted under qemu-system-ppc !
On Thu, 2007-10-18 at 19:12 -0500, Rob Landley wrote: > The easy way to reproduce this is go to "http://landley.net/hg/firmware";, > download tip, and "./build.sh powerpc". When it finishes building > everything, cd build and "./run-powerpc.sh". > [...] > The downside is that the result boots fine under qemu-0.9.0, but is broken > with current cvs. I tracked it down to the specific patch with "git bisect", > and it's this one: > > http://git.kernel.dk/?p=qemu.git;a=commit;h=36f447f730f61ac413c5b1c4a512781f5dea0c94 > > author j_mayer > Mon, 9 Apr 2007 22:45:36 + (22:45 +) > committer j_mayer > Mon, 9 Apr 2007 22:45:36 + (22:45 +) What is strange is that it was reported as unable to boot long before this patch. It was broken when the Qemu PCI architecture has been redesigned and have never been reported booting since then (2 years ago, if I remember well). In march 2007, I did test and reported that PreP and heathrow target were unable to boot, not receiving any IRQ from PCI (in fact, adding traces proves there are even no IRQ generated in the PCI code). Someone reported the faulty patch during this summer (but I've not been unable to find the mail in the mailing list archive tonight). I have to admit I never put the focus on trying to solve this issue, has I usually use Mac99 or PowerPC 405 targets for tests and that PreP machines are long obsolete and the heathrow target does not reflect any real machine. But this is to be solved, for sure. -- J. Mayer <[EMAIL PROTECTED]> Never organized
Re: [Qemu-devel] qemu-system-m68k and booting m68k images
On Thursday 11 October 2007 2:15:25 am Rob Landley wrote: > Back in July, Andreas Schwab posted a patch to upgrade the coldfire support > to full m68k support (or at least the instructions output by gcc): > http://lists.gnu.org/archive/html/qemu-devel/2007-07/msg00015.html Has there been any progress or follow-up on this? (I'm interested. I have a m68k target building at http://landley.net/hg/firmware but don't know how to test it with the current qemu development branch...) Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson.
[Qemu-devel] I got a kernel booted under qemu-system-ppc !
The easy way to reproduce this is go to "http://landley.net/hg/firmware";,
download tip, and "./build.sh powerpc". When it finishes building
everything, cd build and "./run-powerpc.sh".
What I did is build a new ppc_rom.bin (attached, source code is at
http://landley.net/hg/firmware/raw-diff/92f89c9c9495/sources/toys/make-ppc_rom.tar.bz2
)
which was written by Milton Miller. I use that firmware as the boot rom
(point -L at the directory it's in) instead of Open Hackware, which still
doesn't work for me.
Then I build a 2.6.23 kernel with this patch:
http://landley.net/hg/firmware/raw-diff/fdb6ddd4c3b7/sources/patches/linux-ppcqemu.patch
which adds a "qemu" target.
I then boot with the following command line (modulo wordwrap damage):
qemu-system-ppc -M prep -nographic -hda image-powerpc.ext2 -kernel
zImage-powerpc -append 'rw init=/tools/bin/sh panic=1 PATH=/tools/bin
root=/dev/hda console=ttyS0' -L ../sources/toys
And I get a shell prompt inside qemu! (After almost _two_years_ of trying,
I'm kind of happy about this.)
The downside is that the result boots fine under qemu-0.9.0, but is broken
with current cvs. I tracked it down to the specific patch with "git bisect",
and it's this one:
http://git.kernel.dk/?p=qemu.git;a=commit;h=36f447f730f61ac413c5b1c4a512781f5dea0c94
author j_mayer
Mon, 9 Apr 2007 22:45:36 + (22:45 +)
committer j_mayer
Mon, 9 Apr 2007 22:45:36 + (22:45 +)
Implement embedded IRQ controller for PowerPC 6xx/740 & 750.
Fix PowerPC external interrupt input handling and lowering.
Fix OpenPIC output pins management.
Fix multiples bugs in OpenPIC IRQ management.
Fix OpenPIC CPU(s) reset function.
Fix Mac99 machine to properly route OpenPIC outputs to the PowerPC input
pins.
Fix PREP machine to properly route i8259 output to the PowerPC external
interrupt pin.
Versions before that patch went in work fine. Versions since then hang
halfway through IDE controller initialization:
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
hda: QEMU HARDDISK, ATA DISK drive
hda: IRQ probe failed (0x0)
hdb: IRQ probe failed (0x0)
hdb: IRQ probe failed (0x0)
hdb: QEMU CD-ROM, ATAPI CD/DVD-ROM drive
hdb: IRQ probe failed (0x0)
<-- hangs here with the patch
ide0 at 0x1f0-0x1f7,0x3f6 on irq 13
hda: max request size: 512KiB
hda: 4194304 sectors (2147 MB) w/256KiB Cache, CHS=4161/255/63
hda: set_multmode: status=0x41 { DriveReady Error }
hda: set_multmode: error=0x04 { DriveStatusError }
ide: failed opcode was: 0xef
hda: cache flushes supported
hda: unknown partition table
mice: PS/2 mouse device common for all mice
Rob
--
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
ppc_rom.bin
Description: Binary data
