There's no code change, just re-arrangement to simplify the function
after recent modifications.
Reported-by: Juan Quintela quint...@redhat.com
Signed-off-by: Amit Shah amit.s...@redhat.com
---
hw/virtio-serial-bus.c | 12 +++-
1 files changed, 3 insertions(+), 9 deletions(-)
diff
After a port unplug operation, the port-info-have_data() pointer was
set to NULL. The problem is, the -info struct is shared by all ports,
effectively disabling writes to other ports.
Reported-by: juzhang juzh...@redhat.com
Signed-off-by: Amit Shah amit.s...@redhat.com
---
hw/virtio-console.c |
Am Dienstag 01 März 2011 10:47:00 schrieb asim khan:
Hi,
Iam using qemu 0.13.0.whenever Iam playing any audio(wav or mp3 file)
using ffplay there is alot of jittring sound or distorted audio very much
in case of mp3 files.so Iam trying to figure out what could be the
problem..so anybody
On Mar 3, 2011, at 7:43 AM, vagran wrote:
I am using TianoCore EFI by Tristan Gingold which is published
on http://wiki.qemu.org/download/efi-bios.tar.bz2. If you would try
to load it on Qemu 0.14.0 (built either for i386 or x86_64) you will
see nothing on VGA display or serial console. But
On 03/02/2011 09:42 PM, Marcelo Tosatti wrote:
On Wed, Mar 02, 2011 at 04:36:34PM -0300, Marcelo Tosatti wrote:
On Wed, Mar 02, 2011 at 08:03:42PM +0100, Jan Kiszka wrote:
On 2011-03-02 19:43, Marcelo Tosatti wrote:
On Tue, Mar 01, 2011 at 02:35:56PM +0200, Avi Kivity wrote:
On
On 2011-03-03 09:48, Avi Kivity wrote:
On 03/02/2011 09:42 PM, Marcelo Tosatti wrote:
On Wed, Mar 02, 2011 at 04:36:34PM -0300, Marcelo Tosatti wrote:
On Wed, Mar 02, 2011 at 08:03:42PM +0100, Jan Kiszka wrote:
On 2011-03-02 19:43, Marcelo Tosatti wrote:
On Tue, Mar 01, 2011 at
On 03/03/2011 11:07 AM, Jan Kiszka wrote:
Well that's strange, since qemu-kvm now passes autotest (and this was
qemu.git + patchset, not qemu-kvm).
Does it fail every time? Have you tested if qemu.git also fails without
the patches? Then we may have a chance to bisect.
I didn't check.
On Wed, Mar 2, 2011 at 10:25 PM, Vincent Palatin vpala...@chromium.org wrote:
make the code compile correctly when DEBUG is activated.
Signed-off-by: Vincent Palatin vpala...@chromium.org
---
slirp/bootp.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git
On 03/03/2011 10:07 AM, Jan Kiszka wrote:
Does it fail every time? Have you tested if qemu.git also fails without
the patches? Then we may have a chance to bisect.
I plan to check this sometime between today and Monday.
One thing Avi can answer is: do you routinely test qemu.git with or
Sure, i'm very interested in.
I've used another implementation that still require large amount of data to be
allocated (but with O(1) search time)
Have a good day
--- Mer 2/3/11, Vincent Palatin vpala...@chromium.org ha scritto:
Da: Vincent Palatin vpala...@chromium.org
Oggetto: Re:
On 03/03/2011 11:13 AM, Paolo Bonzini wrote:
On 03/03/2011 10:07 AM, Jan Kiszka wrote:
Does it fail every time? Have you tested if qemu.git also fails without
the patches? Then we may have a chance to bisect.
I plan to check this sometime between today and Monday.
One thing Avi can answer
On Wed, Mar 2, 2011 at 3:04 PM, Ryan Harper ry...@us.ibm.com wrote:
If the block device has been closed, we no longer have a medium to submit
IO against, check for this before submitting io. This prevents a segfault
further in the code where we dereference elements of the block driver.
On Wed, Mar 2, 2011 at 3:03 PM, Ryan Harper ry...@us.ibm.com wrote:
+void bdrv_remove(BlockDriverState *bs)
+{
+ if (bs-device_name[0] != '\0') {
+ QTAILQ_REMOVE(bdrv_states, bs, list);
+ }
+}
It's not safe to invoke QTAILQ_REMOVE() twice. Since both
do_drive_del() and
Hello,
is it possible to run OS X in kvm or qemu?
I would like to be able to test some stuff in OS X on my mac mini
without rebooting the system.
Last time I looked at this I found a bunch of patches. From the top of
my head these included:
multiboot support to be able to use BootX (in qemu
From: Jes Sorensen jes.soren...@redhat.com
In case we cannot open the newly created snapshot image, try to fall
back to the original image file and continue running on that, which
should prevent the guest from aborting.
This is a corner case which can happen if the admin by mistake
specifies the
On Mon, Feb 28, 2011 at 11:22 AM, M. Mohan Kumar mo...@in.ibm.com wrote:
Implement chroot daemon side interfaces like sending the file
descriptor to qemu process, reading the object request from socket etc.
Also add chroot main function and other helper routines.
daemon and dm aren't accurate
On Thu, Mar 3, 2011 at 10:44 AM, jes.soren...@redhat.com wrote:
+ char old_filename[1024];
+
+ old_filename[1023] = '\0';
if (!filename) {
qerror_report(QERR_MISSING_PARAMETER, snapshot_file);
@@ -591,6 +594,10 @@ int do_snapshot_blkdev(Monitor *mon, const QDict *qdict,
On Mon, Feb 28, 2011 at 11:22 AM, M. Mohan Kumar mo...@in.ibm.com wrote:
+ retval = recvmsg(sockfd, msg, 0);
+ if (retval 0) {
+ *sock_error = 1;
+ return -EIO;
+ }
Are we guaranteed this will be called with signals blocked? Otherwise
we need to handle EINTR.
+
On Thu, Mar 03, 2011 at 02:13:56PM +0100, jes.soren...@redhat.com wrote:
From: Jes Sorensen jes.soren...@redhat.com
In case we cannot open the newly created snapshot image, try to fall
back to the original image file and continue running on that, which
should prevent the guest from aborting.
On 03/02/11 14:49, Michael Roth wrote:
On 03/02/2011 07:18 AM, Jes Sorensen wrote:
I think we need two types for sure, even for the video case, we will
still need a control channel as well. However, I don't think it is
desirable to split things up more than we have to, so if we can keep it
From: Jes Sorensen jes.soren...@redhat.com
In case we cannot open the newly created snapshot image, try to fall
back to the original image file and continue running on that, which
should prevent the guest from aborting.
This is a corner case which can happen if the admin by mistake
specifies the
On 03/03/11 14:06, Stefan Hajnoczi wrote:
On Thu, Mar 3, 2011 at 10:44 AM, jes.soren...@redhat.com wrote:
+char old_filename[1024];
+
+old_filename[1023] = '\0';
if (!filename) {
qerror_report(QERR_MISSING_PARAMETER, snapshot_file);
@@ -591,6 +594,10 @@ int
On Mon, Feb 28, 2011 at 11:22 AM, M. Mohan Kumar mo...@in.ibm.com wrote:
This patch adds both chroot deamon and qemu side support to open a file/
directory in the chroot environment
Signed-off-by: M. Mohan Kumar mo...@in.ibm.com
---
hw/9pfs/virtio-9p-chroot-qemu.c | 24 +++-
On Thursday 03 March 2011 5:08:10 pm Stefan Hajnoczi wrote:
On Mon, Feb 28, 2011 at 11:22 AM, M. Mohan Kumar mo...@in.ibm.com wrote:
+retval = recvmsg(sockfd, msg, 0);
+if (retval 0) {
+*sock_error = 1;
+return -EIO;
+}
Are we guaranteed this will be
On Thu, Mar 3, 2011 at 1:54 PM, M. Mohan Kumar mo...@in.ibm.com wrote:
On Thursday 03 March 2011 5:39:55 pm Stefan Hajnoczi wrote:
+ v9fs_write_request(fs_ctx-chroot_socket, request);
+ fd = v9fs_receivefd(fs_ctx-chroot_socket, sock_error);
+ if (fd 0 sock_error) {
+
On 24 February 2011 18:57, Juan Quintela quint...@redhat.com wrote:
Signed-off-by: Juan Quintela quint...@redhat.com
---
hw/pxa2xx_pic.c | 52
1 files changed, 20 insertions(+), 32 deletions(-)
Hi Juan,
I pushed an earlier patch from
On Thu, Mar 3, 2011 at 2:01 PM, M. Mohan Kumar mo...@in.ibm.com wrote:
On Thursday 03 March 2011 5:08:10 pm Stefan Hajnoczi wrote:
On Mon, Feb 28, 2011 at 11:22 AM, M. Mohan Kumar mo...@in.ibm.com wrote:
+ retval = recvmsg(sockfd, msg, 0);
+ if (retval 0) {
+ *sock_error = 1;
On 25 February 2011 14:50, Dmitry Eremin-Solenikov dbarysh...@gmail.com wrote:
On 2/25/11, andrzej zaborowski balr...@gmail.com wrote:
Hi Dmitry,
On 20 February 2011 14:50, Dmitry Eremin-Solenikov dbarysh...@gmail.com
wrote:
Use qdev/sysbus framework to handle pxa2xx-pic. Instead of exposing
On Thursday 03 March 2011 5:39:55 pm Stefan Hajnoczi wrote:
+v9fs_write_request(fs_ctx-chroot_socket, request);
+fd = v9fs_receivefd(fs_ctx-chroot_socket, sock_error);
+if (fd 0 sock_error) {
+fs_ctx-chroot_ioerror = 1;
+}
chroot_ioerror, sock_error, and
PTHREAD_STACK_MIN (16KB) is somewhat inadequate for a new stack. follow
the pthread_create defaults, ie setting to RLIMIT_STACK or if unlimited
to 2MB.
Signed-off-by: Riku Voipio riku.voi...@nokia.com
---
linux-user/syscall.c | 28 +---
1 files changed, 21
On Thu, Mar 03, 2011 at 05:37:37PM +0200, Riku Voipio wrote:
PTHREAD_STACK_MIN (16KB) is somewhat inadequate for a new stack. follow
the pthread_create defaults, ie setting to RLIMIT_STACK or if unlimited
to 2MB.
For what sort oof cases is it inadequate? This stack is just for QEMU's
usage
On 3 March 2011 15:46, Nathan Froyd froy...@codesourcery.com wrote:
On Thu, Mar 03, 2011 at 05:37:37PM +0200, Riku Voipio wrote:
PTHREAD_STACK_MIN (16KB) is somewhat inadequate for a new stack. follow
the pthread_create defaults, ie setting to RLIMIT_STACK or if unlimited
to 2MB.
For what
On Thu, Mar 03, 2011 at 07:46:27AM -0800, Nathan Froyd wrote:
On Thu, Mar 03, 2011 at 05:37:37PM +0200, Riku Voipio wrote:
PTHREAD_STACK_MIN (16KB) is somewhat inadequate for a new stack. follow
the pthread_create defaults, ie setting to RLIMIT_STACK or if unlimited
to 2MB.
For what sort
On Thu, Mar 03, 2011 at 06:15:49PM +0200, Riku Voipio wrote:
On Thu, Mar 03, 2011 at 07:46:27AM -0800, Nathan Froyd wrote:
On Thu, Mar 03, 2011 at 05:37:37PM +0200, Riku Voipio wrote:
PTHREAD_STACK_MIN (16KB) is somewhat inadequate for a new stack. follow
the pthread_create defaults, ie
I have taken EFI BIOS image from
http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF
32-bit version works perfectly. However 64-bit version for some reason
doesn't work on
qemu-system-x86_64. But anyway, it is enough for me. Thank you.
Best regards,
Artyom.
Tristan Gingold
On Wed, Mar 02, 2011 at 08:56:03AM +0100, Jan Kiszka wrote:
This is mostly a rebase of the previous round, just including one
additional ppc build fix (patch 2) for a regression in a previous part.
Please merge.
CC: David Gibson da...@gibson.dropbear.id.au
CC: Hidetoshi Seto
On Mon, Feb 28, 2011 at 08:43:41AM +, Liu Yu-B13201 wrote:
-Original Message-
From: qemu-devel-bounces+yu.liu=freescale@nongnu.org
[mailto:qemu-devel-bounces+yu.liu=freescale@nongnu.org]
On Behalf Of Aurelien Jarno
Sent: Sunday, January 16, 2011 3:28 AM
To:
On Thu, Mar 3, 2011 at 7:16 PM, Aurelien Jarno aurel...@aurel32.net wrote:
The endianness handling in virtio-net is different than in virtio-blk.
In virtio-blk we basically have to byteswap the data when the endianness
of the guest is different than the one of the guest. If I am correct, in
Commit bc2429b9174ac2d3c56b7fd35884b0d89ec7fb02 introduced
a severe bug (stack corruption).
bitmap_clear was called with a wrong argument
which caused out-of-bound writes to the local variable width_mask.
This bug was detected with QEMU running on windows.
It also occurs with wine:
*** stack
Am 03.03.2011 21:37, schrieb Stefan Weil:
Commit bc2429b9174ac2d3c56b7fd35884b0d89ec7fb02 introduced
a severe bug (stack corruption).
bitmap_clear was called with a wrong argument
which caused out-of-bound writes to the local variable width_mask.
This bug was detected with QEMU running on
On Thu, Mar 03, 2011 at 07:50:03PM +, Stefan Hajnoczi wrote:
On Thu, Mar 3, 2011 at 7:16 PM, Aurelien Jarno aurel...@aurel32.net wrote:
The endianness handling in virtio-net is different than in virtio-blk.
In virtio-blk we basically have to byteswap the data when the endianness
of the
A pointer to a size_t variable was passed as the void * pointer to
lduw_p() in virtio_net_receive(). Instead of acting on the 16-bit value
this caused failure on big-endian hosts.
Avoid this issue in the future by using stw_p() instead. In general we
should use ld*_p() for loading from target
On Thu, Mar 03, 2011 at 09:42:28PM +, Stefan Hajnoczi wrote:
A pointer to a size_t variable was passed as the void * pointer to
lduw_p() in virtio_net_receive(). Instead of acting on the 16-bit value
this caused failure on big-endian hosts.
Avoid this issue in the future by using
On Thu, Feb 10, 2011 at 04:53:04PM +, Peter Maydell wrote:
If CONFIG_USE_GUEST_BASE is not defined, gcc complains:
linux-user/mmap.c:235: error: comparison of unsigned expression = 0 is
always true
because RESERVED_VA is #defined to 0. Since mmap_find_vma_reserved()
will never be
On 21 February 2011 23:19, Adam Lackorzynski a...@os.inf.tu-dresden.de wrote:
diff --git a/target-arm/machine.c b/target-arm/machine.c
index 3925d3a..a18b7dc 100644
--- a/target-arm/machine.c
+++ b/target-arm/machine.c
@@ -41,6 +41,7 @@ void cpu_save(QEMUFile *f, void *opaque)
}
On Thu Mar 03, 2011 at 22:59:03 +, Peter Maydell wrote:
On 21 February 2011 23:19, Adam Lackorzynski a...@os.inf.tu-dresden.de
wrote:
diff --git a/target-arm/machine.c b/target-arm/machine.c
index 3925d3a..a18b7dc 100644
--- a/target-arm/machine.c
+++ b/target-arm/machine.c
@@
First, sysbus_init_irq shan't be called on on-stack variables. Indeed,
it only stores a passed pointer in qdev and the stored irq is later
populated, so we get a nice write-to-stack bug.
Second, irq for pxa27x should probably be handled in a more gentler way,
as we should check if we have events
Currently pxa2xx_pic init fails with error at sysbus_mmio_map(),
as there is no correspondent sysbus_init_mmio. Also move most of init to
pxa2xx_pic_initfn.
Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
---
hw/pxa2xx_pic.c | 37 +++--
1 files
Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
---
hw/tc6393xb.c | 17 ++---
1 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/hw/tc6393xb.c b/hw/tc6393xb.c
index ed49e94..14847a9 100644
--- a/hw/tc6393xb.c
+++ b/hw/tc6393xb.c
@@ -126,7 +126,8 @@ struct
Init not only first displaystate, but all. Otherwise machines with
multiple display devices (e.g. tosa, as it exists now) will just
segfault on ds switch.
Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
---
vl.c | 104
Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
---
hw/mainstone.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/mainstone.c b/hw/mainstone.c
index 4eabdb9..8970dd8 100644
--- a/hw/mainstone.c
+++ b/hw/mainstone.c
@@ -140,7 +140,7 @@ static void
Extend mst_fpga and mainstone with logic to support PCMCIA
attachment (IRQs, status regs).
Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
---
hw/mainstone.c |7 +++
hw/mst_fpga.c | 29 +++--
2 files changed, 34 insertions(+), 2 deletions(-)
diff
From: Roland Dreier rol...@purestorage.com
If one leaves a VNC session with tight compression running for long
enough, Qemu crashes. This is because of the computation
bytes = zstream-total_out - previous_out;
in tight_compress_data, where zstream-total_out is a uLong but
previous_out is
Yokshiaki:
event-tap record block and io wirte events, and replay these on
the other side, so block_save_live is useless during the latter ft
phase, right? if so, I think it need to process the following code in
block_save_live function:
if (stage == 1) {
init_blk_migration(mon,
Hi,
Iam using qemu 0.14.0 and trying to wav file..on console it shows that
its playing but there is no audio.
if I play the same file with aplay it gives an error*aplay: pcm_write:1603:
write error: Input/output error.*so doono whats going wrong.??
Actually earlier i was using
-Original Message-
From: Aurelien Jarno [mailto:aurel...@aurel32.net]
Sent: Friday, March 04, 2011 6:46 AM
To: Stefan Hajnoczi
Cc: Liu Yu-B13201; Anthony Liguori; qemu-devel@nongnu.org
Subject: Re: [PATCH] virtio-net: Fix lduw_p() pointer
argument of wrong size
On Thu, Mar
04.03.2011 03:57, Roland Dreier wrote:
From: Roland Dreier rol...@purestorage.com
If one leaves a VNC session with tight compression running for long
enough, Qemu crashes. This is because of the computation
bytes = zstream-total_out - previous_out;
in tight_compress_data, where
[And sure thing I forgot to Cc Corentin Chary. ENOCOFFEE.
Please excuse me for the double post]
04.03.2011 03:57, Roland Dreier wrote:
From: Roland Dreier rol...@purestorage.com
If one leaves a VNC session with tight compression running for long
enough, Qemu crashes. This is because of
58 matches
Mail list logo
