[Qemu-devel] About performance of qemu-system-arm

[PianoPan]

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 uses about one
hour to boot GUI system.



Can anybody tell me this performance is proper or not?

Best regards!
Piano Pan
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] About performance of qemu-system-arm

[Màrius Montón]

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 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 uses about one hour to boot GUI system.
>
>  
>
> Can anybody tell me this performance is proper or not?
>
> Best regards!
>
> Piano Pan
> 
>
> ___
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>   

-- 
Màrius Montón i Macián   [EMAIL PROTECTED]
  http://cephis.uab.es

Hardware Engineer
CEPHIS
Centre de Prototips i Solucions Hardware-Software
Dep. Microelectrònica i Sistemes Electrònics
ETSE - Universitat Autònoma de Barcelona (UAB)  Phone: +34 935 813 534
Fax: +34 935 813 033
QC-2090D. ETSE. Campus UAB.
080193 Bellaterra


begin:vcard
fn;quoted-printable:M=C3=A0rius Mont=C3=B3n
n;quoted-printable;quoted-printable:Mont=C3=B3n;M=C3=A0rius
org;quoted-printable:CEPHIS;Microelectr=C3=B2nica i Sistemes Electronics
adr:Campus de la UAB;;QC-2090D, ETSE;Bellaterra;Barcelona;08193;Spain
email;internet:[EMAIL PROTECTED]
title:HW Engineer
tel;work:+34935813534
tel;fax:+34935813033
x-mozilla-html:TRUE
url:http://cephis.uab.es
version:2.1
end:vcard


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Re: NBD server for QEMU images

[Avi Kivity]

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 would depend on the completion of another device.  
Otherwise, if you had two disk adapters, they would always be 
operating in lock step.


As I've said, I've never seen a problem doing-write with nbd on 
localhost.


A deadlock can happen under heavy I/O load:

- 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

I submitted a patch/workaround for this some years ago (for a similar 
problem with a local mount to a userspace nfs server).



--
error compiling committee.c: too many arguments to function



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Re: RE : Re: Re: NBD server for QEMU images

[Jan Marten Simons]

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
it in qemu-nbds (something as libparted but simpler), so it would be
possible to just indicate the partition number to serve.

- Salva
  
The code of lomount might be what you're looking for. Lomount allows one 
to mount partions (via loop) from a raw diskimage.



- Jan



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Subject: Re: [Qemu-devel] SCSI externals [PATCH] revisited

[Chuck Brazie]

>>I was able to apply the patch (almost) cleanly to a November snapshot.
>>The following invocation results in the LSI controller showing up in
>>Windows XP, but the disk(s) do not. Am I missing something?

I missed setting the SCSI device type enum value, sorry. I will make a new 
full
patch with that and with the texi update also. I guess I was too focused
on not messing up the old IDE behavior. :-)

>>qemu -kernel-kqemu -localtime -std-vga \
>>   -disk ide,img=winxp.qcow \
>>   -disk scsi,img=test.qcow

>>It doesn't seem possible to boot from a SCSI disk currently. In fact,
>>there's a check in vl.c to see if there is at least one IDE disk that
>>just dumps the usage output without an error which was rather confusing
>>:-P. I'm thinking that the emulated BIOS doesn't support SCSI yet?

Since SCSI boot is not in there yet, I left it at the default behavior of 
putting up the help text. 

Would it be better to put out a message, then the help text or just the 
message, or leave as is?



Chuck Brazie 
[EMAIL PROTECTED]



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Re: NBD server for QEMU images

[Martin Guy]

- 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


In other words, it can deadlock only if you are swapping to an nbd
device that is served by nbd-server running on the same machine and
kernel. In the case of a qemu system swapping over nbd to a server on
the host machine, it is the guest kernel that waits on the host kernel
paging the nbd server in from the host's separate swap space, so no
deadlock is possible.

Practice bears this out; if you wanna stress-test it, here's a program
that creates a low memory condition by saturating the VM.

Of course, this has nothing to do with the original patch, which just
lets nbd-server interpret qemu image files ;)

   M
