Re: [Qemu-devel] [PATCH] ARM - Remove fixed map code buffer restriction

2011-12-12 Thread David Gilbert
On 12 December 2011 18:10, andrzej zaborowski balr...@gmail.com wrote:
 On 12 December 2011 19:03, Peter Maydell peter.mayd...@linaro.org wrote:
 On 12 December 2011 17:24, andrzej zaborowski balr...@gmail.com wrote:
 BTW: I think we can also use the ld branch when we see the goto
 target is in Thumb mode.

 The target of a goto is currently never Thumb (because gotos are
 always to other TCG generated code and we only generate ARM insns).

 I'm aware of that, I just like functions that can do what their name
 says well. :)

It does have an assert which will catch it if you try, so no one
should get caught out
by it, and on ARMv7 the add is apparently an interworking branch, so I
think it might
even work.

Dave



Re: [Qemu-devel] [ICON] QEMU Mascot Contest v.2

2011-11-11 Thread David Gilbert
Yes, the Q with the emu head looks nice - I kind of think the middle
of the Q starts to look nicely like an egg; but perhaps that's
just me.

Dave



Re: [Qemu-devel] [PATCH 2/5] linux-user: add open() hijack infrastructure

2011-11-03 Thread David Gilbert
On 2 November 2011 19:23, Alexander Graf ag...@suse.de wrote:
 There are a number of files in /proc that expose host information
 to the guest program. This patch adds infrastructure to override
 the open() syscall for guest programs to enable us to on the fly
 generate guest sensible files.

 Signed-off-by: Alexander Graf ag...@suse.de
 ---
  linux-user/syscall.c |   52 +++--
  1 files changed, 49 insertions(+), 3 deletions(-)

 diff --git a/linux-user/syscall.c b/linux-user/syscall.c
 index 9f5da36..38953ba 100644
 --- a/linux-user/syscall.c
 +++ b/linux-user/syscall.c
 @@ -4600,6 +4600,52 @@ int get_osversion(void)
     return osversion;
  }

 +static int do_open(void *cpu_env, const char *pathname, int flags, mode_t 
 mode)

Once you open the pandoras-box that is emulating /proc, I think you'll probably
need to hook it in more places and be more general; although you may
well get away
with it for this particular case.

Isn't it better to put the filename interception code somewhere more general
so that it can also be misused by other calls - e.g. stat().

I guess you're also going to need to be able to do /proc/pid/* instead
of /proc/self;
something is bound to use that.

Dave



Re: [Qemu-devel] [PATCH] Make cpu_single_env thread local (Linux only for now)

2011-10-07 Thread David Gilbert
On 5 October 2011 10:21, Paolo Bonzini pbonz...@redhat.com wrote:


 If interested people can test the patches more and submit them more
 formally, I'd be very glad.  I wrote it for RCU, but of course that one is
 not really going to be 1.0 material (even for 9p).

Hmm this got a bit more complex than the original patch; still it covers a lot
more bases.

Should this also replace the THREAD that's defined in
linux-user/qemu.h and bsd-user/qemu.h (that is __thread if built with
NPTL)?
It seems to only be there for 'thread_env' which is also a CPUState*
(hmm - what state does that contain that cpu_single_env doesn't?)

Dave



Re: [Qemu-devel] How to run realview-pbx-a9 image in qemu

2011-09-27 Thread David Gilbert
On 27 September 2011 14:01, loody milo...@gmail.com wrote:
 hi:


snip

 Would you mind to let me know which configs you use to compile for a9
 running on qemu?

Kernel configs?  I mostly use prebuilt kernels from the Linaro images.

Dave



Re: [Qemu-devel] [PATCH 0/8] tcg/interpreter: Add TCG + interpreter for bytecode (virtual machine)

2011-09-19 Thread David Gilbert
On 18 September 2011 16:13, Stefan Weil w...@mail.berlios.de wrote:
 Am 18.09.2011 17:02, schrieb Mulyadi Santosa:

 Hi :)

 On Sun, Sep 18, 2011 at 02:59, Stefan Weil w...@mail.berlios.de wrote:

 Hello,

 these patches add a new code generator (TCG target) to qemu.

 I personally congrats you for your hard work. So, here's a question
 from who are not so keen with Qemu internals: what is the biggest
 advantage of using TCI instead of directly using TCG?

 TCG with native code support is much faster (6x to 10x),
 so for emulation on a supported host, TCI has no advantage
 for normal users.

Is it possible to dynamically switch between the two?

The two cases I'm thinking of are:
  1) Using the interpreter to execute one or two instructions in an exception
handling case
  2) Avoiding TCG code generation on the first few runs of a piece of
code that might only be init code, and only bothering with TCG for hotter
code.

Dave



Re: [Qemu-devel] [PATCH 0/8] tcg/interpreter: Add TCG + interpreter for bytecode (virtual machine)

