Stefan Weil writes:
> Am 16.07.2010 09:04, schrieb Markus Armbruster:
>> Stefan Weil writes:
>>
>>
>>> An empty environment is sometimes useful in user mode.
>>> The new option provides it for linux-user and bsd-user
>>> (darwin-user still has no environment related options).
>>>
>> St
** Changed in: qemu
Status: New => Confirmed
--
ppc fails to clear MSR_POW when incurring exception
https://bugs.launchpad.net/bugs/608107
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Status in QEMU: Confirmed
Bug description
vvfat tries to set the readonly flag in its open function, but nowadays
this is overwritted with the readonly=... command line option. Check in
bdrv_write if the vvfat was opened read-only and return an error in this
case.
Without this check, vvfat tries to access the qcow bs, which is NULL
withou
I tried to use vvfat recently, just to find that some changes have
completely broken it. With these patches it works "good enough" for me
again.
Kevin Wolf (3):
vvfat: Fix segfault on write to read-only disk
vvfat: Fix double free for opening the image rw
vvfat: Use cache=unsafe
block/vvfa
The qcow file used for write support in vvfat is a temporary file,
so we can use cache=unsafe there. Without this, write support is just
too slow to be of any use.
Signed-off-by: Kevin Wolf
---
block/vvfat.c | 14 ++
1 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/b
Allocation and deallocation of bs->opaque is not in the control of a
block driver. Therefore it should not set bs->opaque to a data structure
used by another bs, or closing the image will lead to a double free.
Signed-off-by: Kevin Wolf
---
block/vvfat.c |7 ---
1 files changed, 4 insert
On 09/09/2010 08:02 PM, Anthony Liguori wrote:
On 09/09/2010 11:48 AM, Paolo Bonzini wrote:
On 09/09/2010 02:49 PM, Anthony Liguori wrote:
We should optimize for the future. That means a btrfs file system
and/or
enterprise storage.
So we should just implement a copy-on-read wrapper that gen
On 09/09/2010 03:49 PM, Anthony Liguori wrote:
On 09/09/2010 01:45 AM, Avi Kivity wrote:
Loading very large L2 tables on demand will result in very long
latencies. Increasing cluster size will result in very long first
write latencies. Adding an extra level results in an extra random
write
On 09/10/2010 12:01 AM, Christoph Hellwig wrote:
On Thu, Sep 09, 2010 at 09:24:26AM +0300, Avi Kivity wrote:
The other thing we can do is defragment the logical image, then
defragment the underlying file (if the filesystem supports it, issue the
appropriate ioctl, otherwise defragment to a new
On 09/09/2010 08:43 PM, Anthony Liguori wrote:
Hm, we do have a use case for qcow2-over-lvm. I can't say it's
something I like, but a point to consider.
We specifically are not supporting that use-case in QED today.
There's a good reason for it. For cluster allocation, we achieve good
pe
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 that have been made to it are almost at th
On Fri, Sep 10, 2010 at 12:25 PM, 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 inte
On Fri, Sep 10, 2010 at 12:22 PM, Avi Kivity wrote:
> On 09/09/2010 08:43 PM, Anthony Liguori wrote:
>>>
>>> Hm, we do have a use case for qcow2-over-lvm. I can't say it's something
>>> I like, but a point to consider.
>>
>>
>> We specifically are not supporting that use-case in QED today. Ther
On 09/10/2010 02:29 PM, Stefan Hajnoczi wrote:
They only guarantee that the filesystem is consistent. A write() that
extends a file may be reordered with the L2 write() that references the new
cluster. Requiring fsck on unclean shutdown is very backwards for a 2010
format.
I'm interested i
On Fri, Sep 10, 2010 at 12:14 PM, Avi Kivity wrote:
> On 09/09/2010 03:49 PM, Anthony Liguori wrote:
>>
>> On 09/09/2010 01:45 AM, Avi Kivity wrote:
>>>
>>> Loading very large L2 tables on demand will result in very long
>>> latencies. Increasing cluster size will result in very long first write
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 until it is no longer
sparse (the lack of TRI
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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,
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
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
---
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
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,
>
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
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
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
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
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>
> >>>
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:
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:
> >>>
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
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
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
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
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
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
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
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
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
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
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
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
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/
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
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 +--
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 +--
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 |
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
-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
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
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
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
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
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="
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'
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
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/
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
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
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..
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
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
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
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
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
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
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
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
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
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
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
1 - 100 of 116 matches
Mail list logo