/*
 * thrash.c
 *
 * A standalone Unix command-line program to
 * make the machine thrash, ie go into permanent swapping,
 * by using VM >= RAM size and accessing all pages repeatedly
 *
 * Usage: thrash size
 * where "size" is the number of megabytes to thrash
 * A good choice for N is the number of megabytes of physical RAM
 * that the machine has.
 *
 * Reason:
 * to force a machine to use its swap space,
 * to flush all unused pages out to swap and so free RAM for other purposes
 * or to see how a system behaves under extreme duress.
 *
 * It currently *writes* to all pages, but could be made to read them
 * as an alternative, or as well.
 *
 *	Martin Guy, 9 November 2006
 */

#include 	/* for exit() */
#include 
#include 	/* for system calls */

main(int argc, char **argv)
{
	int megabytes = 0; /* MB of VM to thrash, from command-line argument.
* 0 means uninitialised */
	char *buf;	/* Huge VM buffer */
	intptr_t bufsize;	/* Size of buffer in bytes */
	long pagesize;	/* size of VM page */
	int i;		/* index into argv */
	int verbose = 0; /* Print a dot for every pass through VM? */

	pagesize = getpagesize();

	for (i=1; i0; p+=pagesize, i--)
			*p=(char) i;
		if (verbose) { putchar('.'); fflush(stdout); }
	}
	/* NOTREACHED */
}
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] About performance of qemu-system-arm

[Martin Guy]

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 upgraded the ARM linux kernel
that QEMU was running from 2.6.16 to 2.6.16-rc3 and the problem has
not come back with later versions (.17 .18)

 M


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Re: NBD server for QEMU images

[Avi Kivity]

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 hangs waiting for kswapd


In other words, it can deadlock only if you are swapping to an nbd
device that is served by nbd-server running on the same machine and
kernel. 


No.  It is possible if you issue non-O_SYNC writes.


In the case of a qemu system swapping over nbd to a server on
the host machine, it is the guest kernel that waits on the host kernel
paging the nbd server in from the host's separate swap space, so no
deadlock is possible.

Practice bears this out; if you wanna stress-test it, here's a program
that creates a low memory condition by saturating the VM.


It isn't enough to thrash the guest, you need to exhaust host memory as 
well.  You also need to do it faster than kswapd can write it out.




Of course, this has nothing to do with the original patch, which just
lets nbd-server interpret qemu image files ;)



Agreed.  But mounting nbd from localhost is dangerous.

--
error compiling committee.c: too many arguments to function



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] qemu-system-* using mmap?

[Tim Olson]

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 build a full system simulator which 
does not define SOFTMMU -- in fact, the configure parameters 
"--disable-system" and "--enable-system" directly control the softmmu 
switch.  There are some mmap() calls in the kqemu code, but to use that 
requires full kqemu support code in the kernel.


I think there is a big performance hit using the software mmu, as each 
target load or store instruction is expanded into 20-30 host 
instructions to perform the translation.  Is there a way to build the 
qemu-system-* emulators using the mmap() feature mentioned in the 
documentation?


-- Tim Olson



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] About performance of qemu-system-arm

[PianoPan]

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 (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 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 uses about one hour to boot 
GUI system.



Can anybody tell me this performance is proper or not?

Best regards! Piano Pan
   



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel



--

   Màrius Montón i Macián[EMAIL PROTECTED] http://cephis.uab.es
   Hardware Engineer
CEPHIS
   Centre de Prototips i Solucions Hardware-Software
 Dep. Microelectrònica i Sistemes Electrònics
 ETSE - Universitat Autònoma de Barcelona (UAB) Phone: +34 935 813 534
Fax: +34 935 813 033
QC-2090D. ETSE. Campus UAB.
080193 Bellaterra

___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel







___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] About performance of qemu-system-arm

[Martin Guy]

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


Sorry I forgot to say, that was with qemu-system-arm 0.8.2

The sort of performance you should be seeing is, for example, a 2GHz
AMD or a 4GHz Intel giving the same realtime speed as a 100-200MHz
ARM.

   M


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] usb-linux.c compile error on latest code

[Chuck Brazie]

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

