Hi,
>>> +#ifndef QXL_HAS_IO_MONITORS_CONFIG_ASYNC
>>> +#define QXL_HAS_IO_MONITORS_CONFIG_ASYNC 0
>>
>> Just delete this and use defined(QXL_HAS_IO_MONITORS_CONFIG_ASYNC).
>
> So you are telling me to undo a change that Gerd asked for - could you
> please at least debate about the merits of bot
Rename 'string' to 'keys', rename 'hold_time' to 'hold-time'.
Signed-off-by: Amos Kong
---
hmp-commands.hx |2 +-
monitor.c | 14 +++---
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/hmp-commands.hx b/hmp-commands.hx
index 6a70a9c..bd0c6c9 100644
--- a/hmp-co
Convert 'sendkey' to use QAPI.
QAPI passes key's index of mapping table to qmp_send_key(),
not keycode. So we use help functions to convert key/code to
index of key_defs, and 'index' will be converted to 'keycode'
inside qmp_send_key().
For qmp, QAPI would check invalid key and raise error.
For h
Currently, if we define an 'enum' and use it in one command's
data, list struct for enum could not be generated, but it's
used in qmp function.
For example: KeyCodesList could not be generated.
>>> qapi-schema.json:
{ 'enum': 'KeyCodes',
'data': [ 'shift', 'alt' ... ] }
{ 'command': 'sendkey',
There are many maps of keycode 0x56 in pc-bios/keymaps/*
pc-bios/keymaps/common:less 0x56
pc-bios/keymaps/common:greater 0x56 shift
pc-bios/keymaps/common:bar 0x56 altgr
pc-bios/keymaps/common:brokenbar 0x56 shift altgr
This patch just renamed '<' to 'less', QAPI might add new
variable by
(qemu) sendkey a
(qemu) sendkey 0x1e
(qemu) sendkey #0x1e
unknown key: '#0x1e'
The last command doesn't work, '#' is not requested before
raw values, and the raw value in decimal format is not supported.
Signed-off-by: Amos Kong
---
hmp-commands.hx |6 +++---
1 files changed, 3 insertions(
Am 20.08.2012 01:39, schrieb Igor Mammedov:
this is th 3rd approach to make CPU a child of DeviceState
for both kinds of targets *-user and *-softmmu. It seems
with current state of qemu it doesn't take too much effort
to make it compile. Please check if it doesn't break
something on other target
This series converted 'sendkey' command to qapi. The raw value
in hexadecimal format is not supported by 'send-key' of qmp.
Amos Kong (6):
fix doc of using raw values with sendkey
monitor: rename keyname '<' to 'less'
hmp: rename arguments
qapi: generate list struct and visit_list for enum
key_defs[] in monitor.c is a mapping table of keys and keycodes,
this patch added a QKeyCode enum and a new key_defs table,
key's index in the enmu is same as keycode's index in new key_defs[].
And added two help functions to convert key/code to index of mapping
table, those functions will return
This allows using qemu_irq in the target specific cpu.h.
Signed-off-by: Stefan Weil
---
qemu-common.h |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/qemu-common.h b/qemu-common.h
index 74a99d3..88a515e 100644
--- a/qemu-common.h
+++ b/qemu-common.h
@@ -19,6 +19,8 @@ s
Am 20.08.2012 01:39, schrieb Igor Mammedov:
it's necessary for making CPU child of DEVICE without
causing circular header deps.
Signed-off-by: Igor Mammedov
---
hw/arm-misc.h |1 +
hw/bt.h |2 ++
hw/devices.h |2 ++
hw/irq.h |2 ++
hw/omap.h |1 +
hw/s
On Tue, Aug 14, 2012 at 6:46 PM, Peter Maydell wrote:
> On 14 August 2012 09:27, Juan Quintela wrote:
>> "Peter A. G. Crosthwaite" wrote:
>>> Hi All. PMM raised a query on a recent series of mine (the SSI series) about
>>> handling VMSD for devices which define state at multiple levels of the QO
On Tue, Aug 14, 2012 at 10:50 PM, Anthony Liguori wrote:
> "Peter A. G. Crosthwaite" writes:
>
>> Hi All. A couple of times now ive had debug issues due to silent failure of
>> object_property_set. This function silently fails if the requested property
>> does not exist for the target object. To
Hi Guys,
I was just doing some testing and decided to run Free-DOS under qemu-kvm
1.1.1 under kernel 3.0.1 (I know it's old).
I downloaded the floppy disk image (1.44M) from the Qemu Testing page
here: http://wiki.qemu.org/Testing
Then I ran:
qemu-kvm -fda odin1440.img
Just press enter on
From: Anthony Liguori
Header file dependency is a frickin' nightmare right now. cpu.h tends to get
included in our 'include everything' header files but qdev also needs to include
those headers mainly for qdev-properties since it knows about CharDriverState
and friends.
We can solve this for no
needed to prevent build breakage when CPU becomes a child of DeviceState
Signed-off-by: Igor Mammedov
---
scripts/qapi-types.py |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/scripts/qapi-types.py b/scripts/qapi-types.py
index cf601ae..f34addb 100644
--- a/scripts/qapi
Signed-off-by: Igor Mammedov
---
include/qemu/cpu.h |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/qemu/cpu.h b/include/qemu/cpu.h
index ad706a6..ac44057 100644
--- a/include/qemu/cpu.h
+++ b/include/qemu/cpu.h
@@ -20,7 +20,7 @@
#ifndef QEMU_CPU_H
#define
Signed-off-by: Igor Mammedov
---
error.h |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/error.h b/error.h
index 96fc203..643a372 100644
--- a/error.h
+++ b/error.h
@@ -14,7 +14,6 @@
#include "compiler.h"
#include "qapi-types.h"
-#include
/**
* A class represent
this is th 3rd approach to make CPU a child of DeviceState
for both kinds of targets *-user and *-softmmu. It seems
with current state of qemu it doesn't take too much effort
to make it compile. Please check if it doesn't break
something on other targets/archs/hosts than i386.
what's tested:
- c
it's necessary for making CPU child of DEVICE without
causing circular header deps.
Signed-off-by: Igor Mammedov
---
hw/arm-misc.h |1 +
hw/bt.h |2 ++
hw/devices.h |2 ++
hw/irq.h |2 ++
hw/omap.h |1 +
hw/soc_dma.h |1 +
hw/xen.h |1 +
qemu-com
didi2@linux:~> strace -f qemu testclonenonptl
execve("/usr/local/bin/qemu", ["qemu", "testclonenonptl"], [/* 67 vars */]) = 0
uname({sys="Linux", node="linux", ...}) = 0
brk(0) = 0x80463540
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
Thanks for doing this testing but I'm afraid it really isn't giving us
any new information. We already know clone is broken for i386 targets;
see my comment #9 in this bug.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.
Yeeaah,
the first version of qemu-0.4.1 is the ONLY version of Qemu,
that runs the testclone programm without any error.
This is nice, because the structure of calling clone() in syscall.c is today
the same as in 0.4.1.
This means, the error can be fixed,
Dietmar
--
You received this bug notifi
Hi,
here are the next steps what I am doing. I get the oldest qemu-0.41 version,
that I can get,
from June 2003:-).
Very interesting, the syscall.c today in Qemu 1.2.0 is build exact like that
from 2003.
And the testclone.c programm comes together with Qemu 0.41 and compiled also.
So, not so diff
On Wed, Aug 15, 2012 at 01:12:20PM +0200, Markus Armbruster wrote:
> pc_cmos_init() always claims 640KiB base memory, and ram_size - 1MiB
> extended memory. The latter can underflow to "lots of extended
> memory". Fix both, and clean up some.
>
> Note: SeaBIOS currently requires 1MiB of RAM, and
On Mon, Aug 13, 2012 at 04:56:53PM +0300, Avi Kivity wrote:
> IMO we need to fix CMOS reporting.
>
> (technically we shouldn't touch CMOS NVRAM at all; seabios should
> discover memory size via fwcfg and program it itself. But it's
> pointless to change it now)
It would be nice to pass all value
Am 19.08.2012 15:11, schrieb Paolo Bonzini:
No problem, my fault---I'm just back and I haven't really started again
all my stuff, so the patch was not tested.
This should fix it, though.
Booting works fine now. But the VM starts to hang after trying to unmap
large regions. No segfault or so j
On Sun, Aug 19, 2012 at 04:34:50PM +0100, Michael Brown wrote:
> On Sunday 19 Aug 2012 16:07:05 Avi Kivity wrote:
> > (and that seabios needs changes to either work in
> > big real mode, or to put the processor back into big real mode after
> > returning from a PMM service.
>
> If seabios switches
On 08/19/2012 06:44 PM, Kevin O'Connor wrote:
> On Sun, Aug 19, 2012 at 06:07:05PM +0300, Avi Kivity wrote:
>> ipxe contains the following snippet:
>>
>> /* Copy ROM to image source PMM block */
>> pushw %es
>> xorw%ax, %ax
>> movw%ax, %es
>> movl%esi, %edi
>
On Sun, Aug 19, 2012 at 06:07:05PM +0300, Avi Kivity wrote:
> ipxe contains the following snippet:
>
> /* Copy ROM to image source PMM block */
> pushw %es
> xorw%ax, %ax
> movw%ax, %es
> movl%esi, %edi
> xorl%esi, %esi
> movzbl romheade
On 08/19/2012 06:34 PM, Michael Brown wrote:
> On Sunday 19 Aug 2012 16:07:05 Avi Kivity wrote:
>> Which is exactly what happens here. My understanding of big real mode is
>> that to achieve a segment limit != 0x, you must go into 32-bit
>> protected mode, load a segment with a larger limit, a
On Sunday 19 Aug 2012 16:07:05 Avi Kivity wrote:
> Which is exactly what happens here. My understanding of big real mode is
> that to achieve a segment limit != 0x, you must go into 32-bit
> protected mode, load a segment with a larger limit, and return into real
> mode without touching the se
ipxe contains the following snippet:
/* Copy ROM to image source PMM block */
pushw %es
xorw%ax, %ax
movw%ax, %es
movl%esi, %edi
xorl%esi, %esi
movzbl romheader_size, %ecx
shll$9, %ecx
addr32 rep movsb
On 08/17/2012 03:36 PM, Richard Davies wrote:
> Hi Avi,
>
> Thanks to you and several others for offering help. We will work with Avi at
> first, but are grateful for all the other offers of help. We have a number
> of other qemu-related projects which we'd be interested in getting done, and
> wil
Am 17.08.2012 20:24, schrieb Jim Meyering:
> From: Jim Meyering
>
> Without this, envlist_to_environ may silently fail to copy all
> strings into the destination buffer, and both callers would leak
> any env strings allocated after a failing strdup, because the
> freeing code stops at the first N
Am 17.08.2012 20:24, schrieb Jim Meyering:
> From: Jim Meyering
>
> Convert each TAB(width-4) to equivalent spaces.
> Put braces around each one-line if-body.
>
> Signed-off-by: Jim Meyering
Reviewed-by: Andreas Färber
Thanks,
Andreas
P.S. CC'ing linux-user folks.
--
SUSE LINUX Products G
Il 19/08/2012 09:55, Stefan Priebe ha scritto:
> Hi Paolo,
>
> Am 18.08.2012 23:49, schrieb Paolo Bonzini:
>> Hi Stefan,
>>
>> this is my version of your patch. I think the flow of the code is a
>> bit simpler (or at least matches other implementations of cancellation).
>> Can you test it on your
On Sun, Aug 19, 2012 at 12:03 PM, Peter Maydell
wrote:
> On 19 August 2012 12:23, Peter Maydell wrote:
>> Ideally, yes, but qemu is full of devices that haven't yet made the leap
>> to QOM.
>>
>> omap1 is particularly tricky because I don't actually have any test images
>> for it, so refactoring
On Sun, Aug 19, 2012 at 10:59 AM, Brendan Fennell wrote:
>
> Signed-off-by: Brendan Fennell
> ---
> hw/pl190.c |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/hw/pl190.c b/hw/pl190.c
> index cb50afb..eddb531 100644
> --- a/hw/pl190.c
> +++ b/hw/pl190.c
> @@ -120,7
On Sat, Aug 18, 2012 at 9:56 PM, Dmitry V. Levin wrote:
> In case when TARGET_ABI_BITS == 32 && HOST_LONG_BITS == 64, the last
> byte of the target dirent structure (aka d_type byte) was never copied
> from the host dirent structure, thus breaking everything that relies
> on valid d_type value, e.
On 19 August 2012 12:23, Peter Maydell wrote:
> Ideally, yes, but qemu is full of devices that haven't yet made the leap
> to QOM.
>
> omap1 is particularly tricky because I don't actually have any test images
> for it, so refactoring it is a leap in the dark. [I've tried asking on this
> list
>
On 08/19/2012 02:23 PM, Peter Maydell wrote:
> On 19 August 2012 11:12, Avi Kivity wrote:
>> On 08/17/2012 10:41 AM, liu ping fan wrote:
>>> And something like omap_mpu_timer_init() in file hw/omap1.c , the
>>> opaque(omap_mpu_timer_s) is got from g_malloc0, which makes things
>>> even harder to h
On 19 August 2012 11:12, Avi Kivity wrote:
> On 08/17/2012 10:41 AM, liu ping fan wrote:
>> And something like omap_mpu_timer_init() in file hw/omap1.c , the
>> opaque(omap_mpu_timer_s) is got from g_malloc0, which makes things
>> even harder to handle. And the DO_CAST can not work for such issue
Signed-off-by: Brendan Fennell
---
hw/pl190.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/hw/pl190.c b/hw/pl190.c
index cb50afb..eddb531 100644
--- a/hw/pl190.c
+++ b/hw/pl190.c
@@ -120,7 +120,8 @@ static uint64_t pl190_read(void *opaque, target_phys_addr_t
offset
On 18 August 2012 22:01, Stefan Weil wrote:
> valgrind reports a lot more memory leaks which are related to
> function qemu_allocate_irqs. In many cases, its return value
> should be free'd. g_malloc / g_free can be avoided by adding
> a new function
>
> void qemu_init_irqs(qemu_irq_handler handle
Il 19/08/2012 01:44, ronnie sahlberg ha scritto:
> format=raw works !
>
> That then begs the question if would it be possible to force
> format=raw always for iscsi devices?
>
> A iscsi device as far as I can see would always just be a raw block
> device and there would never be a "header" on suc
Hi,
I just compiled the testclone.c with Suse Linux 9.0.
It has a Kernel 2.4.21, so never heard anything in its life about NPTL.
On this 2.4.21 Linux, the testclone program with direct calling of clone()
works.
Then I make a try with this testclone on Raspberry Pi and qemu-i386 with
-strace.
The
On 08/18/12 23:06, Michael Tokarev wrote:
> On 19.08.2012 00:51, Stefan Weil wrote:
>
>> +++ b/qapi/opts-visitor.c
>> @@ -416,7 +416,7 @@ opts_visitor_cleanup(OptsVisitor *ov)
>
>> g_hash_table_destroy(ov->unprocessed_opts);
>> }
>> g_free(ov->fake_id_opt);
>> -memset(ov, '
On 08/17/2012 10:41 AM, liu ping fan wrote:
>> The same example, in setup_cmd646_bar(PCIIDEState *d, int bus_num), I
>> think we can not decide which is the type for @bar. If using
>> object_dynamic_cast(@bar, TYPE_OBJECT) to tell whether it is Object or
>> not, it will raise exception.
>>
> And
On 08/18/12 22:51, Stefan Weil wrote:
> valgrind report:
>
> ==24534== 232 bytes in 2 blocks are definitely lost in loss record 1,245 of
> 1,601
> ==24534==at 0x4824F20: malloc (vg_replace_malloc.c:236)
> ==24534==by 0x293C88: malloc_and_trace (vl.c:2281)
> ==24534==by 0x489AD99: ???
On 08/17/2012 05:52 AM, liu ping fan wrote:
>>
>> Why? Usually there's a 1:1 mapping between object and opaque. Can you
>> show cases where there isn't?
>>
> As mentioned ahead, setup_cmd646_bar(PCIIDEState *d, int bus_num),
> Object=@d, but opaque are
> d->cmd646_bar[bus_num], so that is 1:n map
On 08/17/2012 01:55 PM, Jan Kiszka wrote:
> On 2012-07-10 12:41, Jan Kiszka wrote:
>> On 2012-07-02 11:07, Avi Kivity wrote:
>>> On 06/29/2012 07:37 PM, Jan Kiszka wrote:
Instead of flushing pending coalesced MMIO requests on every vmexit,
this provides a mechanism to selectively flush wh
On 08/17/2012 06:04 PM, Jan Kiszka wrote:
>
>>> Can anyone imagine that such a barrier may actually be required? If it
>>> is currently possible that env->stop is evaluated before we called into
>>> sigtimedwait in qemu_kvm_eat_signals, then we could actually eat the
>>> signal without properly p
Avi Kivity wrote:
> Richard Davies wrote:
> > The host in question has 128GB RAM and dual AMD Opteron 6128 (16 cores
> > total). It is running kernel 3.5.1 and qemu-kvm 1.1.1.
> >
> > In this morning's test, we have 3 guests, all booting Windows with 40GB RAM
> > and 8 cores each (we have seen smal
On Sat, Aug 18, 2012 at 05:36:26PM -0700, Nicholas A. Bellinger wrote:
> On Sat, 2012-08-18 at 22:12 +0300, Michael S. Tsirkin wrote:
> > On Tue, Aug 14, 2012 at 01:31:14PM -0700, Nicholas A. Bellinger wrote:
> > > On Mon, 2012-08-13 at 11:53 +0300, Michael S. Tsirkin wrote:
> > > > On Mon, Aug 13,
On 08/17/2012 03:36 PM, Richard Davies wrote:
> Hi Avi,
>
> Thanks to you and several others for offering help. We will work with Avi at
> first, but are grateful for all the other offers of help. We have a number
> of other qemu-related projects which we'd be interested in getting done, and
> wil
On Fri, Aug 17, 2012 at 03:57:55PM +0400, Max Filippov wrote:
> On Fri, Aug 17, 2012 at 3:14 PM, 陳韋任 (Wei-Ren Chen)
> wrote:
> >> > On Thu, Aug 16, 2012 at 7:49 PM, Steven wrote:
> >> > [...]
> >> >> I want to get the guest memory address in the instruction mov
> >> >> 0x4(%ebx) %eax, whic is 0x
On Sat, Aug 18, 2012 at 9:08 PM, Paolo Bonzini wrote:
> That's correct. Live block migration will use two ports, both served by
> the destination, one using NBD and one for RAM/device migration data.
> It will be a little more complicated than just migrate -b, but nothing
> that libvirt cannot or
Hi Paolo,
Am 18.08.2012 23:49, schrieb Paolo Bonzini:
Hi Stefan,
this is my version of your patch. I think the flow of the code is a
bit simpler (or at least matches other implementations of cancellation).
Can you test it on your test case?
I'm really sorry but your patch doesn't work at all.
59 matches
Mail list logo