2011-09-19 Thread David Gilbert
On 19 September 2011 11:20, Stefan Hajnoczi stefa...@gmail.com wrote:
 On Mon, Sep 19, 2011 at 9:40 AM, David Gilbert david.gilb...@linaro.org 
 wrote:

snip

 Is it possible to dynamically switch between the two?

 The two cases I'm thinking of are:
  1) Using the interpreter to execute one or two instructions in an exception
 handling case
  2) Avoiding TCG code generation on the first few runs of a piece of
 code that might only be init code, and only bothering with TCG for hotter
 code.

 The tricky thing with using the interpeter for lesser run code is that
 it has a bunch of machinery in front of it which probably makes it
 relatively similar to actually emitting native code.  The interesting
 benchmark would be to translate blocks but never cache them for future
 executions - compare this with TCI to see how much difference there is
 between executing with interpretation vs translation.  If the
 interpreter is almost as expensive as the translator then it's not
 worth it.

Right; the trick is if you have a passably fast interpreter you can afford
to do some more expensive optimisations in the code generator which would
be interesting.  It's not unusual to find an awful lot of executed once-or-twice
code.

Dave



Re: [Qemu-devel] emulated ARM performance vs real processor ?

2011-09-02 Thread David Gilbert
On 1 September 2011 08:32, Julien Heyman bidsom...@gmail.com wrote:
 Hi,

 I was wondering if anyone had some data regarding the relative performance
 of any given ARM board emulated in QEMU versus the real thing. Yes, I do
 know this depends a lot on the host PC running qemu, but some
 ballpark/example figures would help. Say, I emulate a 400 Mhz ARM9 processor
 on a Core2Duo laptop @ 2 Ghz, what kind of performance/timing ratio should I
 expect, one way or the other ? For example, for boot time.
 I have no idea whether the overhead of emulation is over-compensated by the
 huge processing power of the host compared to the real HW target, and by
 which factor.

Comparing performance is always a bit tricky, and I've not really got
a solid set of benchmarks
ready to run to try it but to give some numbers:

1) Boot times
   Comparing the Linaro 11.08 ubuntu desktop images, time to boot to desktop

   Real Panda board (dual core A9 at 1GHz, 1GB RAM, running off SD
card) - 2minutes to desktop
   QEMU vexpress (2xA9 core, 1GB RAM, emulated sd card, running on a
Core2 Duo T9400 2.53GHz laptop) - 3minutes to desktop

   (The times are scarily close to exact minutes - timeout somewhere?)
   Now, QEMU system mode only ever uses one host core when emulating
multiple cores, so there is a factor 2 disadvantage there, but
on the plus side the memory bandwidth of the host and the disk speed
is probably much higher than the Panda.

2) Simple md5sum benchmark
   As a really simple benchmark the test:

time (dd if=/dev/zero bs=1024k count=1000 | md5sum)

Panda board 14.5s real, 10.7 user, 3.8s system
Emulated Overo board (single A8 processor on same laptop as above)
- 41s real, 24.7s user, 16.4s system
User mode emulated - 14.2s real, 14s user, 0.5s system
Native on x86 host - 3.2s real, 2.5s user, 1.2s system

So, that's two sets of pretty bogus dummy simple benchmarks!

I suppose one observation is that the boot time isn't that bad
compared to the real (different) hardware, the user mode emulation
was comparable to the Panda, but the system emulation on a simple test
seems a lot slower.

These things will vary wildly depending what your benchmark is; but as
a summary I'd say that the ARM system mode emulation is
fast enough to use interactively but CPU wise is noticeably slower
than user mode emulation.

Dave



Re: [Qemu-devel] emulated ARM performance vs real processor ?

2011-09-02 Thread David Gilbert
On 2 September 2011 17:04, Julien Heyman bidsom...@gmail.com wrote:
 Thanks Dave.
 I use system emulation, and my main concern is just to know that the
 actual board will run faster than the emulation. So based on your example,
 and even though my target board (mini2440) is nowhere as fast as a Panda
 board, this should be the case by a comfortable margin.

OK, but be careful - you will occasionally trip over something where the
emulation of it is particularly dire and the real board might be faster;
for example with the default flags SD card writes can be a factor of 10 slower
than real hardware, so relying on the real hardware always being faster
is dangerous. You'll probably get similar CPU emulation artefacts where
there are some instructions that are particularly nasty to emulate but
really cheap on the hardware.

Dave



Re: [Qemu-devel] [PATCH] tcg: Reload local variables after return from longjmp

2011-08-11 Thread David Gilbert
On 11 August 2011 15:10, Paolo Bonzini pbonz...@redhat.com wrote:

 I'm not sure about what to read from there:

 If I make cpu_single_env thread local with __thread and leave
 0d101... in, then again it works reliably on 32bit Lucid, and is
 flaky on 64 bit Oneiric (5/10 2 hangs, 3 segs)

 I've also tried using a volatile local variable in cpu_exec to hold
 a copy of env and restore that rather than cpu_single_env. With this
 it's solid on 32bit lucid and flaky on 64bit Oneirc; these failures
 on 64bit OO look like it running off the end of the code buffer (all
 0 code), jumping to non-existent code addresses and a seg in
 tb_reset_jump_recursive2.

 It looks like neither a thread-local cpu_single_env nor a volatile copy fix
 the bug?!?

