On Wed, 10/08 13:15, Alexandre DERUMIER wrote:
> Hi,
>
> I'm currently planning to migrate our storage to ceph/rbd through qemu
> drive-mirror
>
> and It seem that drive-mirror with rbd block driver, don't create a sparse
> image. (all zeros are copied to the target rbd).
>
> Also note, that i
In qcow2_update_snapshot_refcount -> qcow2_process_discards() -> bdrv_discard()
may free the Qcow2DiscardRegion which is referenced by "next" pointer in
qcow2_process_discards() now, in next iteration, d = next, so g_free(d)
will double-free this Qcow2DiscardRegion.
qcow2_snapshot_delete
|- qcow2_
On Sat, 2014-10-11 at 13:58 +0800, zhanghailiang wrote:
> Hi all,
>
> When i try to passthrough BCM5719 Gigabit Ethernet to guest using the qemu
> master branch, it aborted,
> and show kvm_set_phys_mem:error registering slot:Bad Address.
>
> qemu command:
> #./qemu/qemu/x86_64-softmmu/qemu-syste
>>What is the source format? If the zero clusters are actually unallocated in
>>the
>>source image, drive-mirror will not write those clusters either. I.e. with
>>"drive-mirror sync=top", both source and target should have the same "qemu-img
>>map" output.
Thanks for your reply,
I had tried driv
On Sat, 10/11 10:00, Alexandre DERUMIER wrote:
> >>What is the source format? If the zero clusters are actually unallocated in
> >>the
> >>source image, drive-mirror will not write those clusters either. I.e. with
> >>"drive-mirror sync=top", both source and target should have the same
> >>"qemu-
On Sat, Oct 11, 2014 at 12:25 PM, Fam Zheng wrote:
> On Sat, 10/11 10:00, Alexandre DERUMIER wrote:
>> >>What is the source format? If the zero clusters are actually unallocated
>> >>in the
>> >>source image, drive-mirror will not write those clusters either. I.e. with
>> >>"drive-mirror sync=top
When the Qcow2DiscardRegion is adjacent to another one referenced by "d",
free this Qcow2DiscardRegion metadata referenced by "p" after
it was removed from s->discards queue.
Signed-off-by: Zhang Haoyu
---
block/qcow2-refcount.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/block/qcow2-ref
On Fri, Oct 10, 2014 at 8:57 PM, Peter Maydell wrote:
> The ARM ARM requires that the FPINST and FPINST2 VFP control
> registers are not accessible to code at EL0. We were already
> correctly implementing this for reads of these registers; add
> the missing check for the write code path.
>
> Signe
On Fri, Oct 10, 2014 at 8:46 PM, Peter Maydell wrote:
> For the CPU type "any" (only used with linux-user) we were reporting
> the L1Ip field as 0b00, which is reserved. Change this field to 0b10
> instead, indicating a VIPT icache as the comment describes.
>
> Signed-off-by: Peter Maydell
Revie
Am 09.10.2014 um 20:58 schrieb Benoît Canet:
On Wed, Oct 08, 2014 at 09:43:19PM +0200, Max Reitz wrote:
On 22.09.2014 17:36, Max Reitz wrote:
raw_co_get_block_status() should return 0 and set *pnum to 0 after the
EOF; currently it does this merely by accident, so implement it
directly. Also, nb
Ken Chiang writes:
> Hello,
>
> I am trying to add a block device dynamically using qmp and are having
> some issues.
>
> After successfully adding the block device using "blockdev-add" and
> verifying that it has been added using "query-block", I am unable to
> see the block device in the VM und
Am 10.10.2014 um 13:50 schrieb Benoît Canet:
The Saturday 16 Aug 2014 à 20:54:16 (+0200), Max Reitz wrote :
When falling through to the underlying file in
bdrv_co_get_block_status(), do not let the number of sectors for which
information could be obtained be overwritten.
Signed-off-by: Max Reit
Am 10.10.2014 um 14:03 schrieb Benoît Canet:
+} else if (!num) {
+error_report("Unexpected end of image");
+return 0;
I think this test can miss some case of Unexpected end of image.
For example supose that in map_is_allocated the first bdrv_is_allocated
actually
Am 09.10.2014 um 01:09 schrieb Eric Blake:
On 08/29/2014 03:41 PM, Max Reitz wrote:
The previous commit introduced the "rebuild" variable to qcow2's
implementation of the image consistency check. Now make use of this by
adding a function which creates a completely new refcount structure
based so
Am 10.10.2014 um 14:29 schrieb Benoît Canet:
On Fri, Aug 29, 2014 at 11:40:53PM +0200, Max Reitz wrote:
The size of a refblock entry is (in theory) variable; calculate
therefore the number of entries per refblock and the according bit shift
(1 << x == entry count) when opening an image.
Signed-
Am 10.10.2014 um 14:44 schrieb Benoît Canet:
+*nb_clusters = cluster + cluster_count - contiguous_free_clusters;
+*refcount_table = g_try_realloc(*refcount_table,
+*nb_clusters * sizeof(uint16_t));
Something tells me that these sizeof(uint1
Am 10.10.2014 um 14:32 schrieb Eric Blake:
On 08/26/2014 03:36 PM, Max Reitz wrote:
bdrv_make_empty() is currently only called if the current image
represents an external snapshot that has been committed to its base
image; it is therefore unlikely to have internal snapshots. In this
case, bdrv_m
Am 10.10.2014 um 18:47 schrieb Eric Blake:
On 08/26/2014 03:36 PM, Max Reitz wrote:
Add a test for qcow2's fast bdrv_make_empty implementation on images
without internal snapshots.
This test may need to be limited to compat=1.1 files.
Will do.
Signed-off-by: Max Reitz
---
tests/qemu-iote
On 29 September 2014 16:40, Stefan Hajnoczi wrote:
> The virtio event_index feature lets the device driver tell the device
> how many requests to process before raising the next interrupt.
> virtio-blk-test.c tries to verify that the device does not raise an
> interrupt unnecessarily.
>
> Unfortun
On 11 October 2014 12:43, Peter Maydell wrote:
> Hi; just noticed this breaks 'make check' build on MacOSX:
>
> /Users/pm215/src/qemu/tests/libqos/virtio.c:84:25: warning: implicit
> declaration of function
> 'g_get_monotonic_time' is invalid in C99
> [-Wimplicit-function-declaration]
>
On Fri, Oct 10, 2014 at 09:33:04AM +0200, Marcin Gibuła wrote:
> >Does anybody know why the APIC state loaded by the first call to
> >kvm_arch_get_registers() is wrong, in the first place? What exactly is
> >different in the APIC state in the second kvm_arch_get_registers() call,
> >and when/why do
Hello,
there's a bug in target-arm/translate-a64.c:disas_ldst_excl. The line:
TCGv_i64 tcg_rt2 = cpu_reg(s, rt);
is accessing the wrong register.
Thanks,
Laurent
'instructions-a64.h' has unused variables for qemu which can be found by
gcc 5.0.0 or higher. and qemu needs "-Werror", and cause building break.
But they may be used by another projects (not qemu).
So for gcc 5.0.0 or higher, need still keep them, but ignore diagnostic
(still print warning, but n
On 10/11/14 22:07, Chen Gang wrote:
> 'instructions-a64.h' has unused variables for qemu which can be found by
> gcc 5.0.0 or higher. and qemu needs "-Werror", and cause building break.
> But they may be used by another projects (not qemu).
>
> So for gcc 5.0.0 or higher, need still keep them, but
On 11 October 2014 14:04, Laurent Desnogues wrote:
> there's a bug in target-arm/translate-a64.c:disas_ldst_excl. The line:
>
> TCGv_i64 tcg_rt2 = cpu_reg(s, rt);
>
> is accessing the wrong register.
Yeah, obvious cut-n-paste error, but this doesn't actually
affect the exclusive code
Hello,
in target-arm/translate-a64.c:do_fp_st, it looks like there's an
extraneous store:
TCGv_i64 tcg_hiaddr = tcg_temp_new_i64();
tcg_gen_qemu_st_i64(tmp, tcg_addr, get_mem_index(s), MO_TEQ);
tcg_gen_qemu_st64(tmp, tcg_addr, get_mem_index(s));
The second one can safely
The Saturday 11 Oct 2014 à 11:53:40 (+0200), Max Reitz wrote :
> Am 10.10.2014 um 14:03 schrieb Benoît Canet:
> >>+} else if (!num) {
> >>+error_report("Unexpected end of image");
> >>+return 0;
> >I think this test can miss some case of Unexpected end of image.
> >
The Saturday 16 Aug 2014 à 20:54:17 (+0200), Max Reitz wrote :
> bdrv_is_allocated() may report zero clusters which most probably means
> the image (file) is shorter than expected. Respect this case in order to
> avoid an infinite loop.
>
> Signed-off-by: Max Reitz
> ---
> qemu-io-cmds.c | 5 +++
The Saturday 11 Oct 2014 à 11:44:20 (+0200), Max Reitz wrote :
> Am 10.10.2014 um 13:50 schrieb Benoît Canet:
> >The Saturday 16 Aug 2014 à 20:54:16 (+0200), Max Reitz wrote :
> >>When falling through to the underlying file in
> >>bdrv_co_get_block_status(), do not let the number of sectors for whi
> +int64_t first_free_cluster = 0, rt_ofs = -1, cluster = 0;
> +int64_t rb_ofs, rb_start, rb_index;
Everytime a few day pass and I read rb_ofs and rt_ofs again I found these names
obfuscated. I know Linus says that C is a spartan language but these look odd.
Maybe refcount_block_offset, r
On 11 October 2014 15:13, Chen Gang wrote:
MJT: please don't put this in -trivial, it will clash with
the update to libvixl 1.6 currently on the list.
> On 10/11/14 22:07, Chen Gang wrote:
>> 'instructions-a64.h' has unused variables for qemu which can be found by
>> gcc 5.0.0 or higher. and qe
On 10/12/14 5:25, Peter Maydell wrote:
> On 11 October 2014 15:13, Chen Gang wrote:
>
> MJT: please don't put this in -trivial, it will clash with
> the update to libvixl 1.6 currently on the list.
>
OK thanks (also remove -trivial from replying mailing list).
>
>> On 10/11/14 22:07, Chen Gan
On Fri, Oct 10, 2014 at 08:44:29PM +0100, Peter Maydell wrote:
> Following cleanup of the vga device code in commit d2e043a8041,
> the arrays dmask4 and dmask16 are now unused. gcc doesn't warn
> about this, but clang does; remove them.
>
> Signed-off-by: Peter Maydell
Reviewed-by: David Gibson
33 matches
Mail list logo
