Re: [Qemu-devel] Significant performance regression in qemu-system-mips.

2010-04-02 Thread Rob Landley
On Thursday 01 April 2010 18:42:27 Alexander Graf wrote: > On 01.04.2010, at 15:49, Andreas Färber wrote: > > Am 26.03.2010 um 03:44 schrieb Rob Landley: > >> According to "qemu-system-ppc -M ?", g3beige is still the default. The > >> mac99 machine is the default for ppc64. (Are there newworlds t

Re: [Qemu-devel] Significant performance regression in qemu-system-mips.

2010-04-02 Thread Rob Landley
On Thursday 01 April 2010 16:33:09 Aurelien Jarno wrote: > On Wed, Mar 24, 2010 at 03:34:00PM -0500, Rob Landley wrote: > > Reverting that patch fixed it (git show HEAD | patch -R -p1), by which I > > mean three consecutive runs with 30 second timeout didn't trigger the > > hang detection. > > I ha

[Qemu-devel] [PATCH] target-mips: Fix one more format specifier for cpu_fprintf

2010-04-02 Thread Stefan Weil
env->bcond must be printed using TARGET_FMT_ld. Signed-off-by: Stefan Weil --- target-mips/translate.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/target-mips/translate.c b/target-mips/translate.c index 61f8d72..bdd1884 100644 --- a/target-mips/translate.c +++ b/t

[Qemu-devel] Re: 452efb didn't show up in the list

2010-04-02 Thread Artyom Tarasenko
2010/4/2 Blue Swirl : > On 4/1/10, Artyom Tarasenko wrote: >> 2010/4/1 Blue Swirl : >>  > Which list? >> >>  This mailing list? >> >> >>  > On 4/1/10, Artyom Tarasenko wrote: >>  >> and looks wrong or incomplete to me: >>  >> >>  >>  >According to Sun4M System Architecture Manual chapter 5.3.2, a

[Qemu-devel] Re: [PATCH] provide a stub version of kvm-all.c if !CONFIG_KVM

2010-04-02 Thread Blue Swirl
On 4/2/10, Paolo Bonzini wrote: > On 04/02/2010 08:17 PM, Blue Swirl wrote: > > > I merged your patch and mine. Does it still look reasonable? > > > > Yes, of course. I'd rather see them committed separately though. This version is designed to be applied after your patch. I made my patch a bit

[Qemu-devel] Re: [PATCH] provide a stub version of kvm-all.c if !CONFIG_KVM

2010-04-02 Thread Paolo Bonzini
On 04/02/2010 08:17 PM, Blue Swirl wrote: I merged your patch and mine. Does it still look reasonable? Yes, of course. I'd rather see them committed separately though. Paolo

[Qemu-devel] Re: [PATCH] provide a stub version of kvm-all.c if !CONFIG_KVM

2010-04-02 Thread Blue Swirl
On 4/2/10, Paolo Bonzini wrote: > On 04/02/2010 07:29 PM, Blue Swirl wrote: > > > Could you stub also kvm_init? > > > > It is stubbed, but it returns ENOSYS: > > +int kvm_init(int smp_cpus) > +{ > +return -ENOSYS; > +} > + Sorry, I expected this to be near the end. > and in fact

Re: [Qemu-devel] [PATCH] provide opaque CPUState to files that are compiled once

2010-04-02 Thread Anthony Liguori
On 04/02/2010 12:46 PM, Paolo Bonzini wrote: On 04/02/2010 07:36 PM, Anthony Liguori wrote: On 04/02/2010 11:43 AM, Paolo Bonzini wrote: On 04/02/2010 06:24 PM, Anthony Liguori wrote: I'd rather things be compiled per-target than adding a bunch of crud everywhere. Well, this patch in partic

Re: [Qemu-devel] [PATCH] provide opaque CPUState to files that are compiled once

2010-04-02 Thread Paolo Bonzini
On 04/02/2010 07:36 PM, Anthony Liguori wrote: On 04/02/2010 11:43 AM, Paolo Bonzini wrote: On 04/02/2010 06:24 PM, Anthony Liguori wrote: I'd rather things be compiled per-target than adding a bunch of crud everywhere. Well, this patch in particular removes more lines than it adds. :-P Any

Re: [Qemu-devel] [PATCH] provide opaque CPUState to files that are compiled once

2010-04-02 Thread Anthony Liguori
On 04/02/2010 11:43 AM, Paolo Bonzini wrote: On 04/02/2010 06:24 PM, Anthony Liguori wrote: I'd rather things be compiled per-target than adding a bunch of crud everywhere. Well, this patch in particular removes more lines than it adds. :-P Anyway---me too, given how hairy it's coming out.

[Qemu-devel] Re: [PATCH] provide a stub version of kvm-all.c if !CONFIG_KVM

2010-04-02 Thread Paolo Bonzini
On 04/02/2010 07:29 PM, Blue Swirl wrote: Could you stub also kvm_init? It is stubbed, but it returns ENOSYS: +int kvm_init(int smp_cpus) +{ +return -ENOSYS; +} + and in fact I'm relying this to remove this: if (!(kvm_available())) { printf("Option %s not supported for this ta

[Qemu-devel] Re: [PATCH] provide a stub version of kvm-all.c if !CONFIG_KVM

2010-04-02 Thread Blue Swirl
On 4/2/10, Paolo Bonzini wrote: > This allows limited use of kvm functions (which will return ENOSYS) > even in once-compiled modules. The patch also improves a bit the error > messages for KVM initialization. > > Signed-off-by: Paolo Bonzini > --- > What about this instead? I don't

[Qemu-devel] wrong behaviour of caps lock

2010-04-02 Thread Benjamin Drung
Hi, We applied the attached patch in Ubuntu to fix the wrong behavior of caps lock. Initial bug report: https://launchpad.net/bugs/427612 Testcase: Select German NEO 2 as keyboard layout and press "caps lock" + "l". Then a "-" should appear instead of a "t". -- Benjamin Drung Ubuntu Developer

Re: [Qemu-devel] [PATCH] provide opaque CPUState to files that are compiled once

2010-04-02 Thread Paolo Bonzini
On 04/02/2010 06:24 PM, Anthony Liguori wrote: I'd rather things be compiled per-target than adding a bunch of crud everywhere. Well, this patch in particular removes more lines than it adds. :-P Anyway---me too, given how hairy it's coming out. Maybe (or without maybe) this work should hav

[Qemu-devel] [PATCH] provide a stub version of kvm-all.c if !CONFIG_KVM

2010-04-02 Thread Paolo Bonzini
This allows limited use of kvm functions (which will return ENOSYS) even in once-compiled modules. The patch also improves a bit the error messages for KVM initialization. Signed-off-by: Paolo Bonzini --- What about this instead? I don't like that kvm-stub.c is compiled per-targ

[Qemu-devel] Re: [PATCH 2/2] Make kvm_enabled unavailable to non-target devices

2010-04-02 Thread Anthony Liguori
On 04/02/2010 11:47 AM, Paolo Bonzini wrote: +#pragma GCC poison kvm_allowed +#pragma GCC poison kvm_enabled kvm_enabled() is a macro. I dont' think this poison pragma is actually meaningful. I'm not familiar with poison pragmas, but actually poisoning only kvm_allowed didn't work. I

[Qemu-devel] Re: [PATCH 2/2] Make kvm_enabled unavailable to non-target devices

2010-04-02 Thread Paolo Bonzini
+#pragma GCC poison kvm_allowed +#pragma GCC poison kvm_enabled kvm_enabled() is a macro. I dont' think this poison pragma is actually meaningful. I'm not familiar with poison pragmas, but actually poisoning only kvm_allowed didn't work. Indeed, macro expansions are explicitly allowed t

Re: [Qemu-devel] [PATCH 2/2] Make kvm_enabled unavailable to non-target devices

2010-04-02 Thread Blue Swirl
On 4/2/10, Anthony Liguori wrote: > On 04/02/2010 10:46 AM, Blue Swirl wrote: > > > Signed-off-by: Blue Swirl > > --- > > hw/acpi.c | 10 +- > > hw/pc.h |2 +- > > hw/poison.h |3 +++ > > 3 files changed, 9 insertions(+), 6 deletions(-) > > > > diff --git a/hw/acpi.c b/hw/

Re: [Qemu-devel] [PATCH 2/2] Make kvm_enabled unavailable to non-target devices

2010-04-02 Thread Anthony Liguori
On 04/02/2010 10:46 AM, Blue Swirl wrote: Signed-off-by: Blue Swirl --- hw/acpi.c | 10 +- hw/pc.h |2 +- hw/poison.h |3 +++ 3 files changed, 9 insertions(+), 6 deletions(-) diff --git a/hw/acpi.c b/hw/acpi.c index 5c01c2e..7c2b109 100644 --- a/hw/acpi.c +++ b/hw/ac

Re: [Qemu-devel] [PATCH] provide opaque CPUState to files that are compiled once

2010-04-02 Thread Anthony Liguori
On 04/02/2010 10:43 AM, Paolo Bonzini wrote: On 04/02/2010 05:22 PM, Anthony Liguori wrote: hw/* should never access CPUState. Can you give examples of when qemu-kvm needs this? Indirectly via header files. The problem is that GCC poisoning complains on prototypes too. qemu-kvm.h referen

[Qemu-devel] Re: 452efb didn't show up in the list

2010-04-02 Thread Blue Swirl
On 4/1/10, Artyom Tarasenko wrote: > 2010/4/1 Blue Swirl : > > Which list? > > This mailing list? > > > > On 4/1/10, Artyom Tarasenko wrote: > >> and looks wrong or incomplete to me: > >> > >> >According to Sun4M System Architecture Manual chapter 5.3.2, a limit > >> >of 0 will not gener

Re: [Qemu-devel] [PATCH] provide opaque CPUState to files that are compiled once

2010-04-02 Thread Blue Swirl
On 4/2/10, Paolo Bonzini wrote: > > > > > > > qemu-kvm.h references CPUState and includes cpu.h, so with the latest > > > changes all files that include qemu-kvm.h break, even if they don't > require > > > qemu-kvm.h. With this patch they instead get the opaque definition via > > > hw/hw.h (whic

Re: [Qemu-devel] [PATCH] provide opaque CPUState to files that are compiled once

2010-04-02 Thread Paolo Bonzini
qemu-kvm.h references CPUState and includes cpu.h, so with the latest changes all files that include qemu-kvm.h break, even if they don't require qemu-kvm.h. With this patch they instead get the opaque definition via hw/hw.h (which includes cpu-common.h), and qemu-kvm.h can avoid including cp

Re: [Qemu-devel] [PATCH] provide opaque CPUState to files that are compiled once

2010-04-02 Thread Blue Swirl
On 4/2/10, Paolo Bonzini wrote: > On 04/02/2010 05:22 PM, Anthony Liguori wrote: > > > > hw/* should never access CPUState. > > > > Can you give examples of when qemu-kvm needs this? > > > > Indirectly via header files. The problem is that GCC poisoning complains > on prototypes too. > > qemu-k

[Qemu-devel] Re: [PATCH 1/2] Move KVM init to arch_init.c, compile vl.c once

2010-04-02 Thread Paolo Bonzini
On 04/02/2010 05:20 PM, Anthony Liguori wrote: I didn't do this to compile vl.c once. I don't care about that. I did this as an initial step towards having kvm functions stubbed out for !CONFIG_KVM, instead of relying on GCC performing dead-code-elimination on kvm_enabled(). I'd prefer a kvm

[Qemu-devel] [PATCH 2/2] Make kvm_enabled unavailable to non-target devices

2010-04-02 Thread Blue Swirl
Signed-off-by: Blue Swirl --- hw/acpi.c | 10 +- hw/pc.h |2 +- hw/poison.h |3 +++ 3 files changed, 9 insertions(+), 6 deletions(-) diff --git a/hw/acpi.c b/hw/acpi.c index 5c01c2e..7c2b109 100644 --- a/hw/acpi.c +++ b/hw/acpi.c @@ -51,7 +51,7 @@ typedef struct PIIX4PMSt

[Qemu-devel] [PATCH 1/2] Move KVM init to arch_init.c, compile vl.c once

2010-04-02 Thread Blue Swirl
Remove dependency of vl.c to KVM, then we can partially revert b33612d03540fda7fa67485f1c20395beb7a2bf0. Signed-off-by: Blue Swirl --- Makefile.objs |2 +- Makefile.target |2 +- arch_init.c |5 + arch_init.h |1 + kvm-all.c |3 +++ kvm.h |8

Re: [Qemu-devel] [PATCH] provide opaque CPUState to files that are compiled once

2010-04-02 Thread Paolo Bonzini
On 04/02/2010 05:22 PM, Anthony Liguori wrote: hw/* should never access CPUState. Can you give examples of when qemu-kvm needs this? Indirectly via header files. The problem is that GCC poisoning complains on prototypes too. qemu-kvm.h references CPUState and includes cpu.h, so with the l

[Qemu-devel] Re: [PATCH 1/2] Move KVM init to arch_init.c, compile vl.c once

2010-04-02 Thread Blue Swirl
On 4/2/10, Anthony Liguori wrote: > On 04/02/2010 10:01 AM, Paolo Bonzini wrote: > > > On 04/01/2010 10:27 PM, Blue Swirl wrote: > > > > > It will not be safe to use kvm_enabled() in vl.c, so there needs to be > > > a target dependent helper. The call to kvm_init could remain in vl.c, > > > likewi

Re: [Qemu-devel] [BREAKAGE] commit 9bc6304c156dcc01c619672ca33d7152bb18bcb9 breaks build

2010-04-02 Thread Anthony Liguori
On 04/02/2010 10:27 AM, Anthony Liguori wrote: This tap files are a bit odd. We don't compile tap.o for mingw32 but we do compile tap-win32.o so what we need to do is define tap_get_vhost_net in tap-win32.c. Testing a patch right now. I pushed a fix that does exactly this. Regards, Antho

Re: [Qemu-devel] [BREAKAGE] commit 9bc6304c156dcc01c619672ca33d7152bb18bcb9 breaks build

2010-04-02 Thread Anthony Liguori
On 04/02/2010 09:30 AM, Stefan Weil wrote: Blue Swirl schrieb: On 4/2/10, Roy Tam wrote: 2010/4/2 Anthony Liguori: Try doing a clean build This is a fresh checkout. I can confirm this with mingw32: LINK sparc64-softmmu/qemu-system-sparc64.exe virtio-net.

Re: [Qemu-devel] [PATCH] provide opaque CPUState to files that are compiled once

2010-04-02 Thread Anthony Liguori
On 04/02/2010 09:45 AM, Paolo Bonzini wrote: This patch allows to unpoison CPUState and env in once-compiled files. To achieve this, it defines an opaque struct CPUState in cpu-common.h. This also requires tweaking the relationship between CPUState and CPUXYZState in target files. Unpoisoning en

[Qemu-devel] Re: [PATCH 1/2] Move KVM init to arch_init.c, compile vl.c once

2010-04-02 Thread Anthony Liguori
On 04/02/2010 10:11 AM, Paolo Bonzini wrote: On 04/02/2010 05:08 PM, Anthony Liguori wrote: Having kvm-all.c compile with and without CONFIG_KVM is pretty ugly IMHO. Is compiling vl.c once really that important of a goal? I didn't do this to compile vl.c once. I don't care about that. I di

[Qemu-devel] Re: [PATCH 1/2] Move KVM init to arch_init.c, compile vl.c once

2010-04-02 Thread Paolo Bonzini
On 04/02/2010 05:08 PM, Anthony Liguori wrote: Having kvm-all.c compile with and without CONFIG_KVM is pretty ugly IMHO. Is compiling vl.c once really that important of a goal? I didn't do this to compile vl.c once. I don't care about that. I did this as an initial step towards having kvm fu

[Qemu-devel] Re: [PATCH 1/2] Move KVM init to arch_init.c, compile vl.c once

2010-04-02 Thread Anthony Liguori
On 04/02/2010 10:01 AM, Paolo Bonzini wrote: On 04/01/2010 10:27 PM, Blue Swirl wrote: It will not be safe to use kvm_enabled() in vl.c, so there needs to be a target dependent helper. The call to kvm_init could remain in vl.c, likewise it's not strictly needed to move kvm_allowed to arch_init.c

[Qemu-devel] Re: [PATCH 1/2] Move KVM init to arch_init.c, compile vl.c once

2010-04-02 Thread Paolo Bonzini
On 04/01/2010 10:27 PM, Blue Swirl wrote: It will not be safe to use kvm_enabled() in vl.c, so there needs to be a target dependent helper. The call to kvm_init could remain in vl.c, likewise it's not strictly needed to move kvm_allowed to arch_init.c. Not really, because kvm_allowed _can_ be u

[Qemu-devel] Re: [PATCHv6 03/11] notifier: event notifier implementation

2010-04-02 Thread Paolo Bonzini
On 03/17/2010 12:07 PM, Michael S. Tsirkin wrote: +{ +#ifdef CONFIG_EVENTFD +int fd = eventfd(!!active, EFD_NONBLOCK | EFD_CLOEXEC); +uint64_t value; +int r = read(e->fd,&value, sizeof(value)); +if (r == sizeof(value)) { +/* restore previous value. */ +int s = w

[Qemu-devel] [PATCH] provide opaque CPUState to files that are compiled once

2010-04-02 Thread Paolo Bonzini
This patch allows to unpoison CPUState and env in once-compiled files. To achieve this, it defines an opaque struct CPUState in cpu-common.h. This also requires tweaking the relationship between CPUState and CPUXYZState in target files. Unpoisoning env is needed because it is widely used as the na

Re: [Qemu-devel] [BREAKAGE] commit 9bc6304c156dcc01c619672ca33d7152bb18bcb9 breaks build

2010-04-02 Thread Stefan Weil
Blue Swirl schrieb: > On 4/2/10, Roy Tam wrote: >> 2010/4/2 Anthony Liguori : >> >>> Try doing a clean build >> >> This is a fresh checkout. > > I can confirm this with mingw32: > LINK sparc64-softmmu/qemu-system-sparc64.exe > virtio-net.o: In function `virtio_net_exit': > /src/qemu/hw/virtio-net.

[Qemu-devel] Re: [PATCH 1/2] Move KVM init to arch_init.c, compile vl.c once

2010-04-02 Thread Blue Swirl
On 4/1/10, Paolo Bonzini wrote: > On 04/01/2010 10:07 PM, Blue Swirl wrote: > > > Remove dependency of vl.c to KVM, then we can partially revert > > b33612d03540fda7fa67485f1c20395beb7a2bf0. > > > > This is ugly... > > Michael Tsirkin said in commit ca821806: > > Comment on kvm usage: rather t

Re: [Qemu-devel] [BREAKAGE] commit 9bc6304c156dcc01c619672ca33d7152bb18bcb9 breaks build

2010-04-02 Thread Blue Swirl
On 4/2/10, Roy Tam wrote: > 2010/4/2 Anthony Liguori : > > > Try doing a clean build > > > This is a fresh checkout. I can confirm this with mingw32: LINK sparc64-softmmu/qemu-system-sparc64.exe virtio-net.o: In function `virtio_net_exit': /src/qemu/hw/virtio-net.c:943: undefined reference to

Re: [Qemu-devel] [BREAKAGE] commit 9bc6304c156dcc01c619672ca33d7152bb18bcb9 breaks build

2010-04-02 Thread Roy Tam
2010/4/2 Anthony Liguori : > Try doing a clean build This is a fresh checkout. > > On Apr 2, 2010 4:43 AM, "Roy Tam" wrote: > > Config: > > Install prefixc:/Program Files/Qemu > BIOS directoryc:/Program Files/Qemu > binary directory c:/Program Files/Qemu > Source path /usr/home/Us

Re: [Qemu-devel] [BREAKAGE] commit 9bc6304c156dcc01c619672ca33d7152bb18bcb9 breaks build

2010-04-02 Thread Anthony Liguori
Try doing a clean build On Apr 2, 2010 4:43 AM, "Roy Tam" wrote: Config: Install prefixc:/Program Files/Qemu BIOS directoryc:/Program Files/Qemu binary directory c:/Program Files/Qemu Source path /usr/home/User/qemu C compilergcc Host C compiler gcc CFLAGS-O

Re: [Qemu-devel] [PATCHv2] usb-bus: fix no params

2010-04-02 Thread Aurelien Jarno
On Tue, Mar 30, 2010 at 09:33:24AM +0800, TeLeMan wrote: > After commit 702f3e0fb52c124c07f215426eeadb70a716643f, the params is > nerver NULL. It should check *params instead of params to determine > whether the params is empty. > > Signed-off-by: TeLeMan Thanks, applied. > --- > hw/usb-bus.c

Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG

2010-04-02 Thread Ian Molton
Jamie Lokier wrote: > I would hope that the host can rate limit itself without needing apps > to govern themselves, though. That depends on the source of the entropy - some sources can, some are fed to daemons that can, but not all systems have such daemons. :) -Ian

Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG

