Hello, everyone,
Now, I'm planning to use Qemu as our mobile device emulator (ARM). Before
our development, I want to confirm performance of it. I use packages from
http://folks.o-hand.com/richard/qemu.html to build the evaluation
environment, but performance of Linux in Qemu is too slow. It
Hi,
I've used distro from http://www.aurel32.net/info/debian_arm_qemu.php.
It's working fine (about 1 minute to boot in my PC).
regards,
Màrius
PianoPan wrote:
Hello, everyone,
Now, I'm planning to use Qemu as our mobile device emulator (ARM).
Before our development, I want to confirm
Anthony Liguori wrote:
Mounting a partition being served on the same host as read-write can
cause deadlocks. From nbd-2.9.0 README file:
This text is pretty old. Is this still valid? This would imply that
things like loop can result in dead locks. I don't see why flushing
one device
Salvador Fandino schrieb:
right now, you can use -o offset and -s size to serve a partition
inside a partitioned disk image. And you can use fdisk or a similar tool
to examine the partition table (they work on /dev/nbd0).
I am also looking for some working code to parse the MBR to incorporate
- write tons of data to nbd device, data ends up in pagecache
- memory gets low, kswapd wakes up, calls nbd device to actually write
the data
- nbd issues a request, which ends up on the nbd server on the same machine
- the nbd server allocates memory
- memory allocation hangs waiting for kswapd
2006/12/13, PianoPan [EMAIL PROTECTED]:
performance of Linux in Qemu is too slow. It
uses about one hour to boot GUI system.
During development work this summer at one point I experienced an
immense slowdown of QEMU - from 63 bogomips to 1 or 2 on a 400MHz
Pentium. The problem went away when I
Martin Guy wrote:
- write tons of data to nbd device, data ends up in pagecache
- memory gets low, kswapd wakes up, calls nbd device to actually write
the data
- nbd issues a request, which ends up on the nbd server on the same
machine
- the nbd server allocates memory
- memory allocation
I am using qemu 0.8.2 built from source. In the qemu technical
documentation for features under full system emulation, it says:
QEMU can either use a full software MMU for maximum portability or use
the host system call mmap() to simulate the target MMU.
However, I cannot find a way to
Hi Màrius:
It's working fine (about 1 minute to boot in my PC).
Did you mean that 1 minute to boot the X system?
Regards !
Piano Pan
On 12/13/06, Màrius Montón [EMAIL PROTECTED] wrote:
Hi,
I've used distro from http://www.aurel32.net/info/debian_arm_qemu.php.
It's working fine
2006/12/13, Martin Guy [EMAIL PROTECTED]:
2006/12/13, PianoPan [EMAIL PROTECTED]:
performance of Linux in Qemu is too slow. It
uses about one hour to boot GUI system.
During development work this summer at one point I experienced an
immense slowdown of QEMU - from 63 bogomips to 1 or 2
I pulled the latest code to rebuild my patch and I get compile errors on
usb-linux.c. What do I need to change to get clean compiles?
Chuck
--
In file included from /qemu-new/usb-linux.c:29:
/usr/include/linux/usbdevice_fs.h:49: error: variable or field `__user'
declared void
On Wednesday 13 December 2006 15:23, Chuck Brazie wrote:
I pulled the latest code to rebuild my patch and I get compile errors on
usb-linux.c. What do I need to change to get clean compiles?
Your kernel headers are broken. See list archives.
Paul
On Wednesday 13 December 2006 14:40, Tim Olson wrote:
I am using qemu 0.8.2 built from source. In the qemu technical
documentation for features under full system emulation, it says:
QEMU can either use a full software MMU for maximum portability or use
the host system call mmap() to simulate
Tim Olson wrote:
I am using qemu 0.8.2 built from source. In the qemu technical
documentation for features under full system emulation, it says:
QEMU can either use a full software MMU for maximum portability or
use the host system call mmap() to simulate the target MMU.
However, I cannot
Hi David...
I started playing with nspluginwrapper -- and finally got annoyed with
the fact that not even /bin/echo from current i386 userspace will run in
qemu-i386 any more. So I had a go at implementing set_thread_area, futex
and set_tid_address.
A small request, if you are willing to do
Hi Salvador...
The patch available from http://qemu-forum.ipi.fi/viewtopic.php?t=2718 adds
a new utility, qemu-nbds, that implements a NBD server (see
http://nbd.sf.net) for QEMU images.
Using this utility it is posible to mount images in any format supported by
QEMU.
Good work IMHO !
On Wed, 2006-12-13 at 23:02 +0700, Mulyadi Santosa wrote:
A small request, if you are willing to do it though I think this patch is
really useful (IIRC NPTL is a long time trouble with qemu-i386), so instead
of leaving this patch just archieved inside qemu-devel, could you please post
On Wednesday 13 December 2006 17:01, David Woodhouse wrote:
On Wed, 2006-12-13 at 23:02 +0700, Mulyadi Santosa wrote:
A small request, if you are willing to do it though I think this
patch is really useful (IIRC NPTL is a long time trouble with qemu-i386),
so instead of leaving this
On Wed, 2006-12-13 at 17:22 +, Paul Brook wrote:
I've a nasty feeling you're going to break the host libc if you do threading
this way. One possibly solution is to use the pthreads API instead, and map
everything onto that.
Qemu doesn't use the host's threading support, does it?
--
David Woodhouse wrote:
On Wed, 2006-12-13 at 23:02 +0700, Mulyadi Santosa wrote:
A small request, if you are willing to do it though I think this patch
is
really useful (IIRC NPTL is a long time trouble with qemu-i386), so instead
of leaving this patch just archieved inside
On Wednesday 13 December 2006 17:32, David Woodhouse wrote:
On Wed, 2006-12-13 at 17:22 +, Paul Brook wrote:
I've a nasty feeling you're going to break the host libc if you do
threading this way. One possibly solution is to use the pthreads API
instead, and map everything onto that.
On 12/12/06, Kirill Shutemov [EMAIL PROTECTED] wrote:
I have no ideas why path.c is so complex. Any? In the attachment
rewritten version. It has tested with qemu-arm.
With old version I had the problem. It hangs due loop of symlinks. :(
Any comments?
On Wed, 2006-12-13 at 17:42 +, Paul Brook wrote:
Qemu doesn't currently have any real thread support. It has a few hacks that
work for simple linuxthreads cases, but I doubt real multithreaded
applications will work.
My point was that instead of blindly passing the threading syscalls
- sys_set_tid_address():
- clone(CLONE_CHILD_CLEARTID):
We _could_ manage to do this in qemu for controlled thread exit -- it
would be hard for uncontrolled exit though. But I don't see any harm in
just letting the kernel do it either. I don't mind too much, but if we
can let the kernel do
qemu allows redirecting the monitor to a named pipe (fifo): if you
specify -monitor pipe:/my/fifo, it opens /my/fifo and uses it for
communication in both directions.
Unfortunately pipes are unidirectional on Linux. The pipe(7) man page
says: Portability notes: On some systems (but not Linux),
Jan Marten Simons wrote:
Salvador Fandino schrieb:
right now, you can use -o offset and -s size to serve a partition
inside a partitioned disk image. And you can use fdisk or a similar tool
to examine the partition table (they work on /dev/nbd0).
I am also looking for some working code to
Avi Kivity wrote:
Martin Guy wrote:
- write tons of data to nbd device, data ends up in pagecache
- memory gets low, kswapd wakes up, calls nbd device to actually write
the data
- nbd issues a request, which ends up on the nbd server on the same
machine
- the nbd server allocates memory
-
Paul Brook wrote:
- sys_set_tid_address():
- clone(CLONE_CHILD_CLEARTID):
We _could_ manage to do this in qemu for controlled thread exit -- it
would be hard for uncontrolled exit though. But I don't see any harm in
just letting the kernel do it either. I don't mind too much, but if we
can let
On Wed, Dec 13, 2006 at 08:03:13PM +0100, Salvador Fandino wrote:
The code of lomount might be what you're looking for. Lomount allows one
to mount partions (via loop) from a raw diskimage.
That was my intention, but I have found that lomount handling of EBR and
logical partition is not
Jim C. Brown wrote:
On Wed, Dec 13, 2006 at 08:03:13PM +0100, Salvador Fandino wrote:
The code of lomount might be what you're looking for. Lomount allows one
to mount partions (via loop) from a raw diskimage.
That was my intention, but I have found that lomount handling of EBR and
logical
On Wed, Dec 13, 2006 at 11:07:54PM +0100, Salvador Fandino wrote:
Jim C. Brown wrote:
On Wed, Dec 13, 2006 at 08:03:13PM +0100, Salvador Fandino wrote:
The code of lomount might be what you're looking for. Lomount allows one
to mount partions (via loop) from a raw diskimage.
That was my
David Woodhouse wrote:
- sys_futex():
We have to translate these into calls to the host's sys_futex() anyway.
I don't think it's necessary to translate to the host's sys_futex(),
unless the guest will be doing futex operations on memory which the
host _also_ does futex operations on.
Hi all,
I am in the process of learning QEMU Mechanism by doing a code review.
I need to know the Virtual Image File and how does the Gust Os IO mechanisms
are transfered in to the Host Os Image file .
If anyone could point me the Source Code Portian which handles this part it
33 matches
Mail list logo
