Re: [Qemu-devel] [Qemu-stable] [2.2 PATCH] virtio-net: fix unmap leak

On Thu, 11/27 13:59, Jason Wang wrote: > virtio_net_handle_ctrl() and other functions that process control vq > request call iov_discard_front() which will shorten the iov. This will > lead unmapping in virtqueue_push() leaks mapping. > > Fixes this by keeping the original iov untouched and using

[Qemu-devel] [2.2 PATCH] virtio-net: fix unmap leak

virtio_net_handle_ctrl() and other functions that process control vq request call iov_discard_front() which will shorten the iov. This will lead unmapping in virtqueue_push() leaks mapping. Fixes this by keeping the original iov untouched and using a temp variable in those functions. Cc: Wen Cong

[Qemu-devel] [PATCH] Fix for crash after migration in virtio-rng on bi-endian targets

VirtIO devices now remember which endianness they're operating in in order to support targets which may have guests of either endianness, such as powerpc. This endianness state is transferred in a subsection of the virtio device's information. With virtio-rng this can lead to an abort after a loa

[Qemu-devel] [Bug 1396497] Re: 'qemu-img snapshot' allows new snapshot to be created with the name of an existing snapshot

I'd agree that at least the last part - removing the oldest snapshot first - seems like a bug. ** Also affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.n

Re: [Qemu-devel] [Xen-devel] virtio leaks cpu mappings, was: qemu crash with virtio on Xen domUs (backtrace included)

On 11/26/2014 06:53 PM, Stefano Stabellini wrote: On Wed, 26 Nov 2014, Jason Wang wrote: >On 11/25/2014 09:53 PM, Stefano Stabellini wrote: > >On Tue, 25 Nov 2014, Jason Wang wrote: > >>On 11/25/2014 02:44 AM, Stefano Stabellini wrote: > >>>On Mon, 24 Nov 2014, Stefano Stabellini wrote: >

[Qemu-devel] [PATCH] nvme: 64kB page size fixes

Initialise our maximum page size capability to 64kB and increase the page_size variable from 16 to 32 bits. Signed-off-by: Anton Blanchard -- diff --git a/hw/block/nvme.c b/hw/block/nvme.c index 1327658..aa1ed98 100644 --- a/hw/block/nvme.c +++ b/hw/block/nvme.c @@ -811,6 +811,7 @@ static int nv

Re: [Qemu-devel] [Xen-devel] [PATCH] increase maxmem before calling xc_domain_populate_physmap

On 11/26/14 13:17, Stefano Stabellini wrote: On Tue, 25 Nov 2014, Andrew Cooper wrote: On 25/11/14 17:45, Stefano Stabellini wrote: Increase maxmem before calling xc_domain_populate_physmap_exact to avoid the risk of running out of guest memory. This way we can also avoid complex memory calcul

Re: [Qemu-devel] [PATCH] qmp: extend QMP to provide read/write access to physical memory

On Wed, 11/26 12:27, Bryan D. Payne wrote: > This patch adds a new QMP command that sets up a domain socket. This > socket can then be used for fast read/write access to the guest's > physical memory. The key benefit to this system over existing solutions > is speed. Using this patch, guest memory

Re: [Qemu-devel] [PATCH] ppc: do not use get_clock_realtime()

On Wed, Nov 26, 2014 at 03:01:01PM +0100, Paolo Bonzini wrote: > Use the external qemu-timer API instead. Perhaps it's obvious but is it reasonable to expand on why you're doign this in the commit message? Yours Tony. pgpbbAXtQoPFT.pgp Description: PGP signature

Re: [Qemu-devel] virtio_blk: fix defaults for max_hw_sectors and max_segment_size

On Wed, Nov 26 2014 at 4:53pm -0500, Jens Axboe wrote: > On 11/26/2014 02:51 PM, Mike Snitzer wrote: > > > > But while you're here, I wouldn't mind getting your take on virtio-blk > > setting max_hw_sectors to -1U. > > > > As I said in my original reply to mst: it only makes sense to set a > >

Re: [Qemu-devel] virtio_blk: fix defaults for max_hw_sectors and max_segment_size

On 11/26/2014 02:51 PM, Mike Snitzer wrote: > On Wed, Nov 26 2014 at 3:54pm -0500, > Jens Axboe wrote: > >> On 11/26/2014 01:51 PM, Mike Snitzer wrote: >>> On Wed, Nov 26 2014 at 2:48pm -0500, >>> Jens Axboe wrote: >>> That code isn't even in mainline, as far as I can tell... >>> >>>

Re: [Qemu-devel] virtio_blk: fix defaults for max_hw_sectors and max_segment_size

On Wed, Nov 26 2014 at 3:54pm -0500, Jens Axboe wrote: > On 11/26/2014 01:51 PM, Mike Snitzer wrote: > > On Wed, Nov 26 2014 at 2:48pm -0500, > > Jens Axboe wrote: > > > >> > >> That code isn't even in mainline, as far as I can tell... > > > > Right, it is old RHEL6 code. > > > > But I've y

Re: [Qemu-devel] MinGW build

