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
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
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_
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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-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
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
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
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
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
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/
+#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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
50 matches
Mail list logo
