This patch will hide all symbols except those marked with
QEMU_DLL_PUBLIC in .lo files. Because vsclient linked some
function in qemu, so export them as well. All symbols
in libcacard.syms are marked as public.
Signed-off-by: Wenchao Xia
---
configure | 18 +
Now libqblock can be packaged and installed by
"sudo make install-libqblock'.
Signed-off-by: Wenchao Xia
---
libqblock/Makefile | 34 +-
libqblock/libqblock.pc.in | 13 +
2 files changed, 42 insertions(+), 5 deletions(-)
create mode 1
This command will package the clean operations in tests,
to make it easy to be extended. Now root Makefile simply calls
the command and do not care the details of it any more.
Signed-off-by: Wenchao Xia
---
Makefile |1 -
tests/Makefile |8 +++-
2 files changed, 7 insertions(
In this example, first it will create some qcow2 images, then try get
information including backing file relationship, then it will do sync IO on
the image.
Signed-off-by: Wenchao Xia
---
tests/Makefile|2 +
tests/check-libqblock-qcow2.c | 388 +
Public API design header files: libqblock.h, libqblock-error.h.
Public type define header files: libqblock-types.h. Private internal used
header files: libqblock-internal. For ABI some reserved bytes are used in
structure defines. Macro QEMU_DLL_PUBLIC is used to mark exported function.
Importan
On Wed, Feb 6, 2013 at 9:45 AM, Kuo-Jung Su wrote:
> From: Kuo-Jung Su
>
> The FTMAC110 is an Ethernet controller that provides AHB master capability
> and is in full compliance with the IEEE 802.3 10/100 Mbps specifications.
> Its DMA controller handles all data transfers between system memory
>
On Fri, Feb 8, 2013 at 3:42 AM, Peter Crosthwaite
wrote:
> Signed-off-by: Peter Crosthwaite
> ---
>
> hw/xilinx_zynq.c | 24
> 1 files changed, 24 insertions(+), 0 deletions(-)
>
> diff --git a/hw/xilinx_zynq.c b/hw/xilinx_zynq.c
> index 0ac33b5..f826bff 100644
> --- a
On Sat, Feb 9, 2013 at 7:42 AM, Wenchao Xia wrote:
> This patch contains implemention for APIs. Basically it is a layer
> above qemu block general layer now.
> qb_image_new() will try do init for this library.
>
> Signed-off-by: Wenchao Xia
> ---
> libqblock/libqblock-error.c | 49 +++
> l
Public bug reported:
We tested qemu 1.3.1 for live migration of block device. It failed with
error. Since qemu-kvm 1.2.0 is ok for this test, we think this problem
is introduced by new qemu 1.3.x releases.
To reproduce:
1. compile qemu 1.3.1:
# cd qemu-1.3.1
# ./configure --prefix=/usr
Hey Gleb, Marcelo:
I was looking at the sanity jobs for qemu.git and found this error that
happened during RHEL 6.3 guest reboot test:
02/09 05:16:45 INFO | aexpect:0797| [qemu output] KVM internal
error. Suberror: 1
02/09 05:16:45 INFO | aexpect:0797| [qemu output] emulation failure
On Sat, Feb 9, 2013 at 3:46 PM, Reno Gan wrote:
> Public bug reported:
>
> We tested qemu 1.3.1 for live migration of block device. It failed with
> error. Since qemu-kvm 1.2.0 is ok for this test, we think this problem
> is introduced by new qemu 1.3.x releases.
Thanks for reporting this bug.
bdrv_co_io_em(), bdrv_co_flush(), and bdrv_co_discard() yield the
coroutine when waiting for aio to complete. They do not check that the
request has actually finished.
In simple cases this works, but it returns early when we get spurious
wake-ups due to qemu_coroutine_enter() being called from ot
Commit 43be3a25c931a7f61a76fbfc9d35584cbfc5fb58 changed the
blk_mig_save_dirty_block() return code handling. The function's doc
comment says:
/* return value:
* 0: too much data for max_downtime
* 1: few enough data for max_downtime
*/
Because of the 1 return value, callers must check
Show the actual flags value and include "block migration" in the error
message so it's clear where the error is coming from.
Signed-off-by: Stefan Hajnoczi
---
block-migration.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block-migration.c b/block-migration.c
index 9ac7de
Block migration is currently broken. This series fixes it.
Patch 1 - improve "Unknown flags" error message
Patch 2 - the "Unknown flags" error means the source and destination QEMUs are
not in sync. The destination expects a block migration message but finds an
unexpected message. This is beca
The .save_live_iterate() function returns 0 it continue iterating or 1
to stop iterating.
Since 16310a3cca7320edb9341c976f7819de0a8c27e0 it only ever returns 0,
leading to an infinite loop.
Return 1 if we have finished sending dirty blocks.
Signed-off-by: Stefan Hajnoczi
---
block-migration.c
On Sat, Feb 9, 2013 at 3:46 PM, Reno Gan wrote:
> Public bug reported:
>
> We tested qemu 1.3.1 for live migration of block device. It failed with
> error. Since qemu-kvm 1.2.0 is ok for this test, we think this problem
> is introduced by new qemu 1.3.x releases.
I have posted fixes to the qemu
Check if xsltproc and Sparc32, Sparc64 and PPC compilers
are available. If found, rebuild OpenBIOS ROMs from submodule.
Signed-off-by: Blue Swirl
---
A patch to OpenBIOS is also needed to support out of tree build,
just sent to the list.
---
configure | 25 +
Support building in any directory, not just in-tree build.
Use VPATH for non-Forth files.
Forth compiler does not support explicit paths, so drop source path
prefixes added by XML and rely on directories passed with -I flag.
Signed-off-by: Blue Swirl
---
.gitignore |1 +
Ma
I have tried this patch and it works. Thanks for your work and can't
wait 1.4 coming out
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1120383
Title:
incremental live block migration of qemu 1.3.1
Another thing i want to mention about live block migration, though i
don't know if this is really an issue of qemu or downstream libvirt.
When I was testing live migration of qemu-kvm-1.2.0 for long run, i
found a problem that block data are not completed transferred to target
host. I traced that
On Sun, Feb 10, 2013 at 3:48 AM, Reno Gan wrote:
> Another thing i want to mention about live block migration, though i
> don't know if this is really an issue of qemu or downstream libvirt.
>
> When I was testing live migration of qemu-kvm-1.2.0 for long run, i
> found a problem that block data a
09.02.2013 23:01, Blue Swirl wrote:
Check if xsltproc and Sparc32, Sparc64 and PPC compilers
are available. If found, rebuild OpenBIOS ROMs from submodule.
Signed-off-by: Blue Swirl
---
A patch to OpenBIOS is also needed to support out of tree build,
just sent to the list.
[]
+# OpenBIOS need
If you want to reproduce it, you can refer to my test case in this bug
description, only differences are:
1) make sure "os.img" is big enough, for example, > 300M
2) write a script to migrate it in a loop:
a) migrate from A to B
b) shutdown guest on B and start it again
c)
24 matches
Mail list logo