On 26 Nov 2014, at 22:13, Peter Maydell wrote: > ... We have a workaround already for a similar thing in > include/sysemu/os-win32.h, ok, I'll investigate. > Do you have any experience with mingw-w64? unfortunately not, but, time permitting, I'll check it. > In any case, thanks very much for

Re: [Qemu-devel] virtio_blk: fix defaults for max_hw_sectors and max_segment_size

On 11/26/2014 01:51 PM, Mike Snitzer wrote: > On Wed, Nov 26 2014 at 2:48pm -0500, > Jens Axboe wrote: > >> On 11/21/2014 08:49 AM, Mike Snitzer wrote: >>> On Fri, Nov 21 2014 at 4:54am -0500, >>> Christoph Hellwig wrote: >>> On Thu, Nov 20, 2014 at 02:00:59PM -0500, Mike Snitzer wrote: >

Re: [Qemu-devel] virtio_blk: fix defaults for max_hw_sectors and max_segment_size

On Wed, Nov 26 2014 at 2:48pm -0500, Jens Axboe wrote: > On 11/21/2014 08:49 AM, Mike Snitzer wrote: > > On Fri, Nov 21 2014 at 4:54am -0500, > > Christoph Hellwig wrote: > > > >> On Thu, Nov 20, 2014 at 02:00:59PM -0500, Mike Snitzer wrote: > >>> virtio_blk incorrectly established -1U as the

[Qemu-devel] [Bug 1395217] Re: Networking in qemu 2.0.0 and beyond is not compatible with Open Solaris (Illumos) 5.11

Much appreciated! Please let me know if there is anything else I can do to help this bug progress . . . . - Tim -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1395217 Title: Networking in qemu 2.0

[Qemu-devel] [PATCH] qmp: extend QMP to provide read/write access to physical memory

This patch adds a new QMP command that sets up a domain socket. This socket can then be used for fast read/write access to the guest's physical memory. The key benefit to this system over existing solutions is speed. Using this patch, guest memory can be copied out at a rate of ~200MB/sec, dependin

Re: [Qemu-devel] MinGW build

Am 26.11.2014 um 21:13 schrieb Peter Maydell: > On 26 November 2014 at 19:55, Liviu Ionescu wrote: >> since I had some troubles to build QEMU on Windows, I compiled a page with >> some instructions: >> >> http://gnuarmeclipse.livius.net/wiki/How_to_build_QEMU#Windows >> >> the purpose was

[Qemu-devel] [PATCH v2] qmp: extend QMP to provide read/write access to physical memory

Thanks for the feedback Eric, I've updated the patch. v2 changes: - added QMP command contract to qapi-schema.json - corrected some comments - rewired QMP command to use schema code

[Qemu-devel] Not able to emulate host processor (2Sockets, 8Core/Socket, 2NUMA nodes) using host pass through

Hi, All, I'm using qemu-system-x86_64 in stable-2.1 and trying to use cpu pass-through (-cpu host) to emulate my host processor architecture, which is Intel Xeon CPU E5-2670 2.6GHz, 16 cores (2Sockets, 8Cores/Socket, 2Numa nodes). But it seems that the virtual machine is stuck at somewhere, can

Re: [Qemu-devel] MinGW build

On 26 November 2014 at 19:55, Liviu Ionescu wrote: > since I had some troubles to build QEMU on Windows, I compiled a page with > some instructions: > > http://gnuarmeclipse.livius.net/wiki/How_to_build_QEMU#Windows > > the purpose was to generate a standalone executable, that requires no

[Qemu-devel] MinGW build

since I had some troubles to build QEMU on Windows, I compiled a page with some instructions: http://gnuarmeclipse.livius.net/wiki/How_to_build_QEMU#Windows the purpose was to generate a standalone executable, that requires no libraries. although the procedure is fully functional, I ha

Re: [Qemu-devel] virtio_blk: fix defaults for max_hw_sectors and max_segment_size

On 11/21/2014 08:49 AM, Mike Snitzer wrote: > On Fri, Nov 21 2014 at 4:54am -0500, > Christoph Hellwig wrote: > >> On Thu, Nov 20, 2014 at 02:00:59PM -0500, Mike Snitzer wrote: >>> virtio_blk incorrectly established -1U as the default for these >>> queue_limits. Set these limits to sane default

[Qemu-devel] [Bug 1395217] Re: Networking in qemu 2.0.0 and beyond is not compatible with Open Solaris (Illumos) 5.11

So, if it breaks even with -cpu SandyBridge and -cpu host, it is likely to be a KVM or QEMU bug. Thanks for the testing! -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1395217 Title: Networking in q

Re: [Qemu-devel] [PATCH] hmp: fix regression of HMP device_del auto-completion

On Wed, 2014-11-26 at 13:05 -0500, Luiz Capitulino wrote: > On Wed, 26 Nov 2014 13:50:01 +0200 > Marcel Apfelbaum wrote: > > > The commits: > > - 6a1fa9f5 (monitor: add del completion for peripheral device) > > - 66e56b13 (qdev: add qdev_build_hotpluggable_device_list helper) > > > > cause a Q

