On 2017年01月20日 21:08, Peter Xu wrote:
The default replay() don't work for VT-d since vt-d will have a huge
default memory region which covers address range 0-(2^64-1). This will
normally consumes a lot of time (which looks like a dead loop).
The solution is simple - we don't walk over all the
From: Li Qiang
In virtio_gpu_set_scanout function, when creating the 'rect'
its refcount is set to 2, by pixman_image_create_bits and
qemu_create_displaysurface_pixman function. This can lead
a memory leak issues. This patch avoid this issue.
Signed-off-by: Li Qiang
---
hw/display/virtio-gpu.
Change the name of live migration thread from 'migration'
to 'qemu_vm_migration' to identify it clearly. 'migration'
is a generic word and kernel also has tasks for process
migration with the name 'migration/cpu#'.
Signed-off-by: Pankaj Gupta
---
migration/migration.c | 2 +-
1 file changed, 1
On 01/19/2017 08:54 AM, Kirill Batuzov wrote:
Wrappers issue emulation code instead of operation if it is not supported by
host.
tcg_gen_add_i32x4 looks like this:
if (TCG_TARGET_HAS_add_i32x4) {
tcg_gen_op3_v128(INDEX_op_add_i32x4, args[0], args[1], args[2]);
} else {
for (i = 0; i <
On Sun, Jan 22, 2017 at 04:42:13AM +, Tian, Kevin wrote:
> > From: Peter Xu [mailto:pet...@redhat.com]
> > Sent: Friday, January 20, 2017 6:04 PM
> >
> > On Fri, Jan 20, 2017 at 09:52:01AM +, Tian, Kevin wrote:
> >
> > [...]
> >
> > > btw what about guest setups a valid mapping at 0xFEEx
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Saturday, January 21, 2017 2:21 AM
>
> On Fri, 20 Jan 2017 06:57:22 +
> "Tian, Kevin" wrote:
>
> > > From: Alex Williamson
> > > Sent: Thursday, January 19, 2017 6:32 AM
> > >
> > > On Sat, 31 Dec 2016 17:13:07 +0800
> > > C
> From: Peter Xu [mailto:pet...@redhat.com]
> Sent: Friday, January 20, 2017 6:04 PM
>
> On Fri, Jan 20, 2017 at 09:52:01AM +, Tian, Kevin wrote:
>
> [...]
>
> > btw what about guest setups a valid mapping at 0xFEEx_ in
> > its remapping structure, which is then programmed to virtual
> >
On Sat, Jan 21, 2017 at 04:16:25AM +0100, fassl wrote:
> Hello,
>
> i am trying to pass through a graphic card to a guest within a guest.
> So far i can see a text console within the target vm which says
> "radeon: ring 0 test failed", so it times out in radeon_vce_ring_test
> function. I am using
On Fri, Jan 20, 2017 at 10:14:01AM -0700, Alex Williamson wrote:
> On Fri, 20 Jan 2017 20:27:18 +0800
> Peter Xu wrote:
>
> > On Fri, Jan 20, 2017 at 11:43:28AM +0800, Peter Xu wrote:
> >
> > [...]
> >
> > > > What I don't want to see is for this API bug to leak out into the rest
> > > > of the
From: Aviv Ben-David
This capability asks the guest to invalidate cache before each map operation.
We can use this invalidation to trap map operations in the hypervisor.
Signed-off-by: Aviv Ben-David
[peterx: using "caching-mode" instead of "cache-mode" to align with spec]
[peterx: re-write the
On Fri, Jan 20, 2017 at 09:42:25AM -0600, Eric Blake wrote:
> On 01/12/2017 09:06 PM, Peter Xu wrote:
> > From: Aviv Ben-David
>
> Long subject line, please try to keep it around 60 or so characters
> (look at 'git shortlog -30' for comparison). Also, fix the typos:
> s/capility exposoed/capabil
On 19.01.2017 17:35, Peter Lieven wrote:
> the current implementation always splits requests if a buffer
> begins or ends with zeroes independent of the length of the
> zero area. Change this to really only split off zero areas
> that have at least a length of 'min' bytes.
>
> Signed-off-by: Peter
On 19.01.2017 14:07, Fam Zheng wrote:
> The 059.out went out of sync, bring it back in line.
>
> Fam Zheng (2):
> qapi: Tweak error message of bdrv_query_image_info
> iotests: Fix reference output for 059
>
> block/qapi.c | 4 ++--
> tests/qemu-iotests/059.out | 2 +-
> 2 files
On 19.01.2017 14:07, Fam Zheng wrote:
> @bs doesn't always have a device name, such as when it comes from
> "qemu-img info". Report file name instead.
>
> Signed-off-by: Fam Zheng
> ---
> block/qapi.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Yes, I had a discussion with Kevin
On 03.01.2017 19:28, Daniel P. Berrange wrote:
> Now that all encryption keys must be provided upfront via
> the QCryptoSecret API and associated block driver properties
> there is no need for any explicit encryption handling APIs
> in the block layer. Encryption can be handled transparently
> with
On 03.01.2017 19:28, Daniel P. Berrange wrote:
> Now that qcow & qcow2 are wired up to get encryption keys
> via the QCryptoSecret object, nothing is relying on the
> interactive prompting for passwords. All the code related
> to password prompting can thus be ripped out.
>
> Signed-off-by: Daniel
On 03.01.2017 19:27, Daniel P. Berrange wrote:
> The 138 and 158 iotests exercise the legacy qcow2 aes encryption
> code path. With a few simple tweaks they can exercise the same
> feature in qcow (v1).
>
> Signed-off-by: Daniel P. Berrange
> ---
> tests/qemu-iotests/134 | 10 +-
> tests
On 03.01.2017 19:27, Daniel P. Berrange wrote:
> This converts the qcow2 driver to make use of the QCryptoBlock
> APIs for encrypting image content, using the legacyy QCow2 AES
> scheme.
>
> With this change it is now required to use the QCryptoSecret
> object for providing passwords, instead of t
On 03.01.2017 19:27, Daniel P. Berrange wrote:
> This adds support for using LUKS as an encryption format
> with the qcow2 file. The use of the existing 'encryption=on'
> parameter is replaced by a new parameter 'encryption-format'
> which takes the values 'aes' or 'luks'. e.g.
>
> # qemu-img cr
Applied to -trivial, thanks!
/mjt
Applied both to -trivial, thank you!
/mjt
Applied to -trivial, thanks!
/mjt
15.01.2017 23:30, Samuel Thibault wrote:
> The curses and none possibilities are already documented on a separate line,
> so documenting it on the sdl line was both unneeded and confusing.
Applied to -trivial, thanks!
/mjt
The current code tries to copy `read_count' bytes starting at offset
`offset' from a `read_count`-sized iovec. This causes v9fs_pack() to
fail with ENOBUFS.
Since the PDU iovec is already partially filled with `offset' bytes,
let's skip them when creating `qiov_full' and have v9fs_pack() to
copy t
Thanks for your replies,
I've managed to compile it using a chroot as suggested by Peter. I just
grabbed a pre-built rootfs from here : https://wiki.debian.org/Arm64Port
#Pre-built_Rootfses, then installed qemu-user-static with apt-get and
run the build from the chroot.
Somehow "apt-get build-dep
this was an issue in my setup
** Changed in: qemu
Status: New => Invalid
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1658120
Title:
building with gcc-aarch64-linux-gnu
Status in QEMU:
From: tianqing
Rbd can do readv and writev directly, so wo do not need to transform
iov to buf or vice versa any more.
Signed-off-by: tianqing
---
block/rbd.c | 47 +--
1 file changed, 41 insertions(+), 6 deletions(-)
diff --git a/block/rbd.c b/bloc
On Fri, Jan 20, 2017 at 01:35:10PM -0600, Eric Blake wrote:
> On 01/20/2017 12:00 PM, Alex Bligh wrote:
> >
> >> On 20 Jan 2017, at 17:04, Vladimir Sementsov-Ogievskiy
> >> wrote:
> >>
> >> About extents: is 32bit length enough? We will have to send 4096 for empty
> >> 16tb disk..
> >
> > The
Hi,
Your series seems to have some coding style problems. See output below for
more information:
Subject: [Qemu-devel] [RFC v3] RBD: Add support readv,writev for rbd
Message-id: 20170121105949.15466-1-jaze...@gmail.com
Type: series
=== TEST SCRIPT BEGIN ===
#!/bin/bash
BASE=base
n=1
total=$(git
From: tianqing
Rbd can do readv and writev directly, so wo do not need to transform
iov to buf or vice versa any more.
Signed-off-by: tianqing
---
block/rbd.c | 47 +--
1 file changed, 41 insertions(+), 6 deletions(-)
diff --git a/block/rbd.c b/bloc
@~quentin.casasnovas please report this as new feature request, instead
of adding comment to this one.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/601946
Title:
[Feature request] qemu-img multi-t
That was also my feeling, so nice to get a confirmation!
Another related thing would be to allow qemu-nbd to write compressed
blocks its backing image - today if you use a qcow2 with compression,
any block which is written to gets uncompressed in the resulting image
and you need to recompress the
Hi,
Your series seems to have some coding style problems. See output below for
more information:
Subject: [Qemu-devel] [RFC PATCH 0/3] Preparing the build system for libtcg
Message-id: 20170121084600.5860-1-ale+q...@clearmind.me
Type: series
=== TEST SCRIPT BEGIN ===
#!/bin/bash
BASE=base
n=1
t
Move some functions around in target/$arch/*.c to reduce the coupling
among the various compilation unit. In particular, we want to make the
various translate.c as much standalone as possible, so that they will be
easily employed by libtcg.
---
exec.c | 2 +
target/arm/cpu.
A quite large part of {linux,bsd}-user/qemu.h is shared, this patch
introduces qemu-user-common.h which factors it out. This shared part is
also the bare minimum required to build a linux-user-like target, and,
in particular, it will be useful for the libtcg targets.
---
bsd-user/qemu.h| 193 +
[This is a draft patch is for review purposes only]
* Extend the build system to build libtcg-$arch.so dynamic libraries.
* Introduce --enable-libtcg and --disable-libtcg the *-libtcg target,
similar to *-linux-user and *-bsd-user, since it enables
CONFIG_USER_ONLY, but uses only the TCG front
This series of patches introduce a set of changes, mainly to the QEMU
build system, to open the way to implementing "libtcg", i.e., using
QEMU's tiny code generator frontends as a library.
For the initial proposal, please see the related discussion:
http://lists.nongnu.org/archive/html/qemu-devel
On Sat, 21 Jan 2017 04:16:25 +0100
fassl wrote:
> Hello,
>
> i am trying to pass through a graphic card to a guest within a guest.
> So far i can see a text console within the target vm which says
> "radeon: ring 0 test failed", so it times out in radeon_vce_ring_test
> function. I am using qemu
Hello,
i am trying to pass through a graphic card to a guest within a guest.
So far i can see a text console within the target vm which says
"radeon: ring 0 test failed", so it times out in radeon_vce_ring_test
function. I am using qemu 2.8.50 at revision
0f6bcf68a99efdc531b209551f2b760b0bdcc554.
39 matches
Mail list logo