As I say at the bottom of that bug I'm assuming I'm hitting multiple bugs.
Although it's not clear to me why I don't hit them on 32bit lucid.

Dave



[Qemu-devel] Multithreaded ARM regression from 0d101938

2011-08-10 Thread David Gilbert
Hi,
  I've just filed bug 823902 ( https://bugs.launchpad.net/qemu/+bug/823902 )
which is a mutlthreaded user mode ARM crash that goes away if I revert
0d101938 ( tcg: Reload local variables after return from longjmp ).

It's actually a bit more complicated than that, in that:
   1) It fails reliably on 32bit Lucid with that commit
   2) It works reliably on 32bit Lucid without that commit
   3) It fails reliably on 64bit Oneiric or Natty with that commit
   4) It works mostly on 64bit Oneiric without that commit.

(By mostly I'm talking in run it 10 times and it fails a couple)

Peter Maydell has suggested a few things; and we've tried using a local
volatile copy of env in cpu_exec which seems to work fine on 32bit Lucid
and helps a bit on 64bit Oneiric but has a much higher failure rate than
just reverting 823902 - which is all a bit confusing.

My guess is I'm seeing multiple bugs but haven't quite nailed why/how.

Dave



[Qemu-devel] Defaulting SD_OPTS to cache=writeback

2011-07-27 Thread David Gilbert
Hi,
  Write performance on the SD emulation on ARM is rather painful with
the default empty SD_OPTS; it's
getting something like 130KB/s on the vexpress model  With
cache=writeback this goes up to a sensible
8MB/s. (This is with the file on an LUKS encrypted lvm partition that
is my home directory on an Ubuntu Lucid
install on my core 2 laptop).

The impact is probably so bad because most of the writes are done
using the SD card's native 512byte block size
which turns into a read/modify/write.

Is it reasonable to set SD_OPTS to cache=writeback ?  If people want
other options they can always use -drive,
but having the default give 130KB/s is nasty.

Dave



Re: [Qemu-devel] How to run realview-pbx-a9 image in qemu

2011-07-12 Thread David Gilbert
On 12 July 2011 07:04, Xiao Jiang jgq...@gmail.com wrote:
 It looks like I am not in luck, qemu still can't run successfully.
 I recompiled the qemu from linaro qemu tree and executed below
 instructions in order.

 1. open window A, run below cmd.
 xjiang@xjiang-desktop:~/work/qemu$ sudo qemu-system-arm -M realview-pbx-a9
 -m 1024 -kernel zImage-cortex-a9 -serial telnet::,server -append

I think you have a bad kernel image.
There are some prebuilt ones (and config files) linked off:

http://www.arm.com/community/software-enablement/linux.php

but unfortunately the webserver that holds them isn't happy today.

Dave



Re: [Qemu-devel] How to run realview-pbx-a9 image in qemu

2011-07-11 Thread David Gilbert
On 11 July 2011 09:21, Xiao Jiang jgq...@gmail.com wrote:
 Hello,

 I downloaded latest qemu 0.14.1, it should support realview-pbx-a9 board now
 from
 below cmd.
 $ qemu-system-arm -M ?|grep Cortex-A9
 realview-pbx-a9 ARM RealView Platform Baseboard Explore for Cortex-A9

 Then I compiled a zImage from latest mainline with use
 realview-smp_defconfig as config
 file, but unfortunately qemu can't run with the image, I had tried the below
 instructions.
 1. qemu-system-arm -M realview-pbx-a9 -kernel zImage -initrd initrd.img
 -nographic -append console=ttyAMA0
 2. qemu-system-arm -M realview-pbx-a9 -m 1024M -kernel zImage -nographic
 -append root=/dev/nfs nfsroot=128.225.160.22:/home/work/rootfs rw
 console=ttyAMA0 rdinit=/sbin/init -net nic -net tap,ifname=tap0,script=no
 Both instructions can't work, console is hang and no informations is
 appeared.
 so I am wondering if there are something wrong about the kernel, am I choose
 the wrong
 config file for realview-pbx-a9 board? Or the native mainline kernel can't
 boot on
 qemu? Any suggestions? Thanks a lot!

The command I use is:

sudo ./arm-softmmu/qemu-system-arm -M realview-pbx-a9 -m 1024 -kernel
thekernel -serial telnet::,server -append console=earlycon
console=ttyS0 console=ttyAMA0 earlyprintk root=/dev/nfs
nfsroot=10.1.1.1:/armroot rw
ip=10.1.1.2:10.1.1.1:10.1.1.1:255.255.255.0:armqemu nfsrootdebug 
-net nic -net tap,ifname=tap0,script=no,downscript=no

and then telnet to port  to get the console.

(I'm using the linaro qemu tree).

Dave