Re: [Qemu-devel] TCG Multithreading performance improvement

> On 26 Nov 2014, at 20:12, Lluís Vilanova wrote: > > Mark Burton writes: > >> Hi all, >> We are now actively going to pursue TCG Multithreading to improve the >> performance of the TCG for Qemu models that include multiple cores. > >> We have set up a wiki page to track the project >> http:/

Re: [Qemu-devel] TCG Multithreading performance improvement

Mark Burton writes: > Hi all, > We are now actively going to pursue TCG Multithreading to improve the > performance of the TCG for Qemu models that include multiple cores. > We have set up a wiki page to track the project > http://wiki.qemu.org/Features/tcg-multithread > At this point, I would

[Qemu-devel] [Bug 1395217] Re: Networking in qemu 2.0.0 and beyond is not compatible with Open Solaris (Illumos) 5.11

Note that this Illumos image is certified/runs cleanly on Intel hardware from the last 5 years when natively on it. I doubt that it is a kernel problem with Illumos with regard to the actual CPU architecture. Older releases that are OpenSolaris based also see the problem. Generally speaking, I d

[Qemu-devel] [Bug 1395217] Re: Networking in qemu 2.0.0 and beyond is not compatible with Open Solaris (Illumos) 5.11

(Wow . . . that last was incredibly redundant . . . staying up most of the night working on this has apparently left me a bit stupid this morning/afternoon . . . sorry!) -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.lau

Re: [Qemu-devel] [PATCH] hmp: fix regression of HMP device_del auto-completion

On 26 November 2014 at 18:05, Luiz Capitulino wrote: > Peter, can you apply this patch directly to master to avoid me a pull > request? Maybe it's a good idea to wait until tomorrow for more > reviewers though. Sure. I'll apply it to master some time tomorrow afternoon I expect. -- PMM

[Qemu-devel] [Bug 1395217] Re: Networking in qemu 2.0.0 and beyond is not compatible with Open Solaris (Illumos) 5.11

Broadwell - Fails, Host won't support it: warning: host doesn't support requested feature: CPUID.01H:ECX.fma [bit 12] warning: host doesn't support requested feature: CPUID.01H:ECX.movbe [bit 22] warning: host doesn't support requested feature: CPUID.07H:EBX.fsgsbase [bit 0] warning: host doesn't

Re: [Qemu-devel] [PATCH RFC v3 05/12] virtio: introduce legacy virtio devices

On Wed, Nov 26, 2014 at 07:46:38PM +0100, Greg Kurz wrote: > On Wed, 26 Nov 2014 18:28:36 +0100 > Cornelia Huck wrote: > > > Introduce a helper function to indicate whether a virtio device is > > operating in legacy or virtio standard mode. > > > > It may be used to make decisions about the end

Re: [Qemu-devel] [PATCH RFC v3 11/12] virtio-net/virtio-blk: enable virtio 1.0

On Wed, Nov 26, 2014 at 06:28:42PM +0100, Cornelia Huck wrote: > virtio-net (non-vhost) and virtio-blk have everything in place to support > virtio 1.0: let's enable the feature bit for them. Hmm I doubt that. At least not without more patches. For block, scsi, wce and config-wce must be off, and

Re: [Qemu-devel] [PATCH RFC v3 05/12] virtio: introduce legacy virtio devices

On Wed, 26 Nov 2014 18:28:36 +0100 Cornelia Huck wrote: > Introduce a helper function to indicate whether a virtio device is > operating in legacy or virtio standard mode. > > It may be used to make decisions about the endianess of virtio accesses > and other virtio-1 specific changes, enabling

Re: [Qemu-devel] [Xen-devel] [PATCH] increase maxmem before calling xc_domain_populate_physmap

On Tue, 25 Nov 2014, Andrew Cooper wrote: > On 25/11/14 17:45, Stefano Stabellini wrote: > > Increase maxmem before calling xc_domain_populate_physmap_exact to avoid > > the risk of running out of guest memory. This way we can also avoid > > complex memory calculations in libxl at domain constructi

Re: [Qemu-devel] [PATCH RFC v3 07/12] dataplane: allow virtio-1 devices

On Wed, 26 Nov 2014 18:28:38 +0100 Cornelia Huck wrote: > Handle endianness conversion for virtio-1 virtqueues correctly. > > Note that dataplane now needs to be built per-target. > > Signed-off-by: Cornelia Huck Build is ok now. Acked-by: Greg Kurz > --- > hw/block/dataplane/virtio-blk.c

Re: [Qemu-devel] [PATCH] hmp: fix regression of HMP device_del auto-completion

On Wed, 26 Nov 2014 13:50:01 +0200 Marcel Apfelbaum wrote: > The commits: > - 6a1fa9f5 (monitor: add del completion for peripheral device) > - 66e56b13 (qdev: add qdev_build_hotpluggable_device_list helper) > > cause a QEMU crash when trying to use HMP device_del auto-completion. > It can be e

Re: [Qemu-devel] TCG Multithreading performance improvement