2010-04-02 Thread Ian Molton
Paul Brook wrote: This patch adds support for virtio-rng. Data is read from a chardev and can be either raw entropy or received via the EGD protocol. >>> I still don't get why you need this at all. It seems like >>> virtio-serial would already provides everything you need. >> I gue

Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG

2010-04-02 Thread Ian Molton
Paul Brook wrote: >>This patch adds support for virtio-rng. Data is read from a chardev >> and can be either raw entropy or received via the EGD protocol. > > I still don't get why you need this at all. It seems like virtio-serial would > already provides everything you need. Because we

[Qemu-devel] [BREAKAGE] commit 9bc6304c156dcc01c619672ca33d7152bb18bcb9 breaks build

2010-04-02 Thread Roy Tam
Config: Install prefixc:/Program Files/Qemu BIOS directoryc:/Program Files/Qemu binary directory c:/Program Files/Qemu Source path /usr/home/User/qemu C compilergcc Host C compiler gcc CFLAGS-O2 -g QEMU_CFLAGS -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_

[Qemu-devel] [PATCH] vnc: don't forget to call check_pointer_type_change in pointer_event() and set_encodings().

2010-04-02 Thread Yoshiaki Tamura
The following commit broke the behavior of vnc mouse. Forgetting to call check_pointer_type_change in pointer_event() and set_encodings() seems to be the reason. This patch fix this issue. commit 37c34d9d5d87ea9d51760310c8863b82cb8c055a Author: Anthony Liguori Date: Wed Mar 10 09:38:29 2010 -06

Re: [Qemu-devel] Significant performance regression in qemu-system-mips.

2010-04-02 Thread Aurelien Jarno
On Fri, Apr 02, 2010 at 01:42:27AM +0200, Alexander Graf wrote: > > On 01.04.2010, at 15:49, Andreas Färber wrote: > > > > > Am 26.03.2010 um 03:44 schrieb Rob Landley: > > > >> According to "qemu-system-ppc -M ?", g3beige is still the default. The > >> mac99 > >> machine is the default for p