On 06.10.2013 15:57, Zhang Haoyu wrote:
>From my testing this has been fixed in the saucy version (1.5.0) of
qemu. It is fixed by this patch:
f1c72795af573b24a7da5eb52375c9aba8a37972
However later in the history this commit was reverted, and again broke
this. The other commit that fixes this
if a raw device like an iscsi target or host device is used
the current implementation makes a second call out to get
the block status of bs->file.
Signed-off-by: Peter Lieven
---
v5: add a generic get_lba_status function in the raw driver which
adds the BDRV_BLOCK_RAW flag. bdrv_co_get_block
On 10/04/2013 04:13 PM, Paolo Bonzini wrote:
> Il 04/10/2013 02:04, Marcelo Tosatti ha scritto:
>> This QMP command allows user set guest node's memory policy
>> through the QMP protocol. The qmp-shell command is like:
>> set-mem-policy nodeid=0 policy=membind relative=true host-nod
On 7 October 2013 02:26, Andreas Färber wrote:
> Am 06.10.2013 14:10, schrieb Peter Maydell:
>> The major thing we need is a mechanism for allowing at least the
>> board, and possibly also the user, to specify properties of the cpu
>> like "which rev/patchlevel is it"
>
> I believe I posted patche
Hi,
Default vexpress_defconfig does not boot on qemu vexpress-a9 target. In kernel,
vexpress uart detection for DEBUG_LL is done using Coretex-A9 id. Only r0p1 is
mapped to legacy map. All other variants are mapped to RS1/aseries map.
As qemu vexpress-a9 target reports Cortex-A9 version as r0p0,
On Fri, Oct 04, 2013 at 06:18:42PM +0200, Igor Mammedov wrote:
> On Thu, 3 Oct 2013 18:05:35 +0300
> "Michael S. Tsirkin" wrote:
>
> > This defines a structure that will be used to fill in acpi tables
> > where relevant properties are not yet available using QOM.
> >
> > Reviewed-by: Laszlo Erse
Il 06/10/2013 20:28, Michael S. Tsirkin ha scritto:
> > > > For each PCI device I tried creating a VM with an instance of it (a few
> > > > devices at a time), and did VM resets. Earlier versions were tested by
> > > > the guy who reported the SCSI problems.
> > >
> > > x86 kvm only?
> >
> > Yes
On Fri, Oct 04, 2013 at 06:18:42PM +0200, Igor Mammedov wrote:
> On Thu, 3 Oct 2013 18:05:35 +0300
> "Michael S. Tsirkin" wrote:
>
> > This defines a structure that will be used to fill in acpi tables
> > where relevant properties are not yet available using QOM.
> >
> > Reviewed-by: Laszlo Erse
On Thu, Oct 03, 2013 at 06:53:10PM +0200, Paolo Bonzini wrote:
> Il 03/10/2013 18:54, Michael S. Tsirkin ha scritto:
> > > For each PCI device I tried creating a VM with an instance of it (a few
> > > devices at a time), and did VM resets. Earlier versions were tested by
> > > the guy who reported
Am 06.10.2013 14:10, schrieb Peter Maydell:
> The major thing we need is a mechanism for allowing at least the
> board, and possibly also the user, to specify properties of the cpu
> like "which rev/patchlevel is it"
I believe I posted patches for that long ago, to clean up the PXA mess a
little..
hi all I found a bug in qemu, when i invoke:
cpu_physical_memory_rw(addr, mem_buf, noOfBytes, 0);
where addr=0x0 and noOfBytes=50, qemu will has segmentation fault. I call
the cpu_physical_memory_rw right after the qemu is started (haven't run yet)
with gdb.
Thanksfrom Peter
>>From my testing this has been fixed in the saucy version (1.5.0) of
qemu. It is fixed by this patch:
>f1c72795af573b24a7da5eb52375c9aba8a37972
>
>However later in the history this commit was reverted, and again broke
this. The other commit that fixes this is:
>211ea74022f51164a7729030b28eec90b6c9
Hi,
I've double checked my conf, I can confirm I'm not using virtio but
standard Win 7 drivers. (please see my VM conf that I posted some time ago).
So it's not definitely a virtio-specific issue.
On 3 October 2013 16:31, Serge Hallyn <1180...@bugs.launchpad.net> wrote:
> Quoting Vasile Dumitr
On 6 October 2013 20:12, Mian Yousaf Kaukab wrote:
> Default vexpress_defconfig does not boot on qemu vexpress-a9 target. In
> kernel,
> vexpress uart detection for DEBUG_LL is done using Coretex-A9 id. Only r0p1 is
> mapped to legacy map. All other variants are mapped to RS1/aseries map.
Detect
From: Amos Kong
Touched some error after enabling DEBUG_SUBPAGE.
Signed-off-by: Amos Kong
Reviewed-by: Paolo Bonzini
Signed-off-by: Michael Tokarev
---
exec.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/exec.c b/exec.c
index 26681ce..51c2369 10064
From: Stefan Weil
While dirent->d_type is 8 bit for most systems, it is 32 bit for MinGW.
Reducing it to 8 bit results in a compiler warning because the macro
is_dir_maybe compares that 8 bit value with 32 bit constants.
Using 'unsigned' instead of 'unsigned char' matches the declaration for
Min
From: Stefan Weil
>From buildbot default_i386_rhel61:
CCalpha-softmmu/hw/alpha/typhoon.o
hw/alpha/typhoon.c: In function 'typhoon_translate_iommu':
hw/alpha/typhoon.c:703: warning: integer constant is too large for 'long' type
hw/alpha/typhoon.c:703: warning: integer constant is too large
From: Stefan Weil
Latest gcc-4.8 supports a new option -fsanitize=address which activates
an AddressSanitizer. This AddressSanitizer stops the QEMU system emulation
very early because two character arrays of size 8 are potentially written
with 9 bytes.
Commit 6ea314d91439741e95772dfbab98b4135e04
From: Ján Veselý
Device communication errors need to be reported to driver.
Add a debug message while at it.
Signed-off-by: Jan Vesely
Acked-by: Gerd Hoffmann
Signed-off-by: Michael Tokarev
---
hw/usb/hcd-ohci.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/hw/usb/hcd-ohci.c b/hw/
From: Stefan Weil
blockdev.c:1929:13: warning: Value stored to 'ret' is never read
ret = 0;
^ ~
Signed-off-by: Stefan Weil
Signed-off-by: Michael Tokarev
---
blockdev.c |1 -
1 file changed, 1 deletion(-)
diff --git a/blockdev.c b/blockdev.c
index 8aa66a9..8c8
From: Fam Zheng
Signed-off-by: Fam Zheng
Reviewed-by: Wenchao Xia
Signed-off-by: Michael Tokarev
---
tests/qemu-iotests/.gitignore |1 +
1 file changed, 1 insertion(+)
diff --git a/tests/qemu-iotests/.gitignore b/tests/qemu-iotests/.gitignore
index 62b4002..0541f80 100644
--- a/tests/qemu
Signed-off-by: Michael Tokarev
Reviewed-by: Stefan Weil
---
migration.c |1 +
1 file changed, 1 insertion(+)
diff --git a/migration.c b/migration.c
index b4f8462..2b1ab20 100644
--- a/migration.c
+++ b/migration.c
@@ -150,6 +150,7 @@ MigrationCapabilityStatusList
*qmp_query_migrate_capabil
From: Markus Armbruster
Messed up in commit 8281abd.
Signed-off-by: Markus Armbruster
Signed-off-by: Michael Tokarev
---
vl.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/vl.c b/vl.c
index 983cdc6..7e1f408 100644
--- a/vl.c
+++ b/vl.c
@@ -2825,7 +2825,7 @@ int
From: "Daniel P. Berrange"
If there is no operation driver for the xattr type the
functions return '-1' and set errno to '-EOPNOTSUPP'.
When the calling code sets 'ret = -errno' this turns
into a large positive number.
In Linux 3.11, the kernel has switched to using 9p
version 9p2000.L, instead
From: Stefan Weil
>From buildbot default_i386_rhel61:
CCi386-softmmu/target-i386/arch_memory_mapping.o
target-i386/arch_memory_mapping.c: In function 'walk_pde':
target-i386/arch_memory_mapping.c:110: warning:
integer constant is too large for 'long' type
Signed-off-by: Stefan Weil
Sign
From: Guenter Roeck
With Linux kernel version 3.3 or later, qemu fails with the following message:
sh_serial: unsupported read from 0x18
Aborted
Reported-and-analyzed-by: Rob Landley
Signed-off-by: Guenter Roeck
Reviewed-by: Peter Maydell
Signed-off-by: Michael Tokarev
---
hw/char/sh_ser
From: Markus Armbruster
Commit 4f193e3 added the test, but screwed up in-tree builds
(SRCDIR=.): the tests's output overwrites the expected output, and is
thus compared to itself.
Cc: qemu-sta...@nongnu.org
Reported-by: Laszlo Ersek
Reviewed-by: Andreas Färber
Reviewed-by: Laszlo Ersek
Signed
From: Markus Armbruster
Forgotten in commit 6046c62 and 3464700.
Cc: qemu-sta...@nongnu.org
Reviewed-by: Andreas Färber
Reviewed-by: Laszlo Ersek
Signed-off-by: Markus Armbruster
Signed-off-by: Michael Tokarev
---
tests/.gitignore |2 ++
1 file changed, 2 insertions(+)
diff --git a/tes
Here's another trivial patche pull request, for patches collected
in last 2 weeks (2 instead of 1 because both week were more or
less quiet and there weren't many patches). There's nothing
exciting in here, but there are a few minor fixes for small but
annoying-in-some-environments issues.
Please
On Sun, Oct 06, 2013 at 07:47:02AM +0200, Stefan Weil wrote:
> What about removing the comment with the configure parameters
> from config-host.mak?
Sound like a good idea.
> * Easier code - no need to create a configure call from a comment.
Note we still need some escaping for single quotes, bu
30 matches
Mail list logo