Another good slide for PQemu http://people.cs.nctu.edu.tw/~chenwj/slide/QEMU/PQEMU_presentation_(IIS_Sinica_2)_.pptx On Wed, Nov 26, 2014 at 5:31 PM, Mark Burton wrote: > > > Hi all, > > We are now actively going to pursue TCG Multithreading to improve the > performance of the TCG for Qemu model

[Qemu-devel] [PATCH v8 01/10] qapi: Add optional field "name" to block dirty bitmap

From: Fam Zheng This field will be set for user created dirty bitmap. Also pass in an error pointer to bdrv_create_dirty_bitmap, so when a name is already taken on this BDS, it can report an error message. This is not global check, two BDSes can have dirty bitmap with a common name. Implemented

[Qemu-devel] [PATCH v8 10/10] qemu-iotests: Add tests for drive-backup sync=dirty-bitmap

From: Fam Zheng Signed-off-by: Fam Zheng Signed-off-by: John Snow --- tests/qemu-iotests/056| 33 ++--- tests/qemu-iotests/056.out| 4 ++-- tests/qemu-iotests/iotests.py | 8 3 files changed, 40 insertions(+), 5 deletions(-) diff --git a/test

[Qemu-devel] [PATCH v8 03/10] block: Introduce bdrv_dirty_bitmap_granularity()

From: Fam Zheng This returns the granularity (in bytes) of dirty bitmap, which matches the QMP interface and the existing query interface. Signed-off-by: Fam Zheng Signed-off-by: John Snow --- block.c | 9 +++-- include/block/block.h | 2 ++ 2 files changed, 9 insertions(+),

[Qemu-devel] [PATCH v8 06/10] qmp: Add block-dirty-bitmap-enable and block-dirty-bitmap-disable

From: Fam Zheng This allows to put the dirty bitmap into a disabled state where no more writes will be tracked. It will be used before backup or writing to persistent file. Signed-off-by: Fam Zheng Signed-off-by: John Snow --- block.c | 15 + blockdev.c|

[Qemu-devel] [PATCH v8 08/10] qapi: Add transaction support to block-dirty-bitmap-{add, enable, disable}

From: Fam Zheng This adds three qmp commands to transactions. Users can stop a dirty bitmap, start backup of it, and start another dirty bitmap atomically, so that the dirty bitmap is tracked incrementally and we don't miss any write. Signed-off-by: Fam Zheng Signed-off-by: John Snow --- blo

[Qemu-devel] [PATCH v8 05/10] block: Add bdrv_copy_dirty_bitmap and bdrv_reset_dirty_bitmap

From: Fam Zheng Signed-off-by: Fam Zheng Signed-off-by: John Snow --- block.c | 35 +++ include/block/block.h | 4 2 files changed, 35 insertions(+), 4 deletions(-) diff --git a/block.c b/block.c index c851a03..40cb9cf 100644 --- a/block.c +

[Qemu-devel] [PATCH v8 04/10] hbitmap: Add hbitmap_copy

From: Fam Zheng This makes a deep copy of an HBitmap. Signed-off-by: Fam Zheng Signed-off-by: John Snow --- include/qemu/hbitmap.h | 8 util/hbitmap.c | 16 2 files changed, 24 insertions(+) diff --git a/include/qemu/hbitmap.h b/include/qemu/hbitmap.h index

[Qemu-devel] [PATCH v8 07/10] qmp: Add support of "dirty-bitmap" sync mode for drive-backup

From: Fam Zheng For "dirty-bitmap" sync mode, the block job will iterate through the given dirty bitmap to decide if a sector needs backup (backup all the dirty clusters and skip clean ones), just as allocation conditions of "top" sync mode. There are two bitmap use modes for sync=dirty-bitmap:

[Qemu-devel] [PATCH v8 00/10] block: Incremental backup series

This is the in memory part of the incremental backup feature. With the added commands, we can create a bitmap on a block backend, from which point of time all the writes are tracked by the bitmap, marking sectors as dirty. Later, we call drive-backup and pass the bitmap to it, to do an incrementa

[Qemu-devel] [PATCH v8 02/10] qmp: Add block-dirty-bitmap-add and block-dirty-bitmap-remove

From: Fam Zheng The new command pair is added to manage user created dirty bitmap. The dirty bitmap's name is mandatory and must be unique for the same device, but different devices can have bitmaps with the same names. The granularity is an optional field. If it is not specified, we will choose

[Qemu-devel] [PATCH v8 09/10] qmp: Add dirty bitmap 'enabled' field in query-block

From: Fam Zheng Signed-off-by: Fam Zheng Signed-off-by: John Snow --- block.c | 1 + qapi/block-core.json | 5 - 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/block.c b/block.c index e341844..3ad1af3 100644 --- a/block.c +++ b/block.c @@ -5404,6 +5404,7 @@ Bloc

[Qemu-devel] [PATCH RFC v3 12/12] s390x/virtio-ccw: enable virtio 1.0

virtio-ccw should now have everything in place to operate virtio 1.0 devices, so let's enable revision 1. Signed-off-by: Cornelia Huck --- hw/s390x/virtio-ccw.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/s390x/virtio-ccw.h b/hw/s390x/virtio-ccw.h index 03d5955..08e

