There's no code change, just re-arrangement to simplify the function
after recent modifications.
Reported-by: Juan Quintela
Signed-off-by: Amit Shah
---
hw/virtio-serial-bus.c | 12 +++-
1 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/hw/virtio-serial-bus.c b/hw/virtio-
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
Signed-off-by: Amit Shah
---
hw/virtio-console.c |1 -
1 files changed, 0 insertio
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 anybod
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. B
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 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,
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 wrote:
> make the code compile correctly when DEBUG is activated.
>
> Signed-off-by: Vincent Palatin
> ---
> slirp/bootp.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/slirp/bootp.c b/slirp/bootp.c
> index 0905c6d
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
witho
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 ha scritto:
> Da: Vincent Palatin
> Oggetto: Re: [Qemu-devel] Memory Map
> A: "Salvatore Lionet
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 is:
On Wed, Mar 2, 2011 at 3:04 PM, Ryan Harper 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.
>
> Signed-off-by: Ry
On Wed, Mar 2, 2011 at 3:03 PM, Ryan Harper 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 bdrv_delete() ca
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 now
From: Jes Sorensen
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 snapshot file on a virt
On Mon, Feb 28, 2011 at 11:22 AM, M. Mohan Kumar 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 descriptions b
On Thu, Mar 3, 2011 at 10:44 AM, 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,
> QObject **ret
On Mon, Feb 28, 2011 at 11:22 AM, M. Mohan Kumar 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.
> + if (fd_in
On Thu, Mar 03, 2011 at 02:13:56PM +0100, jes.soren...@redhat.com wrote:
> From: Jes Sorensen
>
> 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 cor
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
From: Jes Sorensen
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 snapshot file on a virt
On 03/03/11 14:06, Stefan Hajnoczi wrote:
> On Thu, Mar 3, 2011 at 10:44 AM, 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
On Mon, Feb 28, 2011 at 11:22 AM, M. Mohan Kumar 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
> ---
> hw/9pfs/virtio-9p-chroot-qemu.c | 24 +++-
> hw/9pfs/virtio-9p-chroot.h
On Thursday 03 March 2011 5:08:10 pm Stefan Hajnoczi wrote:
> On Mon, Feb 28, 2011 at 11:22 AM, M. Mohan Kumar wrote:
> > +retval = recvmsg(sockfd, &msg, 0);
> > +if (retval < 0) {
> > +*sock_error = 1;
> > +return -EIO;
> > +}
>
> Are we guaranteed this will be called
On Thu, Mar 3, 2011 at 1:54 PM, M. Mohan Kumar 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) {
>> > + f
On 24 February 2011 18:57, Juan Quintela wrote:
> Signed-off-by: Juan Quintela
> ---
> hw/pxa2xx_pic.c | 52
> 1 files changed, 20 insertions(+), 32 deletions(-)
Hi Juan,
I pushed an earlier patch from Dmitry Eremin-Solenikov that converte
On Thu, Mar 3, 2011 at 2:01 PM, M. Mohan Kumar 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 wrote:
>> > + retval = recvmsg(sockfd, &msg, 0);
>> > + if (retval < 0) {
>> > + *sock_error = 1;
>> > + retu
On 25 February 2011 14:50, Dmitry Eremin-Solenikov wrote:
> On 2/25/11, andrzej zaborowski wrote:
>> Hi Dmitry,
>>
>> On 20 February 2011 14:50, Dmitry Eremin-Solenikov
>> wrote:
>>> Use qdev/sysbus framework to handle pxa2xx-pic. Instead of exposing IRQs
>>> via array, reference them via qdev_g
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, so
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
---
linux-user/syscall.c | 28 +---
1 files changed, 21 insertions(+), 7 deletions(-)
diff
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 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 oof cases is
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 wh
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 defaul
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 wro
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
> CC: Hidetoshi Seto
> CC: Huang Ying
> CC: Jin Dongming
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
On Thu, Mar 3, 2011 at 7:16 PM, Aurelien Jarno 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
> virtio-net it seems
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 sma
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 windo
On Thu, Mar 03, 2011 at 07:50:03PM +, Stefan Hajnoczi wrote:
> On Thu, Mar 3, 2011 at 7:16 PM, Aurelien Jarno 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 diffe
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 me
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 st
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 b
On 21 February 2011 23:19, Adam Lackorzynski 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)
> }
> qemu_put_be32(f, env->
On Thu Mar 03, 2011 at 22:59:03 +, Peter Maydell wrote:
> On 21 February 2011 23:19, Adam Lackorzynski
> 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 @@ v
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 to
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
---
hw/pxa2xx_pic.c | 37 +++--
1 files changed, 19 insertions(+),
Signed-off-by: Dmitry Eremin-Solenikov
---
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 TC6393xbState {
ui
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
---
vl.c | 104 +-
1 files changed, 5
Signed-off-by: Dmitry Eremin-Solenikov
---
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 mainstone_common_init(ram_add
Extend mst_fpga and mainstone with logic to support PCMCIA
attachment (IRQs, status regs).
Signed-off-by: Dmitry Eremin-Solenikov
---
hw/mainstone.c |7 +++
hw/mst_fpga.c | 29 +++--
2 files changed, 34 insertions(+), 2 deletions(-)
diff --git a/hw/mainstone.c
From: Roland Dreier
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 an int. As soon as zs
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, f
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 Th
04.03.2011 03:57, Roland Dreier wrote:
> From: Roland Dreier
>
> 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 i
[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
>
> If one leaves a VNC session with tight compression running for long
> enough, Qemu crashes. This is because of the computation
>
>
58 matches
Mail list logo
