Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On Mon, Jul 25, 2011 at 9:51 AM, Avi Kivity wrote: > qemu_malloc() is type-unsafe as it returns a void pointer.  Introduce > QEMU_NEW() (and QEMU_NEWZ()), which return the correct type. > > Signed-off-by: Avi Kivity > --- > > This is part of my memory API patchset, but doesn't really belong there

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On 07/25/2011 01:04 PM, Alexander Graf wrote: On 25.07.2011, at 12:02, Avi Kivity wrote: > On 07/25/2011 12:56 PM, Alexander Graf wrote: >> > >> > That argument can be used to block any change. You'll get used to it in time. The question is, is the new interface better or not. >> >> I a

Re: [Qemu-devel] [RFC] ppc: qdev-ify CPU creation

On 24.07.2011, at 21:08, Hervé Poussineau wrote: > Alexander Graf a écrit : >> On 21.12.2010, at 21:01, Andreas Färber wrote: >> >> >>> From: Hervé Poussineau >>> >>> v1: >>> * Coding style fixes. >>> >>> Signed-off-by: Hervé Poussineau >>> Cc: Alexander Graf >>> Signed-off-by: Andreas Fä

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On 07/25/2011 01:06 PM, Stefan Hajnoczi wrote: >char *qemu_strndup(const char *str, size_t size); > > +#define QEMU_NEW(type) ((type *)(qemu_malloc(sizeof(type > +#define QEMU_NEWZ(type) ((type *)(qemu_mallocz(sizeof(type Does this mean we need to duplicate the type name for each a

Re: [Qemu-devel] [Qemu-trivial] [PATCH] Makefile: fix out-of-tree builds

On Thu, Jul 21, 2011 at 5:41 AM, Alexandre Raymond wrote: > This patch fixes a minor bugs which prevented QEMU from being built > out of tree. > > Signed-off-by: Alexandre Raymond > --- >  Makefile |    2 +- >  1 files changed, 1 insertions(+), 1 deletions(-) I don't normally use --source-path b

Re: [Qemu-devel] [Qemu-trivial] [PATCH] vhost build fix for i386

On Mon, Jul 11, 2011 at 02:57:43PM +0200, Wolfgang Mauerer wrote: > vhost.c uses __sync_fetch_and_and(), which is only > available for -march=i486 and above (see > https://bugzilla.redhat.com/show_bug.cgi?id=624279). > > Signed-off-by: Wolfgang Mauerer > --- > configure | 23 ++

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On 25.07.2011, at 12:09, Avi Kivity wrote: > On 07/25/2011 01:04 PM, Alexander Graf wrote: >> On 25.07.2011, at 12:02, Avi Kivity wrote: >> >> > On 07/25/2011 12:56 PM, Alexander Graf wrote: >> >> > >> >> > That argument can be used to block any change. You'll get used to >> >> it in time

Re: [Qemu-devel] [Qemu-trivial] [PATCH] sh4: Fix potential crash in debug code

On Wed, Jul 20, 2011 at 08:56:35PM +0200, Stefan Weil wrote: > cppcheck reports this error: > > qemu/hw/sh_intc.c:390: error: Possible null pointer dereference: > s - otherwise it is redundant to check if s is null at line 385 > > If s were NULL, the printf() statement would crash. > Setting bra

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

Am 25.07.2011 12:06, schrieb Stefan Hajnoczi: > On Mon, Jul 25, 2011 at 9:51 AM, Avi Kivity wrote: >> qemu_malloc() is type-unsafe as it returns a void pointer. Introduce >> QEMU_NEW() (and QEMU_NEWZ()), which return the correct type. >> >> Signed-off-by: Avi Kivity >> --- >> >> This is part of

Re: [Qemu-devel] [Qemu-trivial] [PATCH v2] Makefile: Minor cscope fixups

On Wed, Jul 20, 2011 at 11:12:15PM -0400, Alexandre Raymond wrote: > Changes since v1: > -Use SRC_PATH instead of PWD > > -Create cscope symbols for assembly files in addition to .c/.h files. > -Create cscope database with full path instead of relative path so cscope > can be used with CSCOPE_DB

Re: [Qemu-devel] [RESEND][PATCH v3] Generalize -machine command line option

On 2011-07-25 11:41, Richard W.M. Jones wrote: > On Sat, Jul 23, 2011 at 12:38:37PM +0200, Jan Kiszka wrote: >> From: Jan Kiszka >> >> -machine somehow suggests that it selects the machine, but it doesn't. >> Fix that before this command is set in stone. >> >> Actually, -machine should supersede -

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On Mon, Jul 25, 2011 at 11:25 AM, Kevin Wolf wrote: > Am 25.07.2011 12:06, schrieb Stefan Hajnoczi: >> On Mon, Jul 25, 2011 at 9:51 AM, Avi Kivity wrote: >>> qemu_malloc() is type-unsafe as it returns a void pointer.  Introduce >>> QEMU_NEW() (and QEMU_NEWZ()), which return the correct type. >>>

Re: [Qemu-devel] [RESEND][PATCH v3] Generalize -machine command line option

On Mon, Jul 25, 2011 at 12:33:01PM +0200, Jan Kiszka wrote: > On 2011-07-25 11:41, Richard W.M. Jones wrote: > > On Sat, Jul 23, 2011 at 12:38:37PM +0200, Jan Kiszka wrote: > >> From: Jan Kiszka > >> > >> -machine somehow suggests that it selects the machine, but it doesn't. > >> Fix that before t

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On Mon, 25 Jul 2011, Alexander Graf wrote: > > On 25.07.2011, at 12:09, Avi Kivity wrote: > > > On 07/25/2011 01:04 PM, Alexander Graf wrote: > >> On 25.07.2011, at 12:02, Avi Kivity wrote: > >> > >> > On 07/25/2011 12:56 PM, Alexander Graf wrote: > >> >> > > >> >> > That argument can be u

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

Avi Kivity writes: > On 07/25/2011 01:04 PM, Alexander Graf wrote: >> On 25.07.2011, at 12:02, Avi Kivity wrote: >> >> > On 07/25/2011 12:56 PM, Alexander Graf wrote: >> >> > >> >> > That argument can be used to block any change. You'll get used to >> >> it in time. The question is, is th

Re: [Qemu-devel] [RESEND][PATCH v3] Generalize -machine command line option

On 2011-07-25 12:45, Richard W.M. Jones wrote: > On Mon, Jul 25, 2011 at 12:33:01PM +0200, Jan Kiszka wrote: >> On 2011-07-25 11:41, Richard W.M. Jones wrote: >>> On Sat, Jul 23, 2011 at 12:38:37PM +0200, Jan Kiszka wrote: From: Jan Kiszka -machine somehow suggests that it selects t

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

Kevin Wolf writes: > Am 25.07.2011 12:06, schrieb Stefan Hajnoczi: >> On Mon, Jul 25, 2011 at 9:51 AM, Avi Kivity wrote: >>> qemu_malloc() is type-unsafe as it returns a void pointer. Introduce >>> QEMU_NEW() (and QEMU_NEWZ()), which return the correct type. >>> >>> Signed-off-by: Avi Kivity >

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On 25.07.2011, at 12:59, Markus Armbruster wrote: > Avi Kivity writes: > >> On 07/25/2011 01:04 PM, Alexander Graf wrote: >>> On 25.07.2011, at 12:02, Avi Kivity wrote: >>> On 07/25/2011 12:56 PM, Alexander Graf wrote: >> >> That argument can be used to block any change. You'll

Re: [Qemu-devel] [RFC][PATCH 0/21] QEMU Object Model

Am 25.07.2011 03:44, schrieb Anthony Liguori: > Hi, > > This series is the rough beginnings of the QEMU Object Model. This is > basically > qdev generalized on steroids. > > This series includes the core infrastructure, a strawman Device type, and > the beginnings of the conversion of CharDrive

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On 07/25/2011 12:32 PM, Alexander Graf wrote: On 25.07.2011, at 10:51, Avi Kivity wrote: > qemu_malloc() is type-unsafe as it returns a void pointer. Introduce > QEMU_NEW() (and QEMU_NEWZ()), which return the correct type. What does this buy you over type *x = qemu_malloc(sizeof(type)); ?

Re: [Qemu-devel] [RESEND][PATCH v3] Generalize -machine command line option

Jan Kiszka writes: > On 2011-07-25 12:45, Richard W.M. Jones wrote: >> On Mon, Jul 25, 2011 at 12:33:01PM +0200, Jan Kiszka wrote: >>> On 2011-07-25 11:41, Richard W.M. Jones wrote: On Sat, Jul 23, 2011 at 12:38:37PM +0200, Jan Kiszka wrote: > From: Jan Kiszka > > -machine someh

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On 07/25/2011 02:02 PM, Markus Armbruster wrote: Side-stepping the stupid "OMG malloc(0) is weird, therefore we must make qemu_malloc(0) differently weird" controversy would be useful all by itself. If we all work together, we can make this thread even bigger than the tools/kvm pull request.

Re: [Qemu-devel] [RESEND][PATCH v3] Generalize -machine command line option

On 25 July 2011 11:45, Richard W.M. Jones wrote: > So what you're saying is we have to parse qemu -machine \? output by > looking for the string '(default)'?  eg: > > $ ./arm-softmmu/qemu-system-arm -machine \?|fgrep '(default)' > integratorcp ARM Integrator/CP (ARM926EJ-S) (default) For ARM you

Re: [Qemu-devel] [RESEND][PATCH v3] Generalize -machine command line option

On 2011-07-25 13:39, Markus Armbruster wrote: > Jan Kiszka writes: > >> On 2011-07-25 12:45, Richard W.M. Jones wrote: >>> On Mon, Jul 25, 2011 at 12:33:01PM +0200, Jan Kiszka wrote: On 2011-07-25 11:41, Richard W.M. Jones wrote: > On Sat, Jul 23, 2011 at 12:38:37PM +0200, Jan Kiszka wro

Re: [Qemu-devel] [RESEND][PATCH v3] Generalize -machine command line option

On 25 July 2011 12:48, Peter Maydell wrote: > For ARM you absolutely should not be relying on the default > machine type (not least because it's an incredibly ancient > dev board which nobody uses any more). An ARM kernel is > generally fairly specific to the hardware platform being > emulated, so

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On 07/25/2011 03:51 AM, Avi Kivity wrote: qemu_malloc() is type-unsafe as it returns a void pointer. Introduce QEMU_NEW() (and QEMU_NEWZ()), which return the correct type. Just use g_new() and g_new0() Regards, Anthony Liguori Signed-off-by: Avi Kivity --- This is part of my memory API p

Re: [Qemu-devel] [RESEND][PATCH v3] Generalize -machine command line option

On 2011-07-25 14:05, Peter Maydell wrote: > On 25 July 2011 12:48, Peter Maydell wrote: >> For ARM you absolutely should not be relying on the default >> machine type (not least because it's an incredibly ancient >> dev board which nobody uses any more). An ARM kernel is >> generally fairly specif

Re: [Qemu-devel] [Qemu-trivial] [PATCH] Makefile: fix out-of-tree builds

On 07/25/2011 05:15 AM, Stefan Hajnoczi wrote: On Thu, Jul 21, 2011 at 5:41 AM, Alexandre Raymond wrote: This patch fixes a minor bugs which prevented QEMU from being built out of tree. Signed-off-by: Alexandre Raymond --- Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-)

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On 07/25/2011 03:11 PM, Anthony Liguori wrote: On 07/25/2011 03:51 AM, Avi Kivity wrote: qemu_malloc() is type-unsafe as it returns a void pointer. Introduce QEMU_NEW() (and QEMU_NEWZ()), which return the correct type. Just use g_new() and g_new0() These bypass qemu_malloc(). Are we okay

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On 07/25/2011 06:11 AM, Alexander Graf wrote: #define QEMU_NEW_MULTI(type, len) ((type *)(qemu_mallocz(sizeof(type) * len))) char *arr = QEMU_NEW_MULTI(char, 1024); Still not covered: allocating a struct with a variable-size array as final member. I guess a solution for that can be found if

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On 07/25/2011 07:18 AM, Avi Kivity wrote: On 07/25/2011 03:11 PM, Anthony Liguori wrote: On 07/25/2011 03:51 AM, Avi Kivity wrote: qemu_malloc() is type-unsafe as it returns a void pointer. Introduce QEMU_NEW() (and QEMU_NEWZ()), which return the correct type. Just use g_new() and g_new0()

[Qemu-devel] [PATCH] Fix last sector write on sd card

When writing the last sector of an SD card using WRITE_MULTIPLE_BLOCK QEmu throws an error saying that we've run off the end, and leaves itself in the wrong state. Tested on ARM Vexpress model. Signed-off-by: Dr. David Alan Gilbert --- Don't throw address error on last block, and leave

Re: [Qemu-devel] [RESEND][PATCH v3] Generalize -machine command line option

On 25 July 2011 13:18, Jan Kiszka wrote: > On 2011-07-25 14:05, Peter Maydell wrote: >> In fact having thought about it a bit I'm going to go further >> and say that the whole idea of a "default machine" is a rather >> x86-centric idea -- most architectures don't really have a >> single machine ty

Re: [Qemu-devel] [RESEND][PATCH v3] Generalize -machine command line option

On 07/25/2011 05:59 AM, Jan Kiszka wrote: On 2011-07-25 12:45, Richard W.M. Jones wrote: That's an excuse, not a practical solution. We have to be able to work with any qemu. eg. the qemu in current Fedora Rawhide which supports only -machine accel=, or qemu in other distros which are also bra

Re: [Qemu-devel] [PATCH v1 1/1] Submit the codes for QEMU disk I/O limits.

On Mon, Jul 25, 2011 at 8:08 AM, Zhi Yong Wu wrote: > On Fri, Jul 22, 2011 at 6:54 PM, Stefan Hajnoczi wrote: >> On Fri, Jul 22, 2011 at 10:20 AM, Zhi Yong Wu >> wrote: >>> +    elapsed_time  = (real_time - bs->slice_start[is_write]) / 10.0; >>> +    fprintf(stderr, "real_time = %ld, sl

Re: [Qemu-devel] [RESEND][PATCH v3] Generalize -machine command line option

On 2011-07-25 14:22, Peter Maydell wrote: > On 25 July 2011 13:18, Jan Kiszka wrote: >> On 2011-07-25 14:05, Peter Maydell wrote: >>> In fact having thought about it a bit I'm going to go further >>> and say that the whole idea of a "default machine" is a rather >>> x86-centric idea -- most archit

Re: [Qemu-devel] [PATCH 01/55] blockdev: Make eject fail for non-removable drives even with -f

Looks good, Reviewed-by: Christoph Hellwig

Re: [Qemu-devel] [PATCH 02/55] block: Reset device model callbacks on detach

On Wed, Jul 20, 2011 at 06:23:36PM +0200, Markus Armbruster wrote: > BlockDriverState members change_cb and change_opaque are initially > null. The device model may set them, with bdrv_set_change_cb(). If > the device model gets detached (hot unplug), they're left dangling. > Only safe because de

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On 07/25/2011 04:52 AM, Avi Kivity wrote: On 07/25/2011 12:48 PM, Peter Maydell wrote: On 25 July 2011 10:32, Alexander Graf wrote: > On 25.07.2011, at 10:51, Avi Kivity wrote: >> qemu_malloc() is type-unsafe as it returns a void pointer. Introduce >> QEMU_NEW() (and QEMU_NEWZ()), which return t

Re: [Qemu-devel] [PATCH 04/55] block: Generalize change_cb() to BlockDevOps

On Wed, Jul 20, 2011 at 06:23:38PM +0200, Markus Armbruster wrote: > So we can more easily add device model callbacks. > > Signed-off-by: Markus Armbruster Looks good, Reviewed-by: Christoph Hellwig

Re: [Qemu-devel] [PATCH 05/55] block: Split change_cb() into change_media_cb(), resize_cb()

On Wed, Jul 20, 2011 at 06:23:39PM +0200, Markus Armbruster wrote: > Multiplexing callbacks complicates matters needlessly. Looks good, Reviewed-by: Christoph Hellwig

Re: [Qemu-devel] [PATCH 06/55] block/raw-win32: Drop disabled code for removable host devices

On Wed, Jul 20, 2011 at 06:23:40PM +0200, Markus Armbruster wrote: > It's been disabled since the start (commit 19cb3738, Aug 2006), and > has been untouched except for spelling fixes and such. I don't feel > like dragging it along any further. > > Signed-off-by: Markus Armbruster Ok, let's nuk

Re: [Qemu-devel] [PATCH 10/55] ide: Update command code definitions as per ACS-2 Table B.2

On Wed, Jul 20, 2011 at 06:23:44PM +0200, Markus Armbruster wrote: > Drop WIN_SRST, it has same value as WIN_DEVICE_RESET. > > CFA_IDLEIMMEDIATE isn't specific to CFATA. ACS-2 shows it as a > defined command in ATA-1, -2 and -3. Rename to WIN_IDLEIMMEDIATE2. > > Turn unused macros into comments

Re: [Qemu-devel] [PATCH 11/55] ide: Clean up case label indentation in ide_exec_cmd()

Looks good, Reviewed-by: Christoph Hellwig

Re: [Qemu-devel] [V4 Patch 3/4 - Updated]Qemu: Command "block_set" for dynamic block params change

On 07/25/2011 12:00 PM, Stefan Hajnoczi wrote: On Wed, Jul 13, 2011 at 06:37:05PM +0530, Supriya Kannery wrote: +ret = bdrv_open(bs, bs->filename, bdrv_flags, drv); +if (ret< 0) { +/* Reopen failed. Try to open with original flags */ +error_report("Opening file with ch

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On 07/25/2011 03:21 PM, Anthony Liguori wrote: On 07/25/2011 07:18 AM, Avi Kivity wrote: On 07/25/2011 03:11 PM, Anthony Liguori wrote: On 07/25/2011 03:51 AM, Avi Kivity wrote: qemu_malloc() is type-unsafe as it returns a void pointer. Introduce QEMU_NEW() (and QEMU_NEWZ()), which return the

Re: [Qemu-devel] [Qemu-trivial] [PATCH] Makefile: fix out-of-tree builds

On Mon, Jul 25, 2011 at 1:16 PM, Michael Roth wrote: > On 07/25/2011 05:15 AM, Stefan Hajnoczi wrote: >> >> On Thu, Jul 21, 2011 at 5:41 AM, Alexandre Raymond >>  wrote: >>> >>> This patch fixes a minor bugs which prevented QEMU from being built >>> out of tree. >>> >>> Signed-off-by: Alexandre Ra

Re: [Qemu-devel] [RESEND][PATCH v3] Generalize -machine command line option

On 25.07.2011, at 14:05, Peter Maydell wrote: > On 25 July 2011 12:48, Peter Maydell wrote: >> For ARM you absolutely should not be relying on the default >> machine type (not least because it's an incredibly ancient >> dev board which nobody uses any more). An ARM kernel is >> generally fairly

Re: [Qemu-devel] [RFC][PATCH 0/21] QEMU Object Model

On 07/25/2011 06:21 AM, Kevin Wolf wrote: Am 25.07.2011 03:44, schrieb Anthony Liguori: Hi, This series is the rough beginnings of the QEMU Object Model. This is basically qdev generalized on steroids. This series includes the core infrastructure, a strawman Device type, and the beginnings of

Re: [Qemu-devel] [RESEND][PATCH v3] Generalize -machine command line option

On 07/25/2011 07:44 AM, Alexander Graf wrote: On 25.07.2011, at 14:05, Peter Maydell wrote: On 25 July 2011 12:48, Peter Maydell wrote: For ARM you absolutely should not be relying on the default machine type (not least because it's an incredibly ancient dev board which nobody uses any more)

Re: [Qemu-devel] [RESEND][PATCH v3] Generalize -machine command line option

On Mon, Jul 25, 2011 at 07:47:51AM -0500, Anthony Liguori wrote: > On 07/25/2011 07:44 AM, Alexander Graf wrote: > > > >On 25.07.2011, at 14:05, Peter Maydell wrote: > > > >>On 25 July 2011 12:48, Peter Maydell wrote: > >>>For ARM you absolutely should not be relying on the default > >>>machine ty

Re: [Qemu-devel] [V4 Patch 3/4 - Updated]Qemu: Command "block_set" for dynamic block params change

On Mon, Jul 25, 2011 at 1:52 PM, Supriya Kannery wrote: > On 07/25/2011 12:00 PM, Stefan Hajnoczi wrote: >> >> On Wed, Jul 13, 2011 at 06:37:05PM +0530, Supriya Kannery wrote: >>> +    if (bdrv_is_inserted(bs)) { >>> +        /* Reopen file with changed set of flags */ >>> +        return bdrv_reo

Re: [Qemu-devel] [RESEND][PATCH v3] Generalize -machine command line option

On 25.07.2011, at 14:49, Richard W.M. Jones wrote: > On Mon, Jul 25, 2011 at 07:47:51AM -0500, Anthony Liguori wrote: >> On 07/25/2011 07:44 AM, Alexander Graf wrote: >>> >>> On 25.07.2011, at 14:05, Peter Maydell wrote: >>> On 25 July 2011 12:48, Peter Maydell wrote: > For ARM you ab

Re: [Qemu-devel] [RFC][PATCH 0/21] QEMU Object Model

Am 25.07.2011 14:45, schrieb Anthony Liguori: > On 07/25/2011 06:21 AM, Kevin Wolf wrote: >> Am 25.07.2011 03:44, schrieb Anthony Liguori: >>> Hi, >>> >>> This series is the rough beginnings of the QEMU Object Model. This is >>> basically >>> qdev generalized on steroids. >>> >>> This series incl

Re: [Qemu-devel] [RFC v5 86/86] 440fx: fix PAM, PCI holes

On 07/20/2011 11:50 AM, Avi Kivity wrote: The current implementation of PAM and the PCI holes is broken in several ways: - PCI BARs are not restricted to the PCI hole (a BAR may hide memory) Technically, a BAR can be mapped to any non-RAM memory location. - PCI devices do not respect P

Re: [Qemu-devel] [RFC][PATCH 0/21] QEMU Object Model

On 07/25/2011 08:08 AM, Kevin Wolf wrote: Am 25.07.2011 14:45, schrieb Anthony Liguori: Okay, if it isn't possible with reasonable effort, I guess we'll have to bite the bullet and give it a very careful manual review immediately before the merge. By the way, I see that you create new directorie

Re: [Qemu-devel] [RFC v5 86/86] 440fx: fix PAM, PCI holes

On 07/25/2011 04:07 PM, Anthony Liguori wrote: On 07/20/2011 11:50 AM, Avi Kivity wrote: The current implementation of PAM and the PCI holes is broken in several ways: - PCI BARs are not restricted to the PCI hole (a BAR may hide memory) Technically, a BAR can be mapped to any non-RAM memo

Re: [Qemu-devel] [RFC v5 86/86] 440fx: fix PAM, PCI holes

On Mon, Jul 25, 2011 at 04:14:45PM +0300, Avi Kivity wrote: > On 07/25/2011 04:07 PM, Anthony Liguori wrote: > >On 07/20/2011 11:50 AM, Avi Kivity wrote: > >>The current implementation of PAM and the PCI holes is broken in several > >>ways: > >> > >> - PCI BARs are not restricted to the PCI hole

Re: [Qemu-devel] [RFC v5 86/86] 440fx: fix PAM, PCI holes

On 07/25/2011 04:17 PM, Gleb Natapov wrote: On Mon, Jul 25, 2011 at 04:14:45PM +0300, Avi Kivity wrote: > On 07/25/2011 04:07 PM, Anthony Liguori wrote: > >On 07/20/2011 11:50 AM, Avi Kivity wrote: > >>The current implementation of PAM and the PCI holes is broken in several > >>ways: > >> >

Re: [Qemu-devel] [V4 Patch 3/4 - Updated]Qemu: Command "block_set" for dynamic block params change

Am 25.07.2011 14:50, schrieb Stefan Hajnoczi: > On Mon, Jul 25, 2011 at 1:52 PM, Supriya Kannery wrote: >> On 07/25/2011 12:00 PM, Stefan Hajnoczi wrote: >>> >>> On Wed, Jul 13, 2011 at 06:37:05PM +0530, Supriya Kannery wrote: +if (bdrv_is_inserted(bs)) { +/* Reopen file with

Re: [Qemu-devel] [RFC v5 86/86] 440fx: fix PAM, PCI holes

On Mon, Jul 25, 2011 at 04:28:12PM +0300, Avi Kivity wrote: > On 07/25/2011 04:17 PM, Gleb Natapov wrote: > >On Mon, Jul 25, 2011 at 04:14:45PM +0300, Avi Kivity wrote: > >> On 07/25/2011 04:07 PM, Anthony Liguori wrote: > >> >On 07/20/2011 11:50 AM, Avi Kivity wrote: > >> >>The current implemen

Re: [Qemu-devel] [RFC v5 86/86] 440fx: fix PAM, PCI holes

On 07/25/2011 04:28 PM, Avi Kivity wrote: On 07/25/2011 04:17 PM, Gleb Natapov wrote: On Mon, Jul 25, 2011 at 04:14:45PM +0300, Avi Kivity wrote: > On 07/25/2011 04:07 PM, Anthony Liguori wrote: > >On 07/20/2011 11:50 AM, Avi Kivity wrote: > >>The current implementation of PAM and the PCI holes

Re: [Qemu-devel] [RFC v5 86/86] 440fx: fix PAM, PCI holes

On 07/25/2011 08:28 AM, Avi Kivity wrote: On 07/25/2011 04:17 PM, Gleb Natapov wrote: On Mon, Jul 25, 2011 at 04:14:45PM +0300, Avi Kivity wrote: > On 07/25/2011 04:07 PM, Anthony Liguori wrote: > >On 07/20/2011 11:50 AM, Avi Kivity wrote: > >>The current implementation of PAM and the PCI holes

Re: [Qemu-devel] [RFC v5 86/86] 440fx: fix PAM, PCI holes

On Mon, Jul 25, 2011 at 04:31:27PM +0300, Avi Kivity wrote: > On 07/25/2011 04:28 PM, Avi Kivity wrote: > >On 07/25/2011 04:17 PM, Gleb Natapov wrote: > >>On Mon, Jul 25, 2011 at 04:14:45PM +0300, Avi Kivity wrote: > >>> On 07/25/2011 04:07 PM, Anthony Liguori wrote: > >>> >On 07/20/2011 11:50 AM,

Re: [Qemu-devel] [RFC v5 86/86] 440fx: fix PAM, PCI holes

On 07/25/2011 04:35 PM, Gleb Natapov wrote: > > That's the ISA TOM (15MB hole and friends). > Correct. What about: 3.2.19.DRB[0:7] DRAM ROW BOUNDARY REGISTERS from 440fx spec? Maybe. But we can't use that, since it ignores address line 31. (440fx supports only 1GB RAM, and we're ig

Re: [Qemu-devel] [RFC v5 86/86] 440fx: fix PAM, PCI holes

On 07/25/2011 08:38 AM, Avi Kivity wrote: On 07/25/2011 04:35 PM, Gleb Natapov wrote: > > That's the ISA TOM (15MB hole and friends). > Correct. What about: 3.2.19. DRB[0:7] DRAM ROW BOUNDARY REGISTERS from 440fx spec? Maybe. But we can't use that, since it ignores address line 31. (440fx s

Re: [Qemu-devel] [RFC v5 86/86] 440fx: fix PAM, PCI holes

On Mon, Jul 25, 2011 at 08:47:31AM -0500, Anthony Liguori wrote: > On 07/25/2011 08:38 AM, Avi Kivity wrote: > >On 07/25/2011 04:35 PM, Gleb Natapov wrote: > >>> > >>> That's the ISA TOM (15MB hole and friends). > >>> > >>Correct. What about: > >>3.2.19. DRB[0:7] DRAM ROW BOUNDARY REGISTERS > >> >

[Qemu-devel] 垃圾邮件通知信

Title: Spam Quarantine Notification Spam Quarantine Notification 下列邮件已被您的管理员作为可疑垃圾邮件阻止。 自您上一次收到垃圾邮件隔离区通知以来，您的电子邮件隔离区内已有 1 封新邮件。如果下列邮件是垃圾邮件，您不需要采取任何措施。邮件将于 7 天后自动从隔离区中移除。 如果下列任何邮件不是垃圾邮件，请单击“放行”链接以将其发送到您的收件箱。要查看所有隔离邮件，请查看 您的电子邮件隔离区。

Re: [Qemu-devel] [Qemu-trivial] [PATCH] Makefile: fix out-of-tree builds

On 07/25/2011 07:43 AM, Stefan Hajnoczi wrote: On Mon, Jul 25, 2011 at 1:16 PM, Michael Roth wrote: On 07/25/2011 05:15 AM, Stefan Hajnoczi wrote: On Thu, Jul 21, 2011 at 5:41 AM, Alexandre Raymond wrote: This patch fixes a minor bugs which prevented QEMU from being built out of tree. Si

[Qemu-devel] [PATCH 00/23] Memory API, batch 1

This patchset contains the core of the memory API, with one device (usb-ohci) coverted for reference. The API is currently implemented on top of the old ram_addr_t/cpu_register_physical_memory() API, but the plan is to make it standalone later. The goals of the API are: - correctness: by modelli

[Qemu-devel] [PATCH 02/23] memory: implement dirty tracking

Currently dirty tracking is implemented by passing through all calls to the underlying cpu_physical_memory_*() calls. Signed-off-by: Avi Kivity --- memory.c | 39 +++ memory.h |1 + 2 files changed, 32 insertions(+), 8 deletions(-) diff --git a/memory.c

[Qemu-devel] [PATCH 18/23] pc: convert pc_memory_init() to memory API

Signed-off-by: Avi Kivity --- hw/pc.c | 59 --- hw/pc.h |1 + 2 files changed, 41 insertions(+), 19 deletions(-) diff --git a/hw/pc.c b/hw/pc.c index 369566a..1c9d89a 100644 --- a/hw/pc.c +++ b/hw/pc.c @@ -41,6 +41,7 @@ #include "sys

[Qemu-devel] [PATCH 21/23] pci: add MemoryRegion based BAR management API

Allow registering a BAR using a MemoryRegion. Once all users are converted, pci_register_bar() and pci_register_bar_simple() will be removed. Signed-off-by: Avi Kivity --- hw/pci.c | 47 +++ hw/pci.h |3 +++ 2 files changed, 42 insertions(+), 8

[Qemu-devel] [PATCH 08/23] memory: I/O address space support

Allow registering I/O ports via the same mechanism as mmio ranges. Signed-off-by: Avi Kivity --- exec-memory.h |3 ++ memory.c | 60 - memory.h |2 + 3 files changed, 64 insertions(+), 1 deletions(-) diff --git a/exec-m

Re: [Qemu-devel] [RFC v5 86/86] 440fx: fix PAM, PCI holes

On 07/25/2011 04:47 PM, Anthony Liguori wrote: On 07/25/2011 08:38 AM, Avi Kivity wrote: On 07/25/2011 04:35 PM, Gleb Natapov wrote: > > That's the ISA TOM (15MB hole and friends). > Correct. What about: 3.2.19. DRB[0:7] DRAM ROW BOUNDARY REGISTERS from 440fx spec? Maybe. But we can't use t

Re: [Qemu-devel] [RFC v5 86/86] 440fx: fix PAM, PCI holes

On 07/25/2011 09:05 AM, Avi Kivity wrote: On 07/25/2011 04:47 PM, Anthony Liguori wrote: On 07/25/2011 08:38 AM, Avi Kivity wrote: On 07/25/2011 04:35 PM, Gleb Natapov wrote: > > That's the ISA TOM (15MB hole and friends). > Correct. What about: 3.2.19. DRB[0:7] DRAM ROW BOUNDARY REGISTERS fr

Re: [Qemu-devel] [RFC v5 86/86] 440fx: fix PAM, PCI holes

On 07/25/2011 05:08 PM, Anthony Liguori wrote: Why not use 3.5GB and call it a day? It's safer for memory hotplug, if we ever get it. The guest will never put a PCI BAR below that anyway. My entire concern is that they will. We're not just talking about Windows or Linux here, but any odd DOS

Re: [Qemu-devel] [PATCH 5/7] balloon: Separate out stat and balloon handling

Amit Shah writes: > On (Fri) 22 Jul 2011 [16:45:55], Markus Armbruster wrote: >> Amit Shah writes: >> >> > Passing on '0' as ballooning target to indicate retrieval of stats is >> > bad API. It also makes 'balloon 0' in the monitor cause a segfault. >> > Have two different functions handle the

Re: [Qemu-devel] [PATCH 0/7] balloon: cleanups, fix segfault

Amit Shah writes: > 'balloon 0' in the monitor causes a segfault. This happens because > the function that handles change in balloon values is also tasked with > handling stats retrieval from the guest, and it does the retrieval > when the balloon target is '0'. > > Silly API, replace it. Also

[Qemu-devel] [PATCH 17/23] pc: grab system_memory

While eventually this should come from the machine initialization function, take a short cut to avoid converting all machines now. Signed-off-by: Avi Kivity --- hw/pc.c |3 ++- hw/pc.h |4 +++- hw/pc_piix.c |8 +++- 3 files changed, 12 insertions(+), 3 deletions(-) dif

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On Mon, Jul 25, 2011 at 1:09 PM, Avi Kivity wrote: > On 07/25/2011 01:04 PM, Alexander Graf wrote: >> >> On 25.07.2011, at 12:02, Avi Kivity wrote: >> >> >  On 07/25/2011 12:56 PM, Alexander Graf wrote: >> >>  > >> >>  >   That argument can be used to block any change.  You'll get used to >> >> it

[Qemu-devel] [Request for Help] QEMU 0.15.0 change log

Hi, Hands down, 0.14.0 had the best change log of any QEMU release. A large part of the success of the change log was how many people participated in creating it. I'd love for us to go even further with 0.15.0. I've created a template to start with: http://wiki.qemu.org/ChangeLog/0.15 If

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On 07/25/2011 05:16 PM, Blue Swirl wrote: There is no escape. Don't make me destroy you. You cannot hide forever, Luke. Touché -- error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On Mon, Jul 25, 2011 at 3:21 PM, Anthony Liguori wrote: > On 07/25/2011 07:18 AM, Avi Kivity wrote: >> >> On 07/25/2011 03:11 PM, Anthony Liguori wrote: >>> >>> On 07/25/2011 03:51 AM, Avi Kivity wrote: qemu_malloc() is type-unsafe as it returns a void pointer. Introduce QEMU_NEW()

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On 07/25/2011 09:23 AM, Blue Swirl wrote: On Mon, Jul 25, 2011 at 3:21 PM, Anthony Liguori wrote: On 07/25/2011 07:18 AM, Avi Kivity wrote: On 07/25/2011 03:11 PM, Anthony Liguori wrote: On 07/25/2011 03:51 AM, Avi Kivity wrote: qemu_malloc() is type-unsafe as it returns a void pointer. I

[Qemu-devel] [PATCH 03/23] memory: merge adjacent segments of a single memory region

Simple implementations of memory routers, for example the Cirrus VGA memory banks or the 440FX PAM registers can generate adjacent memory regions which are contiguous. Detect these and merge them; this saves kvm memory slots and shortens lookup times. Signed-off-by: Avi Kivity --- memory.c |

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

>> qemu_malloc() is type-unsafe as it returns a void pointer. Introduce >> QEMU_NEW() (and QEMU_NEWZ()), which return the correct type. > > Just use g_new() and g_new0() > These bypass qemu_malloc(). Are we okay with that? >>> >>> Yes.  We can just make qemu_malloc use

[Qemu-devel] [PATCH 12/23] memory: separate building the final memory map into two steps

Instead of adding and deleting regions in one pass, do a delete pass followed by an add pass. This fixes the following case: from: 0x-0x0fff ram (a1) 0x1000-0x1fff mmio (a2) 0x2000-0x2fff ram (a3) to: 0x-0x2fff ram (b1) The single pass algorithm removed a1, added b2, then rem

[Qemu-devel] [PATCH 10/23] memory: add backward compatibility for old mmio registration

This eases the transition to the new API. Signed-off-by: Avi Kivity --- memory.c | 10 ++ memory.h | 10 ++ 2 files changed, 20 insertions(+), 0 deletions(-) diff --git a/memory.c b/memory.c index bb04952..e4446a0 100644 --- a/memory.c +++ b/memory.c @@ -14,6 +14,7 @@ #incl

Re: [Qemu-devel] [PATCH v2 1/2] qapi: check for python, allow path to be specified

On Sun, Jul 24, 2011 at 9:36 PM, Michael Roth wrote: > QAPI requires python to generate code. Check for python during > configuration and allow python to be specified manually. Now your patch is almost identical to mine. Maybe you missed it: http://lists.nongnu.org/archive/html/qemu-devel/2011-07

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On 07/25/2011 09:30 AM, Max Filippov wrote: qemu_malloc() is type-unsafe as it returns a void pointer. Introduce QEMU_NEW() (and QEMU_NEWZ()), which return the correct type. Just use g_new() and g_new0() These bypass qemu_malloc(). Are we okay with that? Yes. We can just make qemu_malloc

Re: [Qemu-devel] [Qemu-trivial] [PATCH] Makefile: fix out-of-tree builds

On Mon, Jul 25, 2011 at 2:57 PM, Michael Roth wrote: > On 07/25/2011 07:43 AM, Stefan Hajnoczi wrote: >> >> On Mon, Jul 25, 2011 at 1:16 PM, Michael Roth >>  wrote: >>> >>> On 07/25/2011 05:15 AM, Stefan Hajnoczi wrote: On Thu, Jul 21, 2011 at 5:41 AM, Alexandre Raymond  wrote:

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On Mon, 25 Jul 2011, Anthony Liguori wrote: > On 07/25/2011 09:30 AM, Max Filippov wrote: > > > > > > > > qemu_malloc() is type-unsafe as it returns a void pointer. > > > > > > > > Introduce > > > > > > > > QEMU_NEW() (and QEMU_NEWZ()), which return the correct type. > > > > > > > > > > > > > > J

[Qemu-devel] [PATCH 01/23] Hierarchical memory region API

The memory API separates the attributes of a memory region (its size, how reads or writes are handled, dirty logging, and coalescing) from where it is mapped and whether it is enabled. This allows a device to configure a memory region once, then hand it off to its parent bus to map it according to

[Qemu-devel] [PATCH 07/23] memory: late initialization of ram_addr

For non-RAM memory regions, we cannot tell whether this is an I/O region or an MMIO region. Since the qemu backing registration is different for the two, we have to defer initialization until we know which address space we are in. These shenanigans will be removed once the backing registration is

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On 07/25/2011 05:47 PM, malc wrote: Right right.. only g_new aborts on zero.. "If n_structs is 0 it returns NULL . " It's annoying that it takes this parameter at all, but I can live with it. -- error compiling com

[Qemu-devel] [PATCH 19/23] pc: move global memory map out of pc_init1() and into its callers

Signed-off-by: Avi Kivity --- hw/pc_piix.c | 15 --- 1 files changed, 8 insertions(+), 7 deletions(-) diff --git a/hw/pc_piix.c b/hw/pc_piix.c index d83854c..f2d0476 100644 --- a/hw/pc_piix.c +++ b/hw/pc_piix.c @@ -68,7 +68,8 @@ static void ioapic_init(IsaIrqState *isa_irq_state)

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On 07/25/2011 04:23 PM, Blue Swirl wrote: > Yes. We can just make qemu_malloc use g_malloc. It would be also possible to make g_malloc() use qemu_malloc(). That way we could keep the tracepoints which would lose their value with g_malloc() otherwise. qemu_malloc uses g_malloc => you keep tra

[Qemu-devel] Need to find OS running in VMs

Hi, how to find which OS running in my VMs..? If I can select the OS to deploy, which OS I can choose..? And how to deploy in KVM ? I need a simple os to do some samll processing, stiarge and computation which can run on KVM .. I’m using KVM hyper visor since I’m using open nebula to mana

Re: [Qemu-devel] [PATCH v2 1/2] qapi: check for python, allow path to be specified

On 07/25/2011 09:36 AM, Blue Swirl wrote: On Sun, Jul 24, 2011 at 9:36 PM, Michael Roth wrote: QAPI requires python to generate code. Check for python during configuration and allow python to be specified manually. Now your patch is almost identical to mine. Maybe you missed it: http://lists.

  1   2   3   >