[Qemu-devel] [PATCH RFC v3 08/12] s390x/css: Add a callback for when subchannel gets disabled

From: Thomas Huth We need a possibility to run code when a subchannel gets disabled. This patch adds the necessary infrastructure. Signed-off-by: Thomas Huth Signed-off-by: Cornelia Huck --- hw/s390x/css.c | 12 hw/s390x/css.h |1 + 2 files changed, 13 insertions(+) diff -

[Qemu-devel] [PATCH RFC v3 07/12] dataplane: allow virtio-1 devices

Handle endianness conversion for virtio-1 virtqueues correctly. Note that dataplane now needs to be built per-target. Signed-off-by: Cornelia Huck --- hw/block/dataplane/virtio-blk.c |4 +- hw/scsi/virtio-scsi-dataplane.c |2 +- hw/virtio/Makefile.objs

[Qemu-devel] [PATCH RFC v3 06/12] virtio: allow virtio-1 queue layout

For virtio-1 devices, we allow a more complex queue layout that doesn't require descriptor table and rings on a physically-contigous memory area: add virtio_queue_set_rings() to allow transports to set this up. Signed-off-by: Cornelia Huck --- hw/virtio/virtio.c | 16

[Qemu-devel] [PATCH RFC v3 09/12] s390x/virtio-ccw: add virtio set-revision call

From: Thomas Huth Handle the virtio-ccw revision according to what the guest sets. When revision 1 is selected, we have a virtio-1 standard device with byteswapping for the virtio rings. When a channel gets disabled, we have to revert to the legacy behavior in case the next user of the device do

[Qemu-devel] [PATCH RFC v3 05/12] virtio: introduce legacy virtio devices

Introduce a helper function to indicate whether a virtio device is operating in legacy or virtio standard mode. It may be used to make decisions about the endianess of virtio accesses and other virtio-1 specific changes, enabling us to support transitional devices. Reviewed-by: Thomas Huth Sign

[Qemu-devel] [PATCH RFC v3 04/12] s390x/virtio-ccw: fix check for WRITE_FEAT

We need to check guest feature size, not host feature size to find out whether we should call virtio_set_features(). This check is possible now that vdev->guest_features is an array. Reviewed-by: Thomas Huth Signed-off-by: Cornelia Huck --- hw/s390x/virtio-ccw.c |2 +- 1 file changed, 1 ins

[Qemu-devel] [PATCH RFC v3 02/12] virtio: cull virtio_bus_set_vdev_features

The only user of this function was virtio-ccw, and it should use virtio_set_features() like everybody else: We need to make sure that bad features are masked out properly, which this function did not do. Reviewed-by: Thomas Huth Signed-off-by: Cornelia Huck --- hw/s390x/virtio-ccw.c |

[Qemu-devel] [PATCH RFC v3 03/12] virtio: support more feature bits

With virtio-1, we support more than 32 feature bits. Let's make vdev->guest_features depend on the number of supported feature bits, allowing us to grow the feature bits automatically. We also need to enhance the internal functions dealing with getting and setting features with an additional index

[Qemu-devel] [PATCH RFC v3 11/12] virtio-net/virtio-blk: enable virtio 1.0

virtio-net (non-vhost) and virtio-blk have everything in place to support virtio 1.0: let's enable the feature bit for them. Note that VIRTIO_F_VERSION_1 is technically a transport feature; once every device is ready for virtio 1.0, we can move this setting this feature bit out of the individual d

[Qemu-devel] [PATCH RFC v3 00/12] qemu: towards virtio-1 host support

Next version of virtio-1 patches for qemu. Only change from v2 is splitting out the vring accessors into a separate header file - should hopefully fix the build issues. Cornelia Huck (9): virtio: cull virtio_bus_set_vdev_features virtio: support more feature bits s390x/virtio-ccw: fix check

[Qemu-devel] [PATCH RFC v3 10/12] s390x/virtio-ccw: support virtio-1 set_vq format

Support the new CCW_CMD_SET_VQ format for virtio-1 devices. While we're at it, refactor the code a bit and enforce big endian fields (which had always been required, even for legacy). Reviewed-by: Thomas Huth Signed-off-by: Cornelia Huck --- hw/s390x/virtio-ccw.c | 114 +++

[Qemu-devel] [PATCH RFC v3 01/12] linux-headers/virtio_config: Update with VIRTIO_F_VERSION_1

From: Thomas Huth Add the new VIRTIO_F_VERSION_1 definition to the virtio_config.h linux header. Signed-off-by: Thomas Huth Signed-off-by: Cornelia Huck --- linux-headers/linux/virtio_config.h |3 +++ 1 file changed, 3 insertions(+) diff --git a/linux-headers/linux/virtio_config.h b/lin

[Qemu-devel] [PATCH for-2.3] softmmu: clarify meaning of TLB_NOTDIRTY bit