/usr/include/linux/usbdevice_fs.h:49: error: syntax error before '*' token
/usr/include/linux/usbdevice_fs.h:56: error: variable or field `__user' 
declared void

/usr/include/linux/usbdevice_fs.h:56: error: syntax error before '*' token
/usr/include/linux/usbdevice_fs.h:66: error: variable or field `__user' 
declared void

/usr/include/linux/usbdevice_fs.h:66: error: syntax error before '*' token
/usr/include/linux/usbdevice_fs.h:100: error: variable or field `__user' 
declared void

/usr/include/linux/usbdevice_fs.h:100: error: syntax error before '*' token
/usr/include/linux/usbdevice_fs.h:109: error: syntax error before '}' token
/usr/include/linux/usbdevice_fs.h:116: error: variable or field `__user' 
declared void

/usr/include/linux/usbdevice_fs.h:116: error: syntax error before '*' token
/qemu-new/usb-linux.c: In function `usb_host_handle_control':
/qemu-new/usb-linux.c:102: error: invalid application of `sizeof' to an 
incomplete type

/qemu-new/usb-linux.c: In function `usb_host_handle_data':
/qemu-new/usb-linux.c:119: error: storage size of `bt' isn't known
/qemu-new/usb-linux.c:131: error: invalid application of `sizeof' to an 
incomplete type

/qemu-new/usb-linux.c:119: warning: unused variable `bt'
/qemu-new/usb-linux.c: In function `usb_host_device_open':
/qemu-new/usb-linux.c:198: error: storage size of `ctrl' isn't known
/qemu-new/usb-linux.c:201: error: invalid application of `sizeof' to an 
incomplete type

/qemu-new/usb-linux.c:198: warning: unused variable `ctrl'
make[1]: *** [usb-linux.o] Error 1
make[1]: Leaving directory `/qemu-new/i386-softmmu'
make: *** [subdir-i386-softmmu] Error 2





___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] usb-linux.c compile error on latest code

[Paul Brook]

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


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] qemu-system-* using mmap?

[Paul Brook]

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 the target MMU."
>
> However, I cannot find a way to build a full system simulator which
> does not define SOFTMMU -- in fact, the configure parameters
> "--disable-system" and "--enable-system" directly control the softmmu
> switch.  There are some mmap() calls in the kqemu code, but to use that
> requires full kqemu support code in the kernel.

This is unrelated.

> I think there is a big performance hit using the software mmu, as each
> target load or store instruction is expanded into 20-30 host
> instructions to perform the translation.  Is there a way to build the
> qemu-system-* emulators using the mmap() feature mentioned in the
> documentation?

No. That feature was removed some time ago. It only worked with modified guest 
OS. Once you start doing that you generally may as well use UML or Xen.
It's actually more like 10 instructions to do the translation.

Paul


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] qemu-system-* using mmap?

[Joseph Miller]

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 find a way to build a full system simulator which 
does not define SOFTMMU -- in fact, the configure parameters 
"--disable-system" and "--enable-system" directly control the softmmu 
switch.  There are some mmap() calls in the kqemu code, but to use 
that requires full kqemu support code in the kernel.


I think there is a big performance hit using the software mmu, as each 
target load or store instruction is expanded into 20-30 host 
instructions to perform the translation.  Is there a way to build the 
qemu-system-* emulators using the mmap() feature mentioned in the 
documentation?


-- Tim Olson



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


Can someone elaborate on this a little?  What is the difference between 
the SOFTMMU and the mmap()?  Should I be using the --enable-system or 
the --disable-system for win32 guest on i386 debian host?  Can someone 
give a little more insight on this technicality?


-Joseph


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] [PATCH]ish NPTL support.

[Mulyadi Santosa]

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 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 
it to qemu user forum too? So, it will be easy for some one else to get this 
patch until your patch gets merged by Fabrice..

Thanks for sharing your work bravo!

regards,

Mulyadi



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] NBD server for QEMU images

[Mulyadi Santosa]

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 ! Although I am sure there are many ways to do this, yours is a 
nice idea and I think it's pretty easy to be maintained too. Like perl motto: 
there are more  than one way to do it :)

regards,

Mulyadi



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] [PATCH]ish NPTL support.

[David Woodhouse]

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 
> it to qemu user forum too? So, it will be easy for some one else to get this 
> patch until your patch gets merged by Fabrice..

Feel free to do so.

Better still, feel free to break it down into simple fixes and feed it
to Fabrice. The only thing that definitely isn't ready is the futex
stuff -- we could merge set_tid_address, set_thread_area and the clone
bits. And especially the QEMU_ASSUME_KERNEL thing.

Could do with testing the CLONE_SETTLS bits too, and making sure
CLONE_PARENT_SETTID and CLONE_CHILD_CLEARTID are implemented. 

-- 
dwmw2



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] [PATCH]ish NPTL support.

[Paul Brook]

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 patch just archieved inside qemu-devel, could
> > you please post it to qemu user forum too? So, it will be easy for some
> > one else to get this patch until your patch gets merged by Fabrice..
>
> Feel free to do so.
>
> Better still, feel free to break it down into simple fixes and feed it
> to Fabrice. The only thing that definitely isn't ready is the futex
> stuff -- we could merge set_tid_address, set_thread_area and the clone
> bits. And especially the QEMU_ASSUME_KERNEL thing.
>
> Could do with testing the CLONE_SETTLS bits too, and making sure
> CLONE_PARENT_SETTID and CLONE_CHILD_CLEARTID are implemented.

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.

Paul


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] [PATCH]ish NPTL support.

[David Woodhouse]

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?

-- 
dwmw2



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] [PATCH]ish NPTL support.

[Thiemo Seufer]

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 qemu-devel, could you please 
> > post 
> > it to qemu user forum too? So, it will be easy for some one else to get 
> > this 
> > patch until your patch gets merged by Fabrice..
> 
> Feel free to do so.
> 
> Better still, feel free to break it down into simple fixes and feed it
> to Fabrice.

Or send the broken down versions to this list, I (or pbrook) can then
commit the easy bits at least.


Thiemo


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] [PATCH]ish NPTL support.

[Paul Brook]

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.
>
> Qemu doesn't use the host's threading support, does it?

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 through to 
the host we should consider using the host libc/libpthread thread support.

Paul


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] Re: [PATCH] Simplily linux-user/path.c

[Kirill Shutemov]

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?


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] [PATCH]ish NPTL support.

[David Woodhouse]

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 through 
> to 
> the host we should consider using the host libc/libpthread thread support. 

Well, let's break things down individually.

- sys_set_thread_area():
- sys_get_thread_area():
- clone(CLONE_SETTLS)

This _is_ handled in qemu, since it's just a case of loading new stuff
into the emulated GDT. (Well, I didn't do get_thread_area but it's
simple).

- sys_futex():

We have to translate these into calls to the host's sys_futex() anyway.
I need to go through the rest of the futex operations and see how many
we can emulate cross-endian, and perhaps add some kernel support to make
the answer "all of them".

- 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 it I'm happier that way.

- clone(CLONE_PARENT_SETTID):
- clone(CLONE_CHILD_SETTID):

We need endianness-mangling on these so we have to get involved somehow.
But I think we do need to use the kernel's support and then marshal the
result back to the guest's memory.

-- 
dwmw2



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] [PATCH]ish NPTL support.

[Paul Brook]

> - 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 it I'm happier that way.

The harm occurs if the host libc had per-thread state (eg. it has thread local 
variables). If we bypass the host thread library then libc doesn't have 
chance to initialize it's per-thread structures for that new thread, and bad 
things are liable to happen then that thread uses libc functions.

> We need endianness-mangling on these so we have to get involved somehow.
> But I think we do need to use the kernel's support and then marshal the
> result back to the guest's memory.

Once you start proxying things to convert endianness I'd expect it to be 
easier to just emulate everything.


Even when you implement all the syscalls qemu still won't work reliably. In 
particular loads and stores will not be atomic. On real hardware a word 
aligned load or store is guaranteed to complete atomically. qemu sometimes 
splits these into multiple byte accesses, so the guest could see a partial 
access. There are also memory ordering issues (x86 has comparatively strong 
memory ordering guarantees, other hosts require a memory barrier to enforce 
proper ordering). I've seen both these cause failures in in real 
applications.

Paul


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] Unidirectional pipe support

[Ed Swierk]

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), pipes are
bidirectional: data can be transmitted in both directions between the
pipe ends. According to POSIX.1-2001, pipes only need to be
unidirectional. Portable applications should avoid reliance on
bidirectional pipe semantics."

When qemu writes into the pipe, it immediately reads back what it just
wrote and treats it as a monitor command, endlessly breathing its own
exhaust.

The attached patch changes qemu to first try opening a pair of pipes,
"/my/fifo.in" and "/my/fifo.out",  and uses each to communicate in a
single direction. If either file cannot be opened, it reverts to the
current behavior, using "/my/fifo" bidirectionally.

--Ed
Index: qemu-0.8.2/vl.c
===
--- qemu-0.8.2.orig/vl.c
+++ qemu-0.8.2/vl.c
@@ -1285,12 +1285,19 @@ CharDriverState *qemu_chr_open_file_out(
 
 CharDriverState *qemu_chr_open_pipe(const char *filename)
 {
-int fd;
+int fd_in, fd_out;
+char filename_in[256], filename_out[256];
 
-fd = open(filename, O_RDWR | O_BINARY);
-if (fd < 0)
-return NULL;
-return qemu_chr_open_fd(fd, fd);
+snprintf(filename_in, 256, "%s.in", filename);
+snprintf(filename_out, 256, "%s.out", filename);
+fd_in = open(filename_in, O_RDWR | O_BINARY);
+fd_out = open(filename_out, O_RDWR | O_BINARY);
+if (fd_in < 0 || fd_out < 0) {
+fd_in = fd_out = open(filename, O_RDWR | O_BINARY);
+if (fd_in < 0)
+return NULL;
+}
+return qemu_chr_open_fd(fd_in, fd_out);
 }
 
 
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] Re: RE : Re: Re: NBD server for QEMU images

[Salvador Fandino]

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 parse the MBR to incorporate
>> it in qemu-nbds (something as libparted but simpler), so it would be
>> possible to just indicate the partition number to serve.
>>
>> - Salva
>>   
> 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 correct, they perform as if EBR where
structured as MBR, what is wrong!

Anyway, I have implemented the partition table parsing from scratch and
upload a new version of qemu-nbds.c to the QEMU forum.

Cheers,

  - Salva



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] Re: NBD server for QEMU images

[Salvador Fandino]

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
>>> - memory allocation hangs waiting for kswapd
>>
>> In other words, it can deadlock only if you are swapping to an nbd
>> device that is served by nbd-server running on the same machine and
>> kernel. 
> 
> No.  It is possible if you issue non-O_SYNC writes.

I have run some tests and found that it's easy to cause a deadlock just
untaring a file over an nbd device being served from localhost (using
the standard nbd-server or my own, it doesn't matter).

Another interesting finding is that when the deadlock happens, qemu-nbds
is inside a read() call, waiting for new nbd requests to arrive over the
socket, and so, not trying to allocate memory or writing to disk.

BTW, I am using Debian unstable with kernel 2.6.18-1-686

Regards,

 - Salva




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] [PATCH]ish NPTL support.

[Fabrice Bellard]

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 the kernel do it I'm happier that way.



The harm occurs if the host libc had per-thread state (eg. it has thread local 
variables). If we bypass the host thread library then libc doesn't have 
chance to initialize it's per-thread structures for that new thread, and bad 
things are liable to happen then that thread uses libc functions.




We need endianness-mangling on these so we have to get involved somehow.
But I think we do need to use the kernel's support and then marshal the
result back to the guest's memory.



Once you start proxying things to convert endianness I'd expect it to be 
easier to just emulate everything.



Even when you implement all the syscalls qemu still won't work reliably. In 
particular loads and stores will not be atomic. On real hardware a word 
aligned load or store is guaranteed to complete atomically. qemu sometimes 
splits these into multiple byte accesses, so the guest could see a partial 
access. There are also memory ordering issues (x86 has comparatively strong 
memory ordering guarantees, other hosts require a memory barrier to enforce 
proper ordering). I've seen both these cause failures in in real 
applications.


Paul


Another point is that the dynamic translator itself is not thread safe 
(I tried to implement thread safety a long time ago, but it is not 
finished).


Using the pthreads may not be necessary provided we assume the host 
kernel supports NPTL. I don't think it is worth to spend time on the 
case where the host kernel does not support NPTL.


Fabrice.


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Re: RE : Re: Re: NBD server for QEMU images

[Jim C. Brown]

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 correct, they perform as if EBR where
> structured as MBR, what is wrong!
> 
> Cheers,
> 
>   - Salva
> 

How is it incorrect? What needs to be fixed?

My understanding is that the extended partition has a partition table
set up with the first partition entry pointing to the logical partition,
the second entry pointing to a partition table that exists immediately
after the logical partition, and then the 3rd and 4th entries are not
used. The second partition table is structed the same way, so you
essentially have a linked list of extended partitions. (Unlike the MBR,
there are no boot sectors associated with these partition tables.)

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] Re: RE : Re: Re: NBD server for QEMU images

[Salvador Fandino]

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 partition is not correct, they perform as if EBR where
>> structured as MBR, what is wrong!
>>
>> Cheers,
>>
>>   - Salva
>>
> 
> How is it incorrect? What needs to be fixed?
> 
> My understanding is that the extended partition has a partition table
> set up with the first partition entry pointing to the logical partition,
> the second entry pointing to a partition table that exists immediately
> after the logical partition, and then the 3rd and 4th entries are not
> used. The second partition table is structed the same way, so you
> essentially have a linked list of extended partitions. (Unlike the MBR,
> there are no boot sectors associated with these partition tables.)
> 

yes, that's right, but it's not what lomount does. It parses the data on
the EBR in the same way as the MBR, reading 4 partition registers from them.

EBRs are explained here: http://en.wikipedia.org/wiki/Extended_Boot_Record

I believe that the implementation in the last version of qemu-nbds I
have uploaded to the forum is correct.

Cheers,

  - Salva



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Re: RE : Re: Re: NBD server for QEMU images

[Jim C. Brown]

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 intention, but I have found that lomount handling of EBR and
> >> logical partition is not correct, they perform as if EBR where
> >> structured as MBR, what is wrong!
> >>
> >> Cheers,
> >>
> >>   - Salva
> >>
> > 
> > How is it incorrect? What needs to be fixed?
> > 
> > My understanding is that the extended partition has a partition table
> > set up with the first partition entry pointing to the logical partition,
> > the second entry pointing to a partition table that exists immediately
> > after the logical partition, and then the 3rd and 4th entries are not
> > used. The second partition table is structed the same way, so you
> > essentially have a linked list of extended partitions. (Unlike the MBR,
> > there are no boot sectors associated with these partition tables.)
> > 
> 
> yes, that's right, but it's not what lomount does. It parses the data on
> the EBR in the same way as the MBR, reading 4 partition registers from them.
> 

It only uses the first two. It reads in the rest but ignores them.

> Cheers,
> 
>   - Salva
> 
> 
> 
> ___
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] [PATCH]ish NPTL support.

[Jamie Lokier]

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.

CLONE_CHILD_CLEARTID is one of those, if it's simply relayed to the host.
So are locks in shared memory, if they are to work between host and
guest processes.  But I guess they are not expected to work.

The atomicity, queueing etc. semantics, provided they are only among
threads of a single qemu process, can be guaranteed using normal
pthreads locking and atomic operations, analogous to the way the host
kernel maps futex calls to its own waitqueues, semaphores, and atomic
ops.

However, it is probably easier to use the host's, than to write the
equivalent (basically duplicating the kernel's futex code in qemu, the
hashed locks and wait queues etc.).

On the other hand, using the host's makes it hard to run Linux guest
binaries on non-Linux hosts (those which don't have futex), or newer
Linux guest binaries on older Linux hosts which have fewer futex ops,
or none at all.

-- Jamie


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] Qemu Virual Machine Image

[I_am alone]

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 
would be really helpful for me to learn about the Images and Guest Os to Hos Os 
IO mechanisms...

Thanks in Advance



 
-
Have a burning question? Go to Yahoo! Answers and get answers from real people 
who know.___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel