[Qemu-devel] [PATCH] mips_malta: Detect format errors for function prom_set

Add the necessary gcc attribute and fix the detected errors. Cc: Aurelien Jarno Signed-off-by: Stefan Weil --- hw/mips_malta.c |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/hw/mips_malta.c b/hw/mips_malta.c index a458c97..deee273 100644 --- a/hw/mips_malta.c +++

[Qemu-devel] [PATCH] mips_fulong2e: Detect format errors for function prom_set

Add the necessary gcc attribute and fix the detected errors. Cc: Aurelien Jarno Signed-off-by: Stefan Weil --- hw/mips_fulong2e.c |8 +--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/hw/mips_fulong2e.c b/hw/mips_fulong2e.c index cbe7156..2ef5070 100644 --- a/hw/mips_f

[Qemu-devel] Re: [PATCH] Use a Linux-style MAINTAINERS file

On 09/10/2010 10:26 AM, Venkateswararao Jujjuri (JV) wrote: is the person who owns this set of files but rather, this person is willing to be helpful with this set of files. +vhost +M: Michael S. Tsirkin +S: Supported +F: hw/vhost* + +virtio-9p +M: JV Rao Please have my full name... Venka

[Qemu-devel] Re: [PATCH] Use a Linux-style MAINTAINERS file

On 9/10/2010 7:04 AM, Anthony Liguori wrote: On 09/10/2010 03:03 AM, Kevin Wolf wrote: -Project leaders: - +Please see the MAINTAINERS file in the Linux kernel for information about how +to update this file. Can't we just copy that one interesting section from Linux into this fi

[Qemu-devel] Re: [PATCH] Use a Linux-style MAINTAINERS file

On 09/10/2010 03:03 AM, Kevin Wolf wrote: -Project leaders: - +Please see the MAINTAINERS file in the Linux kernel for information about how +to update this file. Can't we just copy that one interesting section from Linux into this file? Sure, that makes sense. +Dev

[Qemu-devel] Re: [PATCH] Use a Linux-style MAINTAINERS file

On 09/10/2010 03:22 PM, Alexander Graf wrote: I was referring to the one below :). We usually use RPN in email. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.

[Qemu-devel] Re: [PATCH] Use a Linux-style MAINTAINERS file

Avi Kivity wrote: > On 09/10/2010 11:10 AM, Alexander Graf wrote: >> >>> KERNEL VIRTUAL MACHINE (KVM) FOR POWERPC >>> M: Alexander Graf mailto:ag...@suse.de>> >>> L: kvm-...@vger.kernel.org >>> W: http://kvm.qumranet.com >>> S: Supported >>> F: arch/

[Qemu-devel] Re: [PATCH] Use a Linux-style MAINTAINERS file

Hi Magnus, On 09/10/2010 03:25 AM, Magnus Damm wrote: On Fri, Sep 10, 2010 at 6:18 AM, Anthony Liguori wrote: SH4 - shix.c ? - r2d.c Magnus Damm +M: qemu-devel@nongnu.org +S: Orphan +F: target-sh4/ I don't mind having my name on the list.

[Qemu-devel] Re: [PATCH] Use a Linux-style MAINTAINERS file

On 09/10/2010 11:10 AM, Alexander Graf wrote: KERNEL VIRTUAL MACHINE (KVM) FOR POWERPC M: Alexander Graf mailto:ag...@suse.de>> L: kvm-...@vger.kernel.org W: http://kvm.qumranet.com S: Supported F: arch/powerpc/include/asm/kvm* F: arch/power

[Qemu-devel] Re: [PATCH] Use a Linux-style MAINTAINERS file

On Thu, 9 Sep 2010 16:18:37 -0500 Anthony Liguori wrote: > I make no claims that this is accurate or exhaustive but I think it's a > reasonable place to start. > > As the file mentions, the purpose of this file is to give contributors > information about who they can go to with questions about

[Qemu-devel] Re: [PATCH] Use a Linux-style MAINTAINERS file

On 10.09.2010, at 10:03, Kevin Wolf wrote: > Am 09.09.2010 23:18, schrieb Anthony Liguori: >> I make no claims that this is accurate or exhaustive but I think it's a >> reasonable place to start. >> >> As the file mentions, the purpose of this file is to give contributors >> information about wh

[Qemu-devel] Re: [PATCH] Use a Linux-style MAINTAINERS file

On 10.09.2010, at 10:19, Kevin Wolf wrote: > Am 10.09.2010 10:10, schrieb Alexander Graf: +IDE +M: qemu-devel@nongnu.org +S: Odd Fixes +F: hw/ide/ + +SCSI +M: Paul Brook mailto:p...@codesourcery.com>> +S: Odd Fixes +F: hw

[Qemu-devel] Re: [PATCH] Use a Linux-style MAINTAINERS file

Am 10.09.2010 10:10, schrieb Alexander Graf: >>> +IDE >>> +M: qemu-devel@nongnu.org >>> +S: Odd Fixes >>> +F: hw/ide/ >>> + >>> +SCSI >>> +M: Paul Brook mailto:p...@codesourcery.com>> >>> +S: Odd Fixes >>> +F: hw/lsi53c895a.c >>> +F: hw/scsi* >> >> In practice, virtio

[Qemu-devel] Re: [PATCH] Use a Linux-style MAINTAINERS file

On Fri, Sep 10, 2010 at 6:18 AM, Anthony Liguori wrote: >  SH4 > -  shix.c                  ? > -  r2d.c                   Magnus Damm > +M: qemu-devel@nongnu.org > +S: Orphan > +F: target-sh4/ I don't mind having my name on the list. I'd like to spend more time on improving SH support in QEMU.

[Qemu-devel] Re: [PATCH] Use a Linux-style MAINTAINERS file

Am 09.09.2010 23:18, schrieb Anthony Liguori: > I make no claims that this is accurate or exhaustive but I think it's a > reasonable place to start. > > As the file mentions, the purpose of this file is to give contributors > information about who they can go to with questions about a particular p

Re: [Qemu-devel] Re: [PATCH] [RFC] Add support for a USB audio device model

On 09/10/2010 07:47 PM, H. Peter Anvin wrote: > On 09/10/2010 06:08 PM, H. Peter Anvin wrote: >> >> Any remotely recent stock distro should have support for it. I say >> "should", because I haven't actually tested it with a Linux guest yet. >> >> I'll try to do that later; I have to leave now. >>

Re: [Qemu-devel] Re: [PATCH] [RFC] Add support for a USB audio device model

On 09/10/2010 06:08 PM, H. Peter Anvin wrote: > > Any remotely recent stock distro should have support for it. I say > "should", because I haven't actually tested it with a Linux guest yet. > > I'll try to do that later; I have to leave now. > Just tested it on a stock Fedora 13 64 bit VM; it

[Qemu-devel] [PATCH 2/2] PPC: Redesign interrupt trigger path

According to the Book3S spec, the interrupt context starts with an MSR value that is rather simple. If we leave out the HV case, it's almost always 0. To reflect this, let's redesign the way that MSR value gets calculated. Using this, we also squash the bug where MSR_POW can slip through into the

[Qemu-devel] Re: [PATCH] [RFC] Add support for a USB audio device model

On 09/10/2010 05:28 PM, malc wrote: > On Fri, 10 Sep 2010, H. Peter Anvin wrote: > >> I discovered that none of the audio device models supported by current >> Qemu/KVM appear to be supported out of the box on Win7 64 bit (AC97 >> works fine on 32 bit). The most logical ways to fix that would be

[Qemu-devel] [PATCH 0/2] PowerPC fixes

There goes another round of PowerPC fixes. Originally this should only have been a fix for the MSR_POW issue (bug 608107), but I also stumbed over recent Linux kernels not booting in qemu-system-ppc64. So a fix for that is also included. With this new logic I didn't really took care of all HV corn

[Qemu-devel] [PATCH 1/2] PPC: Enable hint bits for lwarx/ldarx

The lwarx and ldarx instructions have a bit to give some hint to the CPU which is safe to ignore. We currently refuse to accept any instruction with that bit set, as it used to be declared MBZ. Let's remove the reserved bit and make the instruction work as expected. This fixes Linux boot for ppc64

[Qemu-devel] Re: [PATCH] [RFC] Add support for a USB audio device model

On Fri, 10 Sep 2010, H. Peter Anvin wrote: > I discovered that none of the audio device models supported by current > Qemu/KVM appear to be supported out of the box on Win7 64 bit (AC97 > works fine on 32 bit). The most logical ways to fix that would be to > add a long-term supportable audio devi

[Qemu-devel] Issue with compiling qemu-0.13.0.-rc1

When I try to run the following commands on rc1 or fresh git (synced 5 minutes back), I get the following error: bash-3.2$ ./configure --disable-kvm --disable-xen bash-3.2$ make Makefile:24: no file name for `-include' make-3.79.1-p7[1]: *** No rule to make target `loader.o', needed by `all'. Sto

Re: [Qemu-devel] Re: [RFC] qed: Add QEMU Enhanced Disk format

On 09/06/2010 05:45 AM, Anthony Liguori wrote: >> >> Before inventing yet another image format, you certainly have checked >> the existing ones. > > Obviously, yes. > > Here are the issues: > > cow.c: it's cow of an otherwise sparse file. An important reason for > implementing a format is the

Re: [Qemu-devel] [PATCH] target-ppc: clear MSR_POW on interrupt

On 10.09.2010, at 18:58, Thomas Monjalon wrote: > Alexander Graf wrote: >> Am 10.09.2010 um 18:08 schrieb "Edgar E. Iglesias" > : >>> On Fri, Sep 10, 2010 at 05:50:27PM +0200, Alexander Graf wrote: Thomas Monjalon wrote: > Alexander Graf wrote: >> Thomas Monjalon wrote: >>> Alex

Re: [Qemu-devel] Re: [PATCH] Use a Linux-style MAINTAINERS file

On 10.09.2010, at 21:05, Anthony Liguori wrote: > On 09/10/2010 12:45 PM, Blue Swirl wrote: > >> How about also listing the ROMs under pc-bios? I'd claim openbios-*, >> except if Alex wants openbios-ppc, that's fine too. >> > > Yes, that's a good idea. I'd actually like to keep the ownersh

[Qemu-devel] [PATCH] [RFC] Add support for a USB audio device model

I discovered that none of the audio device models supported by current Qemu/KVM appear to be supported out of the box on Win7 64 bit (AC97 works fine on 32 bit). The most logical ways to fix that would be to add a long-term supportable audio device model. Intel HD Audio and USB Audio seemed like

[Qemu-devel] [PATCH 06/15] Use range_covers_byte

Use range_covers_byte() instead of comparisons. This avoids some warnings with GCC flag -Wtype-limits. Signed-off-by: Blue Swirl --- hw/omap1.c | 14 -- hw/sm501.c |5 +++-- 2 files changed, 11 insertions(+), 8 deletions(-) diff --git a/hw/omap1.c b/hw/omap1.c index 1ee5514..

[Qemu-devel] [PATCH 13/15] Use a few more gcc warning flags

If the compiler supports the following warning flags, use them: -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wmissing-include-dirs -Wclobbered Currently, these flags don't produce any warnings. Signed-off-by: Blue Swirl --- configure |5 - 1 files changed, 4 inserti

Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format

Stefan Hajnoczi wrote: > Since there is no ordering imposed between the data write and metadata > update, the following scenarios may occur on crash: > 1. Neither data write nor metadata update reach the disk. This is > fine, qed metadata has not been corrupted. > 2. Data reaches disk but metadata

[Qemu-devel] [PATCH 10/15] MIPS: fix yield handling

The parameter for yield should be handled as a signed integer for the comparisons to have any effect. This also avoids a gcc warning with -Wtype-limits. Signed-off-by: Blue Swirl --- target-mips/op_helper.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/target-mips/

[Qemu-devel] [PATCH 15/15] Use gcc warning flag -Wnested-externs

If the compiler supports the warning flag -Wnested-externs, use it. Avoid the only warning by moving the declaration of xml_builtin to a more proper place. Signed-off-by: Blue Swirl --- configure |2 +- feature_to_c.sh |1 - gdbstub.c |1 - gdbstub.h |3 +++ 4

[Qemu-devel] [PATCH 08/15] blkdebug: fix enum comparison

The signedness of enum types depend on the compiler implementation. Therefore the check for negative values may or may not be meaningful. Fix by explicitly casting to a signed integer. Since the values are also checked earlier against event_names table, this is an internal error. Change the 'if'

[Qemu-devel] [PATCH 12/15] Use gcc warning flag -Wtype-limits

If the compiler supports the warning flag -Wtype-limits, use it. Signed-off-by: Blue Swirl --- configure |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/configure b/configure index 4061cb7..29d3548 100755 --- a/configure +++ b/configure @@ -138,7 +138,7 @@ QEMU_CFLAGS="

[Qemu-devel] [PATCH 11/15] pxa2xx: fix SSSR TFN logic

Fix SSSR TFN logic: TX FIFO is never filled, so it is always in underrun condition if SSP is enabled. This also avoids a gcc warning with -Wtype-limits. Signed-off-by: Blue Swirl --- hw/pxa2xx.c |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/hw/pxa2xx.c b/hw/pxa

[Qemu-devel] [PATCH 07/15] pxa2xx: remove useless checks

Remove checks which were made useless by r5849, 8da3ff180974732fc4272cb4433fef85c1822961. This also avoids a warning with GCC flag -Wtype-limits. Signed-off-by: Blue Swirl --- hw/pxa2xx.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/hw/pxa2xx.c b/hw/pxa2xx.c index 2

[Qemu-devel] [PATCH 14/15] Use gcc warning flag -Wempty-body

If the compiler supports the warning flag -Wempty-body, use it. Adjust the code to avoid the warnings. Signed-off-by: Blue Swirl --- configure |2 +- hw/omap_i2c.c |5 +++-- hw/omap_mmc.c |5 +++-- hw/pxa2xx.c |5 +++-- hw/soc_dma.c |5 +++-- targe

[Qemu-devel] [PATCH 09/15] PPC: Suppress gcc warnings with -Wtype-limits

The hack added by c5b76b381081680633e2e0a91216507430409fb2 was not enough to avoid warnings with gcc flag -Wtype-limits. Add a new macro to fix both problems. Signed-off-by: Blue Swirl --- target-ppc/op_helper.c | 50 1 files changed, 25 inserti

[Qemu-devel] [PATCH 03/15] linux-user: fix types in a comparison

-1ul is unsigned long, which does not necessarily match abi_ulong type. Fix by using abi_long instead. This also avoids a warning with GCC flag -Wtype-limits. Signed-off-by: Blue Swirl --- linux-user/mmap.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/linux-user/mm

[Qemu-devel] [PATCH 04/15] linux-user: improve flatload error checking

Because of the use of unsigned type, possible errors during load were ignored. Fix by using a signed type. This also avoids a warning with GCC flag -Wtype-limits. Signed-off-by: Blue Swirl --- linux-user/flatload.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/linu

[Qemu-devel] [PATCH 05/15] Introduce range.h

Extract range functions from pci.h. These will be used by later patches by non-PCI devices. Adjust current users. Signed-off-by: Blue Swirl --- hw/acpi_piix4.c |1 + hw/msix.c |1 + hw/pci.c|1 + hw/pci.h| 29 - hw/piix_pci.c |

[Qemu-devel] [PATCH 02/15] linux-user: fix socklen_t comparisons

On many systems, socklen_t is defined as unsigned. This means that checks for negative values are not meaningful. Fix by explicitly casting to a signed integer. This also avoids some warnings with GCC flag -Wtype-limits. Signed-off-by: Blue Swirl --- linux-user/syscall.c | 20 +--

[Qemu-devel] [PATCH 01/15] Check for errors during BIOS or kernel load

Because of the use of unsigned types, possible errors during BIOS or kernel load were ignored. Fix by using a signed type. This also avoids some warnings with GCC flag -Wtype-limits. Signed-off-by: Blue Swirl --- hw/mips_fulong2e.c |2 +- hw/ppc405_boards.c | 23 +--

[Qemu-devel] [PATCH v3 00/15] GCC warning flags

I updated the descriptions and cleaned up 6/16. Blue Swirl (15): Check for errors during BIOS or kernel load linux-user: fix socklen_t comparisons linux-user: fix types in a comparison linux-user: improve flatload error checking Introduce range.h Use range_covers_byte pxa2xx: remove

Re: [Qemu-devel] Re: [PATCH] Use a Linux-style MAINTAINERS file

Am 10.09.2010 um 21:19 schrieb Blue Swirl: On Fri, Sep 10, 2010 at 7:05 PM, Anthony Liguori > wrote: On 09/10/2010 12:45 PM, Blue Swirl wrote: On Thu, Sep 9, 2010 at 9:18 PM, Anthony Liguori wrote: diff --git a/MAINTAINERS b/MAINTAINERS index 79dfc7f..3894cd8 100644 --- a/MAINTAINERS +++ b/

Re: [Qemu-devel] [PATCH] target-ppc: clear MSR_POW on interrupt

On Fri, Sep 10, 2010 at 06:58:10PM +0200, Thomas Monjalon wrote: > Alexander Graf wrote: > > Am 10.09.2010 um 18:08 schrieb "Edgar E. Iglesias" > : > > > On Fri, Sep 10, 2010 at 05:50:27PM +0200, Alexander Graf wrote: > > >> Thomas Monjalon wrote: > > >>> Alexander Graf wrote: > > Thomas Monj

Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format

On 09/10/2010 12:42 PM, Kevin Wolf wrote: It bounces all buffers still and I still think it's synchronous (although Kevin would know better). Yes, it does bounce the buffers, though I'm looking into this anyway because you raised concerns about unbounded allocations. (And it has been on my

Re: [Qemu-devel] Re: [PATCH] Use a Linux-style MAINTAINERS file

On Fri, Sep 10, 2010 at 7:05 PM, Anthony Liguori wrote: > On 09/10/2010 12:45 PM, Blue Swirl wrote: >> >> On Thu, Sep 9, 2010 at 9:18 PM, Anthony Liguori >>  wrote: >> >>> >>> I make no claims that this is accurate or exhaustive but I think it's a >>> reasonable place to start. >>> >>> As the file

Re: [Qemu-devel] Re: [PATCH] Use a Linux-style MAINTAINERS file

On 09/10/2010 12:45 PM, Blue Swirl wrote: On Thu, Sep 9, 2010 at 9:18 PM, Anthony Liguori wrote: I make no claims that this is accurate or exhaustive but I think it's a reasonable place to start. As the file mentions, the purpose of this file is to give contributors information about who t

Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format

On Fri, Sep 10, 2010 at 2:10 PM, Anthony Liguori wrote: >> >> Well, snapshots have an ID today (which is different from their name). >> Nobody stops you from putting a UUID there. Fully backwards compatible, >> no feature flag needed. I think Miguel was planning to actually do this. >> > > The pro

[Qemu-devel] Re: [PATCH] Use a Linux-style MAINTAINERS file

On Thu, Sep 9, 2010 at 9:18 PM, Anthony Liguori wrote: > I make no claims that this is accurate or exhaustive but I think it's a > reasonable place to start. > > As the file mentions, the purpose of this file is to give contributors > information about who they can go to with questions about a par

Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format

Am 10.09.2010 19:10, schrieb Anthony Liguori: > On 09/10/2010 11:05 AM, Kevin Wolf wrote: >> Am 10.09.2010 17:53, schrieb Anthony Liguori: >> >>> On 09/10/2010 10:18 AM, Kevin Wolf wrote: >>> Am 10.09.2010 17:02, schrieb Anthony Liguori: > What makes us future p

Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format

Am 10.09.2010 19:07, schrieb Anthony Liguori: Sure, we'll support qcow2, but will we give it the same attention? >>> >>> We have a lot of block formats in QEMU today but only one block >>> format that actually performs well and has good data integrity. >>> >>> We're not giving qcow2 the atten

[Qemu-devel] Re: [PATCH 1/1] Avoid compiler error when building block/blkdebug.c with -Wtype-limits

On 09/10/10 19:05, Blue Swirl wrote: > On Fri, Sep 10, 2010 at 2:04 PM, wrote: >> From: Jes Sorensen >> >> Signed-off-by: Jes Sorensen >> --- >> block/blkdebug.c |7 ++- >> 1 files changed, 6 insertions(+), 1 deletions(-) >> >> diff --git a/block/blkdebug.c b/block/blkdebug.c >> index

Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format

On 09/10/2010 11:05 AM, Kevin Wolf wrote: Am 10.09.2010 17:53, schrieb Anthony Liguori: On 09/10/2010 10:18 AM, Kevin Wolf wrote: Am 10.09.2010 17:02, schrieb Anthony Liguori: What makes us future proof is having a good feature support. qcow2 doesn't have this. We have a g

Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format

On 09/10/2010 10:49 AM, Avi Kivity wrote: If I do a qemu-img create -f qcow2 foo.img 10GB, and then do a naive copy of the image file and end up with a 2GB image when there's nothing in it, that's badness. Only if you crash in the middle. If not, you free the preallocation during shutdown

[Qemu-devel] Re: [PATCH 1/1] Avoid compiler error when building block/blkdebug.c with -Wtype-limits

On Fri, Sep 10, 2010 at 2:04 PM, wrote: > From: Jes Sorensen > > Signed-off-by: Jes Sorensen > --- >  block/blkdebug.c |    7 ++- >  1 files changed, 6 insertions(+), 1 deletions(-) > > diff --git a/block/blkdebug.c b/block/blkdebug.c > index 2a63df9..17d796d 100644 > --- a/block/blkdebug.c

Re: [Qemu-devel] [PATCH] target-ppc: clear MSR_POW on interrupt

Alexander Graf wrote: > Am 10.09.2010 um 18:08 schrieb "Edgar E. Iglesias" : > > On Fri, Sep 10, 2010 at 05:50:27PM +0200, Alexander Graf wrote: > >> Thomas Monjalon wrote: > >>> Alexander Graf wrote: > Thomas Monjalon wrote: > > Alexander Graf wrote: > >> Thomas Monjalon wrote: > >>>

Re: [Qemu-devel] [PATCH] target-ppc: clear MSR_POW on interrupt

Am 10.09.2010 um 18:08 schrieb "Edgar E. Iglesias" : > On Fri, Sep 10, 2010 at 05:50:27PM +0200, Alexander Graf wrote: >> Thomas Monjalon wrote: >>> Alexander Graf wrote: >>> Thomas Monjalon wrote: > Alexander Graf wrote: > >> Thomas Monjalon wrote: >> >>> From:

Re: [Qemu-devel] [PATCH] target-ppc: clear MSR_POW on interrupt

On Fri, Sep 10, 2010 at 05:50:27PM +0200, Alexander Graf wrote: > Thomas Monjalon wrote: > > Alexander Graf wrote: > > > >> Thomas Monjalon wrote: > >> > >>> Alexander Graf wrote: > >>> > Thomas Monjalon wrote: > > > From: till <608...@bugs.launchpad.net> > >>>

Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format

Am 10.09.2010 17:53, schrieb Anthony Liguori: > On 09/10/2010 10:18 AM, Kevin Wolf wrote: >> Am 10.09.2010 17:02, schrieb Anthony Liguori: >> >>> What makes us future proof is having a good feature support. qcow2 >>> doesn't have this. We have a good way at making purely informational >>> cha

Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format

On 09/10/2010 10:18 AM, Kevin Wolf wrote: Am 10.09.2010 17:02, schrieb Anthony Liguori: What makes us future proof is having a good feature support. qcow2 doesn't have this. We have a good way at making purely informational changes and also making changes that break the format. Those feat

Re: [Qemu-devel] [PATCH] target-ppc: clear MSR_POW on interrupt

Thomas Monjalon wrote: > Alexander Graf wrote: > >> Thomas Monjalon wrote: >> >>> Alexander Graf wrote: >>> Thomas Monjalon wrote: > From: till <608...@bugs.launchpad.net> > > According to FreeScale's 'Programming Environments Manual for 32-bit > Im

Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format

On 09/10/2010 05:56 PM, Anthony Liguori wrote: On 09/10/2010 08:47 AM, Avi Kivity wrote: The current qcow2 implementation, yes. The qcow2 format, no. The qcow2 format has more writes because it maintains more meta data. More writes == worse performance. You claim that you can effectively

Re: [Qemu-devel] [PATCH] target-ppc: clear MSR_POW on interrupt

Alexander Graf wrote: > Thomas Monjalon wrote: > > Alexander Graf wrote: > >> Thomas Monjalon wrote: > >>> From: till <608...@bugs.launchpad.net> > >>> > >>> According to FreeScale's 'Programming Environments Manual for 32-bit > >>> Implementations of the PowerPC Architecture' [MPCFPE32B, Rev.3, >

[Qemu-devel] [PATCH 0/2] Add SVM feature flags to qemu

Hi again, this is the new version of the patches that add the SVM feature flags to qemu. I rebased the patches to qemu.git. These patches are required to let the guests see the svm flag and additional svm features like nested paging as well. Please have a look at them and let me knwo your opinion

[Qemu-devel] [PATCH 1/2] qemu-kvm: Set cpuid definition to 0 before initializing it

This patch cleans the (stack-allocated) cpuid definition to 0 before actually initializing it. Signed-off-by: Joerg Roedel --- target-i386/cpuid.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/target-i386/cpuid.c b/target-i386/cpuid.c index 04ba8d5..3fcf78f 100644 ---

[Qemu-devel] [PATCH 2/2] qemu-kvm: Add svm cpuid features

This patch adds the svm cpuid feature flags to the qemu intialization path. Signed-off-by: Joerg Roedel --- target-i386/cpu.h | 12 +++ target-i386/cpuid.c | 80 --- target-i386/kvm.c |3 ++ 3 files changed, 78 insertions(+), 17 del

Re: [Qemu-devel] [PATCH] target-ppc: clear MSR_POW on interrupt

Thomas Monjalon wrote: > Alexander Graf wrote: > >> Thomas Monjalon wrote: >> >>> From: till <608...@bugs.launchpad.net> >>> >>> According to FreeScale's 'Programming Environments Manual for 32-bit >>> Implementations of the PowerPC Architecture' [MPCFPE32B, Rev.3, 9/2005], >>> section 6.5,

Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format

Am 10.09.2010 17:02, schrieb Anthony Liguori: > What makes us future proof is having a good feature support. qcow2 > doesn't have this. We have a good way at making purely informational > changes and also making changes that break the format. Those features > are independent so they can be ba

Re: [Qemu-devel] [PATCH] target-ppc: clear MSR_POW on interrupt

Alexander Graf wrote: > Thomas Monjalon wrote: > > From: till <608...@bugs.launchpad.net> > > > > According to FreeScale's 'Programming Environments Manual for 32-bit > > Implementations of the PowerPC Architecture' [MPCFPE32B, Rev.3, 9/2005], > > section 6.5, table 6-7, an interrupt resets MSR_PO

Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format

On 09/10/2010 08:48 AM, Christoph Hellwig wrote: On Fri, Sep 10, 2010 at 08:22:14AM -0500, Anthony Liguori wrote: fsck will always be fast on qed because the metadata is small. For a 1PB image, there's 128MB worth of L2s if it's fully allocated (keeping in mind, that once you're fully alloc

Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format

On 09/10/2010 08:47 AM, Avi Kivity wrote: The current qcow2 implementation, yes. The qcow2 format, no. The qcow2 format has more writes because it maintains more meta data. More writes == worse performance. You claim that you can effectively batch those writes such that the worse performa

Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format

On 09/10/2010 05:12 PM, Christoph Hellwig wrote: On Fri, Sep 10, 2010 at 05:05:16PM +0300, Avi Kivity wrote: Note that ATA allows simply ignoring TRIM requests that we can't handle, and if we don't set the bit that guarantees TRIMed regions to be zeroed we don't even have to zero out the region

Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format

On Fri, Sep 10, 2010 at 05:05:16PM +0300, Avi Kivity wrote: > >Note that ATA allows simply ignoring TRIM requests that we can't handle, > >and if we don't set the bit that guarantees TRIMed regions to be zeroed > >we don't even have to zero out the regions. > > It would be nice to support it. TRI

Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format

On 09/10/2010 04:16 PM, Anthony Liguori wrote: btw, despite being not properly designed, qcow2 is able to support TRIM. qed isn't able to, except by leaking clusters on shutdown. TRIM support is required unless you're okay with the image growing until it is no longer sparse (the lack of TRIM

Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format

On 09/10/2010 04:47 PM, Christoph Hellwig wrote: On Fri, Sep 10, 2010 at 12:33:09PM +0100, Stefan Hajnoczi wrote: btw, despite being not properly designed, qcow2 is able to support TRIM. ?qed isn't able to, except by leaking clusters on shutdown. ?TRIM support is required unless you're okay wit

[Qemu-devel] [PATCH 1/1] Avoid compiler error when building block/blkdebug.c with -Wtype-limits

From: Jes Sorensen Signed-off-by: Jes Sorensen --- block/blkdebug.c |7 ++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/block/blkdebug.c b/block/blkdebug.c index 2a63df9..17d796d 100644 --- a/block/blkdebug.c +++ b/block/blkdebug.c @@ -439,7 +439,12 @@ static void blk

[Qemu-devel] [PATCH 0/1] Avoid compiler error when building block/blkdebug.c with -Wtype-limits

From: Jes Sorensen Hi, Back to the earlier discussion about building with -Wtype-limits. This fixes the problem with block/blkdebug.c where it tries to compare an enum against < 0. I looked at a couple of ways to do this, but I think this is the least intrusive. Let me know what you think. Tha

Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format

On 09/10/2010 04:22 PM, Anthony Liguori wrote: Looks like it depends on fsck, which is not a good idea for large images. fsck will always be fast on qed because the metadata is small. For a 1PB image, there's 128MB worth of L2s if it's fully allocated It's 32,000 seeks. (keeping in mind,

Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format

On 09/10/2010 04:39 PM, Anthony Liguori wrote: On 09/10/2010 07:47 AM, Avi Kivity wrote: Then, with a clean base that takes on board the lessons of existing formats it is much easier to innovate. Look at the image streaming, defragmentation, and trim ideas that are playing out right now. I th

Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format

On Fri, Sep 10, 2010 at 08:22:14AM -0500, Anthony Liguori wrote: > fsck will always be fast on qed because the metadata is small. For a > 1PB image, there's 128MB worth of L2s if it's fully allocated (keeping > in mind, that once you're fully allocated, you'll never fsck again). If > you've go

Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format

On Fri, Sep 10, 2010 at 08:39:21AM -0500, Anthony Liguori wrote: > You're hand waving to a dangerous degree here :-) > > TRIM in qcow2 would require the following sequence: > > 1) remove cluster from L2 table > 2) sync() > 3) reduce cluster reference count > 4) sync() > > TRIM needs to be fast s

Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format

Am 10.09.2010 14:35, schrieb Stefan Hajnoczi: > On Fri, Sep 10, 2010 at 1:12 PM, Kevin Wolf wrote: >> Am 10.09.2010 13:43, schrieb Stefan Hajnoczi: >>> By creating two code paths within qcow2. >> >> You're creating two code paths for users. > > No, I'm creating a single path: Q

Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format

On 09/10/2010 04:14 PM, Anthony Liguori wrote: On 09/10/2010 06:14 AM, Avi Kivity wrote: The point of an image format is not to recreate btrfs in software. It's to provide a mechanism to allow users to move images around reasonable but once an image is present on a reasonable filesystem, w

Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format

On Fri, Sep 10, 2010 at 12:33:09PM +0100, Stefan Hajnoczi wrote: > > btw, despite being not properly designed, qcow2 is able to support TRIM. > > ?qed isn't able to, except by leaking clusters on shutdown. ?TRIM support is > > required unless you're okay with the image growing until it is no longer

Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format

On 09/10/2010 07:47 AM, Avi Kivity wrote: Then, with a clean base that takes on board the lessons of existing formats it is much easier to innovate. Look at the image streaming, defragmentation, and trim ideas that are playing out right now. I think the reason we haven't seen them before is bec

Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format

On 09/10/2010 07:06 AM, Avi Kivity wrote: On 09/10/2010 02:43 PM, Stefan Hajnoczi wrote: and/or enterprise storage. That doesn't eliminate undiscovered errors (they can still come from the transport). Eliminating silent data corruption is currently not a goal for any disk image format I kn

Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format

On 09/10/2010 06:43 AM, Avi Kivity wrote: On 09/10/2010 02:33 PM, Stefan Hajnoczi wrote: btw, despite being not properly designed, qcow2 is able to support TRIM. qed isn't able to, except by leaking clusters on shutdown. TRIM support is required unless you're okay with the image growing u

Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format

On 09/10/2010 04:10 PM, Stefan Hajnoczi wrote: On Fri, Sep 10, 2010 at 1:47 PM, Avi Kivity wrote: On 09/10/2010 03:35 PM, Stefan Hajnoczi wrote: That still leaves those qcow2 images that use features not supported by qed. Just a few features missing in qed are internal snapshots, qcow2 on b

Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format

On 09/10/2010 06:25 AM, Avi Kivity wrote: On 09/10/2010 02:14 PM, Avi Kivity wrote: qcow2 is not a properly designed image format. It was a weekend hacking session from Fabrice that he dropped in the code base and never really finished doing what he originally intended. The improvements

Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format

On 09/10/2010 06:14 AM, Avi Kivity wrote: The point of an image format is not to recreate btrfs in software. It's to provide a mechanism to allow users to move images around reasonable but once an image is present on a reasonable filesystem, we should more or less get the heck out of the way

Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format

On Fri, Sep 10, 2010 at 1:47 PM, Avi Kivity wrote: >  On 09/10/2010 03:35 PM, Stefan Hajnoczi wrote: >> >>> That still leaves those qcow2 images that use features not supported by >>> qed. Just a few features missing in qed are internal snapshots, qcow2 on >>> block devices, compression, encryptio

Re: [Qemu-devel] [PATCH] target-ppc: clear MSR_POW on interrupt

Thomas Monjalon wrote: > From: till <608...@bugs.launchpad.net> > > According to FreeScale's 'Programming Environments Manual for 32-bit > Implementations of the PowerPC Architecture' [MPCFPE32B, Rev.3, 9/2005], > section 6.5, table 6-7, an interrupt resets MSR_POW to zero but qemu-0.12.4 > fails t

Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format

On 09/10/2010 03:35 PM, Stefan Hajnoczi wrote: That still leaves those qcow2 images that use features not supported by qed. Just a few features missing in qed are internal snapshots, qcow2 on block devices, compression, encryption. So qed can't be a complete replacement for qcow2 (and that was

[Qemu-devel] Tracing TranslationBlocks to file

Hello! I am trying to modify Qemu to trace the executed BasicBlocks and their lengths to a file. The host platform is x86_64, quest is arm-softmmu. Currently I am passing the current TranslationBlock from gen_intermediate_code_internal() to disas_arm_insn() in "target-arm/translate.c". The T

Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format

On Fri, Sep 10, 2010 at 1:12 PM, Kevin Wolf wrote: > Am 10.09.2010 13:43, schrieb Stefan Hajnoczi: >> By creating two code paths within qcow2. > > You're creating two code paths for users. No, I'm creating a single path: QED. There are already two code paths: raw an

[Qemu-devel] [PATCH] target-ppc: clear MSR_POW on interrupt

From: till <608...@bugs.launchpad.net> According to FreeScale's 'Programming Environments Manual for 32-bit Implementations of the PowerPC Architecture' [MPCFPE32B, Rev.3, 9/2005], section 6.5, table 6-7, an interrupt resets MSR_POW to zero but qemu-0.12.4 fails to do so. Resetting the bit is nece

Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format

Am 10.09.2010 13:43, schrieb Stefan Hajnoczi: > By creating two code paths within qcow2. You're creating two code paths for users. >>> >>> No, I'm creating a single path: QED. >>> >>> There are already two code paths: raw and qcow2. qcow2 has had such a bad >>> history that for a lot

Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format

On 09/10/2010 02:43 PM, Stefan Hajnoczi wrote: and/or enterprise storage. That doesn't eliminate undiscovered errors (they can still come from the transport). Eliminating silent data corruption is currently not a goal for any disk image format I know of. For filesystems, I know that ZFS and

  1   2   >