It wasn't obvious to me why the TLB entries should cache the memory dirty bitmap state. Signed-off-by: Stefan Hajnoczi --- include/exec/cpu-all.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/exec/cpu-all.h b/include/exec/cpu-all.h index c085804..e71e47e 100644 --

Re: [Qemu-devel] [PATCH 1/3] blockdev: Add read-only option to change-blockdev

On 11/26/2014 09:36 AM, Max Reitz wrote: >>> -qmp_bdrv_open_encrypted(bs, filename, bdrv_flags, drv, NULL, >>> errp); >>> +qmp_bdrv_open_encrypted(bs, filename, bdrv_flags, drv, NULL, &err); >>> + >>> +if (err) { >>> +if (read_only == BLOCKDEV_CHANGE_READ_ONLY_MODE_AUTO) { >>

Re: [Qemu-devel] [PATCH 0/4] blockdev: support dataplane in QMP 'transaction' command

On Fri, Nov 21, 2014 at 10:48:56AM +, Stefan Hajnoczi wrote: > These patches make the QMP 'transaction' command work with virtio-blk > dataplane. Each 'transaction' action must take care to acquire AioContext > around BlockDriverState accesses. Once that protection is in place we can > unbloc

Re: [Qemu-devel] [PATCH v4 3/6] block: JSON filenames and relative backing files

On 11/26/2014 09:20 AM, Max Reitz wrote: > When using a relative backing file name, qemu needs to know the > directory of the top image file. For JSON filenames, such a directory > cannot be easily determined (e.g. how do you determine the directory of > a qcow2 BDS directly on top of a quorum BDS?

Re: [Qemu-devel] [PATCH v4 1/6] checkpatch: Brace handling on multi-line condition

On 11/26/2014 09:20 AM, Max Reitz wrote: > CODING_STYLE states the following about braces around blocks: > >> The opening brace is on the line that contains the control flow >> statement that introduces the new block; [...] > > This is obviously impossible with multi-line conditions. Therefore, >

Re: [Qemu-devel] [PATCH 1/3] blockdev: Add read-only option to change-blockdev

On 2014-11-26 at 17:24, Eric Blake wrote: On 11/20/2014 05:44 AM, Max Reitz wrote: Add an option to qmp_change_blockdev() which allows changing the read-only status of the block device to be changed. Some drives do not have a inherently fixed read-only status; for instance, floppy disks can be

Re: [Qemu-devel] [PATCH 3/3] hmp: Expose read-only option for 'change'

On 11/20/2014 05:44 AM, Max Reitz wrote: > Expose the new read-only option of qmp_change_blockdev() for the > 'change' HMP command. > > Signed-off-by: Max Reitz > --- > hmp-commands.hx | 24 +--- > hmp.c | 17 - > 2 files changed, 37 insertions(+), 4

Re: [Qemu-devel] [PATCH 2/3] qmp: Expose read-only option for 'change'

On 11/20/2014 05:44 AM, Max Reitz wrote: > Expose the new read-only option of qmp_change_blockdev() for the > 'change' QMP command. Leave it unset for HMP for now. > > Signed-off-by: Max Reitz > --- > hmp.c| 2 +- > qapi-schema.json | 7 ++- > qmp-commands.hx | 24

Re: [Qemu-devel] [PATCH 1/3] blockdev: Add read-only option to change-blockdev

On 11/20/2014 05:44 AM, Max Reitz wrote: > Add an option to qmp_change_blockdev() which allows changing the > read-only status of the block device to be changed. > > Some drives do not have a inherently fixed read-only status; for > instance, floppy disks can be set read-only or writable independe

Re: [Qemu-devel] TCG Multithreading performance improvement

Mark Burton writes: > Hi all, > > We are now actively going to pursue TCG Multithreading to improve the > performance of the TCG for Qemu models that include multiple cores. > > We have set up a wiki page to track the project > http://wiki.qemu.org/Features/tcg-multithread >

[Qemu-devel] [PATCH v4 3/6] block: JSON filenames and relative backing files

When using a relative backing file name, qemu needs to know the directory of the top image file. For JSON filenames, such a directory cannot be easily determined (e.g. how do you determine the directory of a qcow2 BDS directly on top of a quorum BDS?). Therefore, do not allow relative filenames for

Re: [Qemu-devel] [PATCH v2] tests: Use "command -v" instead of which(1) in shell scripts

On Wed, Nov 19, 2014 at 03:07:12PM +0800, Fam Zheng wrote: > When which(1) is not installed, we would complain "perl not found" > because it's the first set_prog_path check. The error message is > wrong. > > Fix it by using "command -v", a native way to query the existence of a > command. > > Sug

Re: [Qemu-devel] [PATCH v3 0/9] raw: Prohibit dangerous writes for probed images

On Thu, Nov 20, 2014 at 04:27:05PM +0100, Kevin Wolf wrote: > See the commit message of patch 7 for the why and how. This series > will probably be only part of the solution and doesn't mean that we > should stop looking for other patches which improve different parts of > the problem. > > See the

[Qemu-devel] [PATCH v4 6/6] iotests: Add test for relative backing file names

Sometimes, qemu does not have a filename to work with, so it does not know which directory to use for a backing file specified by a relative filename. Add a test which tests that qemu exits with an appropriate error message. Additionally, add a test for qemu-img create with a backing filename rela

[Qemu-devel] [PATCH v4 4/6] block: Relative backing file for image creation

Relative backing filenames are always relative to the backed image's directory; the same applies to image creation. Therefore, if the backing file has to be opened for determining its size (in case the size has not been explicitly specified) its filename should be interpreted relative to the new im

[Qemu-devel] [PATCH v4 1/6] checkpatch: Brace handling on multi-line condition

CODING_STYLE states the following about braces around blocks: > The opening brace is on the line that contains the control flow > statement that introduces the new block; [...] This is obviously impossible with multi-line conditions. Therefore, CODING_STYLE does not make any clear statement about

[Qemu-devel] [PATCH v4 0/6] block: Relative backing files

Cover letter of v1: Sometimes, qemu does not have a filename to work with (it then generates a JSON filename), so it does not know which directory to use for a backing file specified by a relative filename. In this case, qemu should not somehow try to append the backing file's name to the JSON ob

[Qemu-devel] [PATCH v4 5/6] block/vmdk: Relative backing file for creation

When a vmdk image is created with a backing file, it is opened to check whether it is indeed a vmdk file by letting qemu probe it. When doing so, the backing filename is relative to the image's base directory so it should be interpreted accordingly. Signed-off-by: Max Reitz Reviewed-by: Eric Blak

[Qemu-devel] [PATCH v4 2/6] block: Get full backing filename from string

Introduce bdrv_get_full_backing_filename_from_filename(), a function which takes the name of the backed file and a potentially relative backing filename to produce the full (absolute) backing filename. Use this function from bdrv_get_full_backing_filename(). Signed-off-by: Max Reitz Reviewed-by:

Re: [Qemu-devel] [PATCH v2 0/6] nbd: Use BlockBackend

On Tue, Nov 18, 2014 at 12:21:13PM +0100, Max Reitz wrote: > From the block layer's perspective, the nbd server is pretty similar to > a guest device. Therefore, it should use BlockBackend to access block > devices, just like any other guest device does. > > This series consequently makes the nbd

Re: [Qemu-devel] [PATCH 0/3] blockdev: Add read-only option to change-blockdev

Am 20.11.2014 um 13:44 hat Max Reitz geschrieben: > The 'change' QMP and HMP command allows replacing the medium in drives > which support this, e.g. floppy disk drives. For some drives, the medium > carries information about whether it can be written to or not (again, > floppy drives). Therefore,

Re: [Qemu-devel] [2.3 PATCH v7 05/10] block: Add bdrv_copy_dirty_bitmap and bdrv_reset_dirty_bitmap

On 11/26/2014 05:43 AM, Max Reitz wrote: > On 2014-11-25 at 20:46, John Snow wrote: >> From: Fam Zheng >> >> Signed-off-by: Fam Zheng >> Signed-off-by: John Snow >> --- >> block.c | 35 +++ >> include/block/block.h | 4 >> 2 files changed,

Re: [Qemu-devel] [PATCH 0/2] ahci: small cleanups

On Thu, Nov 13, 2014 at 10:24:39AM +, Stefan Hajnoczi wrote: > Two small cleanups for QEMU 2.3: > > 1. Avoid DEBUG_AHCI bitrot > 2. Use FIS type constants instead of magic numbers > > See commit descriptions for details. > > Stefan Hajnoczi (2): > ahci: avoid #ifdef DEBUG_AHCI bitrot > a

Re: [Qemu-devel] [PATCH RESEND] Support vhd type VHD_DIFFERENCING

On Thu, Nov 06, 2014 at 10:43:50PM +0800, Xiaodong Gong wrote: > Now qemu only supports vhd type VHD_FIXED and VHD_DYNAMIC, so qemu > can't read snapshot volume of vhd, and can't support other storage > features of vhd file. > > This patch add read parent information in function "vpc_open", read >

Re: [Qemu-devel] [PATCH v3 0/2] block: Improve filename generation for blkdebug

On Tue, Nov 11, 2014 at 10:23:43AM +0100, Max Reitz wrote: > Eric has gloriously reviewed v2 of this series, and by adopting v2 > averted a kitten crisis and the need for me to find a freely usable > kitten picture (although I guess Wikipedia would have been the way to > go). I do have own pictures

Re: [Qemu-devel] [2.3 PATCH v7 02/10] qmp: Add block-dirty-bitmap-add and block-dirty-bitmap-remove

On 2014-11-26 at 16:39, John Snow wrote: On 11/26/2014 07:19 AM, Max Reitz wrote: On 2014-11-25 at 20:46, John Snow wrote: From: Fam Zheng The new command pair is added to manage user created dirty bitmap. The dirty bitmap's name is mandatory and must be unique for the same device, but di

Re: [Qemu-devel] [2.3 PATCH v7 02/10] qmp: Add block-dirty-bitmap-add and block-dirty-bitmap-remove

On 11/26/2014 07:19 AM, Max Reitz wrote: On 2014-11-25 at 20:46, John Snow wrote: From: Fam Zheng The new command pair is added to manage user created dirty bitmap. The dirty bitmap's name is mandatory and must be unique for the same device, but different devices can have bitmaps with the sa

Re: [Qemu-devel] [PATCH RESEND] Support vhd type VHD_DIFFERENCING

On Thu, Nov 06, 2014 at 10:43:50PM +0800, Xiaodong Gong wrote: > +} else if (platform == PLATFORM_W2RU) { > +/* Must be UTF16-LE to ASCII */ > +char *out, *optr; > +int j; > + > +optr = out = (char *) g_malloc(data_length + 1); > +

Re: [Qemu-devel] [RFC PATCH v5 03/31] replay: global variables and function stubs

On 11/26/2014 03:39 AM, Pavel Dovgalyuk wrote: > This patch adds global variables, defines, functions declarations, > and function stubs for deterministic VM replay used by external modules. > > Signed-off-by: Pavel Dovgalyuk > --- > +# Since: 2.3 > +## > +{ 'enum': 'ReplaySubmode', > + 'data'

Re: [Qemu-devel] [PATCH 01/12] block: qcow2 driver may not be found

Am 26.11.2014 um 16:20 hat Max Reitz geschrieben: > On 2014-11-26 at 16:19, Eric Blake wrote: > >On 11/26/2014 02:13 AM, Max Reitz wrote: > >>On 2014-11-26 at 08:23, Markus Armbruster wrote: > >>>Max Reitz writes: > >>> > Albeit absolutely impossible right now, bdrv_find_format("qcow2") may >

Re: [Qemu-devel] [PATCH 01/12] block: qcow2 driver may not be found

On 2014-11-26 at 16:19, Eric Blake wrote: On 11/26/2014 02:13 AM, Max Reitz wrote: On 2014-11-26 at 08:23, Markus Armbruster wrote: Max Reitz writes: Albeit absolutely impossible right now, bdrv_find_format("qcow2") may fail. bdrv_append_temp_snapshot() should heed that case. Impossible bec

Re: [Qemu-devel] [PATCH 01/12] block: qcow2 driver may not be found

On 11/26/2014 02:13 AM, Max Reitz wrote: > On 2014-11-26 at 08:23, Markus Armbruster wrote: >> Max Reitz writes: >> >>> Albeit absolutely impossible right now, bdrv_find_format("qcow2") may >>> fail. bdrv_append_temp_snapshot() should heed that case. >> Impossible because we always compile in bdrv

Re: [Qemu-devel] [PATCH 1/1] qmp: extend QMP to provide read/write access to physical memory

On 11/26/2014 01:41 AM, Bryan D. Payne wrote: > This patch adds a new QMP command that sets up a domain socket. This > socket can then be used for fast read/write access to the guest's > physical memory. The key benefit to this system over existing solutions > is speed. Using this patch, guest memo

Re: [Qemu-devel] [2.3 PATCH v7 10/10] qemu-iotests: Add tests for drive-backup sync=dirty-bitmap

On 2014-11-25 at 20:46, John Snow wrote: From: Fam Zheng Signed-off-by: Fam Zheng Signed-off-by: John Snow --- tests/qemu-iotests/056| 33 ++--- tests/qemu-iotests/056.out| 4 ++-- tests/qemu-iotests/iotests.py | 8 3 files changed, 40 i

Re: [Qemu-devel] [PATCH v6 1/3] linux-aio: fix submit aio as a batch

Am 25.11.2014 um 08:23 hat Ming Lei geschrieben: > In the submit path, we can't complete request directly, > otherwise "Co-routine re-entered recursively" may be caused, One more thing: Can you write a qemu-iotests case to test this code path? (Which should fail on master and be fixed with this pa

Re: [Qemu-devel] [PATCH v7 09/16] hw/vfio/platform: add vfio-platform support

On 11/26/2014 12:20 PM, Alexander Graf wrote: > > > On 26.11.14 11:48, Eric Auger wrote: >> On 11/26/2014 11:24 AM, Alexander Graf wrote: >>> >>> >>> On 26.11.14 10:45, Eric Auger wrote: On 11/05/2014 11:29 AM, Alexander Graf wrote: > > > On 31.10.14 15:05, Eric Auger wrote:

Re: [Qemu-devel] [2.3 PATCH v7 09/10] qmp: Add dirty bitmap 'enabled' field in query-block

On 2014-11-25 at 20:46, John Snow wrote: From: Fam Zheng Signed-off-by: Fam Zheng Signed-off-by: John Snow --- block.c | 1 + qapi/block-core.json | 5 - 2 files changed, 5 insertions(+), 1 deletion(-) Reviewed-by: Max Reitz I like how you dropped my R-bs even for fun

[Qemu-devel] [RFC PATCH 0/3] linux-aio: Convert to coroutines

This is my current branch for converting the linux-aio interface to coroutines. I started this as a performance optimisation, but I think it also makes it much easier to avoid the recursive coroutine reentrace that Ming Lei has sent a relatively complex callback-based patch for. See patch 3 for a q

  1   2   3   >