Re: [Qemu-devel] [PATCH v2 3/8] vhdx: Use QEMU UUID API

On Mon, Aug 08, 2016 at 02:09:23PM +0800, Fam Zheng wrote: > This removes our dependency to libuuid, so that the driver can always be > built. > > Similar to how we handled data plane configure options, --enable-vhdx > and --disable-vhdx are also changed to a nop with a message saying it's >

Re: [Qemu-devel] [PATCH RFC] block/vxhs: Initial commit to add Veritas HyperScale VxHS block device support

Hi Christopher, We are working on a sample server implementation, and will add it to libqnio soon. Thanks, Ashish On Mon, Aug 8, 2016 at 12:46 AM, Christoph Hellwig wrote: > On Sun, Jul 31, 2016 at 04:52:16PM -0700, Ashish Mittal wrote: > > This patch adds support for a new block

Re: [Qemu-devel] [PATCH V3] hw/misc: Add simple measurement hardware

Hi, Your series seems to have some coding style problems. See output below for more information: Message-id: 1470688017-1127-1-git-send-email-mj...@coreos.com Type: series Subject: [Qemu-devel] [PATCH V3] hw/misc: Add simple measurement hardware === TEST SCRIPT BEGIN === #!/bin/bash BASE=base

[Qemu-devel] [PATCH V3] hw/misc: Add simple measurement hardware

Trusted Boot is based around having a trusted store of measurement data and a secure communications channel between that store and an attestation target. In actual hardware, that's a TPM. Since the TPM can only be accessed via the host system, this in turn requires that the TPM be able to perform

Re: [Qemu-devel] [PATCH v2 1/8] util: Add UUID API

On Mon, Aug 08, 2016 at 01:07:33PM +0200, Markus Armbruster wrote: > Fam Zheng writes: > > > A number of different places across the code base use CONFIG_UUID. Some > > of them are soft dependency, some are not built if libuuid is not > > available, some come with dummy

[Qemu-devel] ANNOUNCE: libguestfs 1.34 released

I'm pleased to announce libguestfs 1.34, a library and set of tools for accessing and modifying virtual machine disk images. This release took about 8 months of work by many contributors. Amongst the new features are large performance improvements, substantial enhancements to virt-p2v & virt-v2v,

Re: [Qemu-devel] [PATCH V2] hw/misc: Add simple measurement hardware

On Fri, Aug 5, 2016 at 8:56 PM, Stefan Berger wrote: > Matthew Garrett wrote on 08/05/2016 07:17:12 PM: >> This version of the implementation depends on port io, but if there's >> interest I'll add mmio as well. > > Port io is x86 specific, right? I don't

Re: [Qemu-devel] [PATCH 0/5] blockjobs: Fix transactional race condition

I should also clarify that this is ambiguously for either 2.7 or 2.8. 2.7: This fixes a real, observable problem with transactional completion that has the capacity to hang QEMU or segfault due to QLIST corruption. 2.8: Incremental backup is not earnestly a supported feature yet as

Re: [Qemu-devel] [PATCH 0/5] blockjobs: Fix transactional race condition

Hi, Your series seems to have some coding style problems. See output below for more information: Message-id: 1470683381-16680-1-git-send-email-js...@redhat.com Type: series Subject: [Qemu-devel] [PATCH 0/5] blockjobs: Fix transactional race condition === TEST SCRIPT BEGIN === #!/bin/bash

[Qemu-devel] [PATCH 3/5] blockjob: refactor backup_start as backup_job_create

Refactor backup_start as backup_job_create, which only creates the job, but does not automatically start it. The old interface, 'backup_start', is not kept in favor of limiting the number of nearly-identical iterfaces that would have to be edited to keep up with QAPI changes in the future.

[Qemu-devel] [PATCH 5/5] iotests: add transactional failure race test

Add a regression test for the case found by Vladimir. Reported-by: Vladimir Sementsov-Ogievskiy Signed-off-by: John Snow --- tests/qemu-iotests/124 | 91 ++ tests/qemu-iotests/124.out | 4 +- 2 files

[Qemu-devel] [PATCH 2/5] blockjob: add block_job_start

Instead of automatically starting jobs at creation time via backup_start et al, we'd like to return a job object pointer that can be started manually at later point in time. For now, add the block_job_start mechanism and start the jobs automatically as we have been doing, with conversions

[Qemu-devel] [PATCH 0/5] blockjobs: Fix transactional race condition

There are a few problems with transactional job completion right now. First, if jobs complete so quickly they complete before remaining jobs get a chance to join the transaction, the completion mode can leave well known state and the QLIST can get corrupted and the transactional jobs can complete

[Qemu-devel] [PATCH 4/5] blockjob: add .clean property

Cleaning up after we have deferred to the main thread but before the transaction has converged can be dangerous and result in deadlocks if the job cleanup invokes any BH polling loops. A job may attempt to begin cleaning up, but may induce another job to enter its cleanup routine. The second job,

[Qemu-devel] [PATCH 1/5] blockjob: fix dead pointer in txn list

From: Vladimir Sementsov-Ogievskiy Though it is not intended to be reached through normal circumstances, if we do not gracefully deconstruct the transaction QLIST, we may wind up with stale pointers in the list. The rest of this series attempts to address the

Re: [Qemu-devel] Qemu tracing documentation

On Mon, Aug 8, 2016 at 6:56 PM, Gadre Nayan wrote: > Quoting from the documentation for qemu tracing: > docs/tracing.txt: > > " > === Analyzing trace files > The "simple" backend produces binary trace files that can be formatted with > the > simpletrace.py script. The

Re: [Qemu-devel] [PATCH V5 1/6] oslib-posix: add helpers for stack alloc and free

Am 08.08.2016 um 12:37 schrieb Stefan Hajnoczi: > On Tue, Jul 12, 2016 at 06:23:01PM +0200, Peter Lieven wrote: >> the allocated stack will be adjusted to the minimum supported stack size >> by the OS and rounded up to be a multiple of the system pagesize. >> Additionally an architecture dependent

[Qemu-devel] [PATCH v7 3/4] blockdev: Add dynamic module loading for block drivers

From: Marc Mari Extend the current module interface to allow for block drivers to be loaded dynamically on request. The only block drivers that can be converted into modules are the drivers that don't perform any init operation except for registering themselves. In addition,

[Qemu-devel] [PATCH v7 4/4] blockdev: Modularize nfs block driver

Modularizes the nfs block driver so that it gets dynamically loaded. Signed-off-by: Colin Lord Reviewed-by: Stefan Hajnoczi --- block/Makefile.objs | 1 + configure | 4 ++-- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git

[Qemu-devel] [PATCH v7 2/4] blockdev: Add dynamic generation of module_block.h

From: Marc Mari To simplify the addition of new block modules, add a script that generates module_block.h automatically from the modules' source code. This script assumes that the QEMU coding style rules are followed. Signed-off-by: Marc Marí

[Qemu-devel] [PATCH v7 1/4] blockdev: prepare iSCSI block driver for dynamic loading

This commit moves the initialization of the QemuOptsList qemu_iscsi_opts struct out of block/iscsi.c in order to allow the iscsi module to be dynamically loaded. Signed-off-by: Colin Lord Reviewed-by: Fam Zheng --- block/iscsi.c | 36

[Qemu-devel] [PATCH v7 0/4] Dynamic module loading for block drivers

One more minor revision from v6, no big changes. v7: - Add ifdef around qemu_iscsi_opts in vl.c (first patch) v6: - Fix bug so that users can specify a modularized driver on the cli without qemu exiting - Remove extra lines from Makefile - Add patch to modularize NFS v5: - No format drivers

Re: [Qemu-devel] [PATCH for-2.7] pc-bios/optionrom: Fix OpenBSD build with better detection of linker emulation

On 08/08/16 10:11, Peter Maydell wrote: > The various host OSes are irritatingly variable about the name > of the linker emulation we need to pass to ld's -m option to > build the i386 option ROMs. Instead of doing this via a > CONFIG ifdef, check in configure whether any of the emulation >

Re: [Qemu-devel] [PATCH v3 00/15] qapi: remove the 'middle' mode

On Mon, Aug 8, 2016 at 6:57 PM wrote: > Hi, > > Your series seems to have some coding style problems. See output below for > more information: > While at it, I guess I could remove those trailing spaces too > > Message-id:

Re: [Qemu-devel] [Qemu-block] [PATCH v6 1/4] blockdev: prepare iSCSI block driver for dynamic loading

On 08/08/2016 11:18 AM, Stefan Hajnoczi wrote: > On Tue, Aug 02, 2016 at 10:12:14AM -0400, Colin Lord wrote: >> diff --git a/vl.c b/vl.c >> index e7c2c62..1a5f807 100644 >> --- a/vl.c >> +++ b/vl.c >> @@ -506,6 +506,41 @@ static QemuOptsList qemu_fw_cfg_opts = { >> }, >> }; >> >> +static

[Qemu-devel] Unreviewable bsd-user code bomb

I've forked a branch of master in my github repo and only merged in the needed bsd-user changes (or at least what I think are the needed changes). https://github.com/seanbruno/qemu-bsd-user/tree/qemu-merge-bsd-user The diffstat is still out of control, but the damage is contained to bsd-user

Re: [Qemu-devel] [Patch v2 00/29] s390x CPU models: exposing features

On Mon, Aug 08, 2016 at 09:45:04AM -0700, no-re...@ec2-52-6-146-230.compute-1.amazonaws.com wrote: > Hi, > > Your series seems to have some coding style problems. See output below for > more information: [...] Does anybody know who owns this robot? -- Eduardo

Re: [Qemu-devel] [Patch v2 00/29] s390x CPU models: exposing features

> On Mon, 8 Aug 2016 09:45:04 -0700 (PDT) > no-re...@patchew.org wrote: > > something sensible, e.g. qemu-devel> > > > Checking PATCH 4/29: s390x/cpumodel: introduce CPU features... > > WARNING: line over 80 characters > > #65: FILE: target-s390x/cpu_features.c:27: > > +FEAT_INIT("zarch",

Re: [Qemu-devel] [PATCH for-2.7] pc-bios/optionrom: Fix OpenBSD build with better detection of linker emulation

On 8 August 2016 at 17:11, Peter Maydell wrote: > The various host OSes are irritatingly variable about the name > of the linker emulation we need to pass to ld's -m option to > build the i386 option ROMs. Instead of doing this via a > CONFIG ifdef, check in configure

Re: [Qemu-devel] [Patch v2 00/29] s390x CPU models: exposing features

On Mon, 8 Aug 2016 09:45:04 -0700 (PDT) no-re...@patchew.org wrote: > Checking PATCH 4/29: s390x/cpumodel: introduce CPU features... > WARNING: line over 80 characters > #65: FILE: target-s390x/cpu_features.c:27: > +FEAT_INIT("zarch", S390_FEAT_TYPE_STFL, 1, "z/Architecture architectural >

Re: [Qemu-devel] [RFC PATCH v2 0/2] GICv3 live migration support

Hi, Your series seems to have some coding style problems. See output below for more information: Message-id: 1470675071-23677-1-git-send-email-vijay.kil...@gmail.com Type: series Subject: [Qemu-devel] [RFC PATCH v2 0/2] GICv3 live migration support === TEST SCRIPT BEGIN === #!/bin/bash

Re: [Qemu-devel] [RFC PATCH v2 2/2] hw/intc/arm_gicv3_kvm: Implement get/put functions

On 8 August 2016 at 17:51, wrote: > From: Vijaya Kumar K > > This actually implements pre_save and post_load methods for in-kernel > vGICv3. > > Signed-off-by: Pavel Fedin > Signed-off-by: Peter Maydell

[Qemu-devel] [RFC PATCH v2 1/2] kernel: Add definitions for GICv3 attributes

From: Vijaya Kumar K This temporary patch adds kernel API definitions. Use proper header update procedure after these features are released. Signed-off-by: Pavel Fedin --- linux-headers/asm-arm64/kvm.h | 17 ++--- 1 file changed, 14

[Qemu-devel] [RFC PATCH v2 2/2] hw/intc/arm_gicv3_kvm: Implement get/put functions

From: Vijaya Kumar K This actually implements pre_save and post_load methods for in-kernel vGICv3. Signed-off-by: Pavel Fedin Signed-off-by: Peter Maydell [PMM: * use decimal, not 0bnnn * fixed typo in names of

[Qemu-devel] [RFC PATCH v2 0/2] GICv3 live migration support

From: Vijaya Kumar K This series introduces support for GICv3 live migration with new VGIC implementation in 4.7-rc3 kernel. In this series, patch 1 of the previous implementation are ported. https://lists.nongnu.org/archive/html/qemu-devel/2015-10/msg05284.html Patch

Re: [Qemu-devel] [Patch v2 00/29] s390x CPU models: exposing features

Hi, Your series seems to have some coding style problems. See output below for more information: Message-id: 1470670378-53732-1-git-send-email-d...@linux.vnet.ibm.com Type: series Subject: [Qemu-devel] [Patch v2 00/29] s390x CPU models: exposing features === TEST SCRIPT BEGIN === #!/bin/bash

Re: [Qemu-devel] R: [PATCH v2] Unbreak FreeBSD build after optionrom update.

On 6 August 2016 at 21:59, Brad Smith wrote: > This breaks the build on OpenBSD.. > > ld: unrecognised emulation mode: elf_i386_fbsd > Supported emulations: elf_x86_64_obsd elf_i386_obsd elf_i386 > gmake[1]: *** [Makefile:55: multiboot.img] Error 1 Sorry about that; I've just

[Qemu-devel] [Patch v2 21/29] s390x/kvm: implement CPU model support

Let's implement our two hooks so we can support CPU models. Acked-by: Cornelia Huck Signed-off-by: David Hildenbrand --- target-s390x/cpu_models.c | 75 +++- target-s390x/cpu_models.h | 50 target-s390x/kvm.c| 295

[Qemu-devel] [Patch v2 26/29] qmp: add QMP interface "query-cpu-model-baseline"

Let's provide a standardized interface to baseline two CPU models, to create a third, compatible one. This is especially helpful when two CPU models are not identical, but a CPU model is required that is guaranteed to run under both configurations, where the original models run.

Re: [Qemu-devel] [PATCH v2] trace: add syslog tracing backend

On Thu, Aug 04, 2016 at 02:44:14PM +0100, Paul Durrant wrote: > This patch adds a tracing backend which sends output using syslog(). > The syslog backend is limited to POSIX compliant systems. > > openlog() is called with facility set to LOG_DAEMON, with the LOG_PID > option. Trace events are

[Qemu-devel] [PATCH for-2.7] pc-bios/optionrom: Fix OpenBSD build with better detection of linker emulation

The various host OSes are irritatingly variable about the name of the linker emulation we need to pass to ld's -m option to build the i386 option ROMs. Instead of doing this via a CONFIG ifdef, check in configure whether any of the emulation names we know about will work and pass the right answer

[Qemu-devel] [Patch v2 24/29] qmp: add QMP interface "query-cpu-model-expansion"

Let's provide a standardized interface to expand CPU models. This interface can be used by tooling to get details about a specific CPU model in a certain configuration, e.g. about the "host" model. To take care of all architectures, two detail levels for an expansion are introduced. Certain

[Qemu-devel] [Patch v2 28/29] s390x/cpumodel: implement QMP interface "query-cpu-model-comparison"

Let's implement that interface by reusing our convertion code implemented for expansion. We use CPU generations and CPU features to calculate the result. This means, that a zEC12 cannot simply be converted into a z13 by stripping of features. This is required, as other magic values (e.g. maximum

[Qemu-devel] [Patch v2 25/29] qmp: add QMP interface "query-cpu-model-comparison"

Let's provide a standardized interface to compare two CPU models. "query-cpu-model-compare" takes two models and returns how they compare in a specific configuration. The result will give guarantees about runnability. E.g. if a CPU model A is a subset of CPU model B, model A is guaranteed to run

[Qemu-devel] [Patch v2 05/29] s390x/cpumodel: generate CPU feature lists for CPU models

From: Michael Mueller This patch introduces the helper "gen-features" which allows to generate feature list definitions at compile time. Its flexibility is better and the error-proneness is lower when compared to static programming time added statements. The helper

[Qemu-devel] [Patch v2 19/29] linux-headers: update against kvm/next

Update against 29b4817d4018 ("Linux 4.8-rc1") Acked-by: Cornelia Huck Signed-off-by: David Hildenbrand --- include/standard-headers/linux/input-event-codes.h | 32 + include/standard-headers/linux/input.h | 1 +

[Qemu-devel] [Patch v2 22/29] s390x/kvm: disable host model for existing compat machines

Compatibility machines that touch runtime-instrumentation should not be used with the CPU model. Otherwise the host model will look different, depending on the QEMU machine QEMU has been started with. So let's simply disable the host model for existing compatibility machines that all disable ri.

[Qemu-devel] [Patch v2 02/29] s390x/cpumodel: "host" and "qemu" as CPU subclasses

This patch introduces two CPU models, "host" and "qemu". "qemu" is used as default when running under TCG. "host" is used as default when running under KVM. "host" cannot be used without KVM. "host" is not migration-safe. They both inherit from the base s390x CPU, which is turned into an abstract

Re: [Qemu-devel] [PATCH v3 kernel 0/7] Extend virtio-balloon for fast (de)inflating & fast live migration

On 08/07/2016 11:35 PM, Liang Li wrote: > Dave Hansen suggested a new scheme to encode the data structure, > because of additional complexity, it's not implemented in v3. FWIW, I don't think it takes any additional complexity here, at least in the guest implementation side. The thing I suggested

[Qemu-devel] [Patch v2 20/29] s390x/kvm: allow runtime-instrumentation for "none" machine

To be able to query the correct host model for the "none" machine, let's allow runtime-instrumentation for that machine. Acked-by: Cornelia Huck Signed-off-by: David Hildenbrand --- hw/s390x/s390-virtio-ccw.c | 5 + 1 file changed, 5

[Qemu-devel] [Patch v2 07/29] s390x/cpumodel: introduce CPU feature group definitions

Let's use the generated groups to create feature group representations for the user. These groups can later be used to enable/disable multiple features in one shot and will be used to reduce the amount of reported features to the user if all subfeatures are in place. Acked-by: Cornelia Huck

[Qemu-devel] [Patch v2 08/29] s390x/cpumodel: register defined CPU models as subclasses

This patch adds the CPU model definitions that are known on s390x - like z900, zBC12 or z13. For each definition, introduce two CPU models: 1. Base model (e.g. z13-base): Minimum feature set we expect to be around on all z13 systems. These models are migration-safe and will never change. 2.

[Qemu-devel] [Patch v2 04/29] s390x/cpumodel: introduce CPU features

From: Michael Mueller The patch introduces s390x CPU features (most of them refered to as facilities) along with their discription and some functions that will be helpful when working with the features later on. Please note that we don't introduce all known CPU

[Qemu-devel] [Patch v2 16/29] s390x/sclp: propagate the ibc val(lowest and unblocked ibc)

If we have a lowest ibc, we can indicate the ibc to the guest. Acked-by: Cornelia Huck Signed-off-by: David Hildenbrand --- hw/s390x/sclp.c | 2 ++ include/hw/s390x/sclp.h | 3 ++- target-s390x/cpu_models.c | 21

[Qemu-devel] [Patch v2 09/29] s390x/cpumodel: store the CPU model in the CPU instance

A CPU model consists of a CPU definition, to which delta changes are applied - features added or removed (e.g. z13-base,vx=on). In addition, certain properties (e.g. cpu id) can later on change during migration but belong into the CPU model. This data will later be filled from the host model in

[Qemu-devel] [Patch v2 11/29] s390x/cpumodel: let the CPU model handle feature checks

If we have certain features enabled, we have to migrate additional state (e.g. vector registers or runtime-instrumentation registers). Let the CPU model control that unless we have no "host" CPU model in the KVM case. This will later on be the case for compatibility machines, so migration from

[Qemu-devel] [Patch v2 00/29] s390x CPU models: exposing features

After another very helpful discussion with Eduardo and Jiri and the lates review, these were the major changes: - QOM interfaces: Only documentation changes - Minor s390x specific implementation fixups - Renamed some s390x features, sthyi added to the default + max models Full list of changes can

[Qemu-devel] [Patch v2 23/29] s390x/kvm: let the CPU model control CMM(A)

Starting with recent kernels, if the cmma attributes are available, we actually have hardware support. Enabling CMMA then means providing the guest VCPU with CMM, therefore enabling its CMM facility. Let's not blindly enable CMM anymore but let's control it using CPU models. For disabled CPU

Re: [Qemu-devel] [Qemu-block] [PATCH v6 2/4] blockdev: Add dynamic generation of module_block.h

On Tue, Aug 02, 2016 at 10:12:15AM -0400, Colin Lord wrote: > From: Marc Mari > > To simplify the addition of new block modules, add a script that generates > module_block.h automatically from the modules' source code. > > This script assumes that the QEMU coding style rules

[Qemu-devel] [Patch v2 27/29] s390x/cpumodel: implement QMP interface "query-cpu-model-expansion"

In order to expand CPU models, we create temporary cpus that handle the feature/group parsing. Only CPU feature properties are expanded. When converting the data structure back, we always fall back to the static base CPU model, which is by definition migration-safe. Acked-by: Cornelia Huck

[Qemu-devel] [Patch v2 03/29] s390x/cpumodel: expose CPU class properties

Let's expose the description and migration safety and whether a definition is static, as class properties, this can be helpful in the future. Acked-by: Cornelia Huck Signed-off-by: David Hildenbrand --- target-s390x/cpu.c| 1 +

[Qemu-devel] [Patch v2 14/29] s390x/sclp: introduce sclp feature blocks

The sclp "read cpu info" and "read scp info" commands can include features for the cpu info and configuration characteristics (extended), decribing some advanced features available in the configuration. Acked-by: Cornelia Huck Signed-off-by: David Hildenbrand

[Qemu-devel] [Patch v2 13/29] s390x/sclp: factor out preparation of cpu entries

Let's factor out the common code of "read cpu info" and "read scp info". This will make the introduction of new cpu entry fields easier. Acked-by: Cornelia Huck Signed-off-by: David Hildenbrand --- hw/s390x/sclp.c | 22 --

Re: [Qemu-devel] [Qemu-block] [PATCH v6 4/4] blockdev: Modularize nfs block driver

On Tue, Aug 02, 2016 at 10:12:17AM -0400, Colin Lord wrote: > Modularizes the nfs block driver so that it gets dynamically loaded. > --- > block/Makefile.objs | 1 + > configure | 4 ++-- > 2 files changed, 3 insertions(+), 2 deletions(-) Reviewed-by: Stefan Hajnoczi

[Qemu-devel] [PATCH 02/29] tests: add hbitmap iter test

Test that hbitmap iter is resistant to bitmap resetting. Signed-off-by: Vladimir Sementsov-Ogievskiy Signed-off-by: Denis V. Lunev --- tests/test-hbitmap.c | 19 +++ 1 file changed, 19 insertions(+) diff --git a/tests/test-hbitmap.c

[Qemu-devel] [Patch v2 17/29] s390x/sclp: propagate the mha via sclp

The mha is provided in the CPU model, so get any CPU and extract the value. Acked-by: Cornelia Huck Signed-off-by: David Hildenbrand --- hw/s390x/sclp.c | 1 + include/hw/s390x/sclp.h | 3 ++- target-s390x/cpu_models.c | 14

[Qemu-devel] [Patch v2 29/29] s390x/cpumodel: implement QMP interface "query-cpu-model-baseline"

Let's implement that interface by reusing our conversion code and lookup code for CPU definitions. In order to find a compatible CPU model, we first detect the maximum possible CPU generation and then try to find a maximum model, satisfying all base features (not exceeding the maximum

Re: [Qemu-devel] [Qemu-block] [PATCH v6 1/4] blockdev: prepare iSCSI block driver for dynamic loading

On Tue, Aug 02, 2016 at 10:12:14AM -0400, Colin Lord wrote: > diff --git a/vl.c b/vl.c > index e7c2c62..1a5f807 100644 > --- a/vl.c > +++ b/vl.c > @@ -506,6 +506,41 @@ static QemuOptsList qemu_fw_cfg_opts = { > }, > }; > > +static QemuOptsList qemu_iscsi_opts = { > +.name = "iscsi", >

[Qemu-devel] [PATCH 29/29] qcow2-dirty-bitmap: refcounts

Calculate refcounts for dirty bitmaps. Signed-off-by: Vladimir Sementsov-Ogievskiy Signed-off-by: Denis V. Lunev --- block/qcow2-bitmap.c | 58 -- block/qcow2-refcount.c | 14 +++-

[Qemu-devel] [Patch v2 15/29] s390x/sclp: indicate sclp features

We have three different blocks in the SCLP read-SCP information response that indicate sclp features. Let's prepare propagation. Acked-by: Cornelia Huck Signed-off-by: David Hildenbrand --- hw/s390x/sclp.c | 9 +

[Qemu-devel] [Patch v2 12/29] s390x/cpumodel: check and apply the CPU model

We have to test if a configured CPU model is runnable in the current configuration, and if not report why that is the case. This is done by comparing it to the maximum supported model (host for KVM or z900 for TCG). Also, we want to do some base sanity checking for a configured CPU model. We'll

[Qemu-devel] [Patch v2 01/29] qmp: details about CPU definitions in query-cpu-definitions

It might be of interest for tooling whether a CPU definition can be safely used when migrating, or if e.g. CPU features might get lost during migration when migrationg from/to a different QEMU version or host, even if the same compatibility machine is used. Also, we want to know if a CPU

Re: [Qemu-devel] e1000 not fully implemented

On Thu, Jul 28, 2016 at 09:04:30PM +0530, Gadre Nayan wrote: > Hi everyone, > > I am trying to get my Host Ubuntu Machines kernel and initrd to run in > QEMU as well. > > Basically I have Host Ubuntu 16.04, with Linux kernel 4.4.13. I > compiled the kernel (make, make modules modules_install,

[Qemu-devel] [PATCH 21/29] qcow2-bitmap: add EXTRA_DATA_COMPATIBLE flag

If this flag is unset and extra data is present the bitmap should be read-only. For now just return error for this case. Signed-off-by: Vladimir Sementsov-Ogievskiy --- block/qcow2-bitmap.c | 8 1 file changed, 8 insertions(+) diff --git

[Qemu-devel] [Patch v2 18/29] s390x/sclp: propagate hmfai

hmfai is provided on CPU models >= z196. Let's propagate it properly. Acked-by: Cornelia Huck Signed-off-by: David Hildenbrand --- hw/s390x/sclp.c | 1 + include/hw/s390x/sclp.h | 3 ++- target-s390x/cpu_models.c | 14

[Qemu-devel] [PATCH 26/29] iotests: test qcow2 persistent dirty bitmap

Signed-off-by: Vladimir Sementsov-Ogievskiy --- tests/qemu-iotests/160| 87 +++ tests/qemu-iotests/160.out| 5 +++ tests/qemu-iotests/group | 1 + tests/qemu-iotests/iotests.py | 6 +++ 4 files changed, 99

Re: [Qemu-devel] [PULL for-2.7 0/2] Monitor patches for 2016-08-08

On 8 August 2016 at 13:27, Markus Armbruster <arm...@redhat.com> wrote: > The following changes since commit cbda16c010a2e1e7cd6e5441cef87663fbe1ef75: > > Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-2.7-20160808' > into staging (2016-08-08 11:32:01 +0100)

[Qemu-devel] [PATCH 28/29] qcow2-bitmap: do not try reloading bitmaps

Sometimes image is being reopened without removing bdrv state and therefore bitmaps. So here we allow not loading qcow2 bitmap if it already exists. It may lead to problem, if existing of such bitmap is a mistake - this mistake would be skipped. Signed-off-by: Vladimir Sementsov-Ogievskiy

[Qemu-devel] [Patch v2 10/29] s390x/cpumodel: expose features and feature groups as properties

Let's add all features and feature groups as properties to all CPU models. If the "host" CPU model is unknown, we can neither query nor change features. KVM will just continue to work like it did until now. We will not allow to enable features that were not part of the original CPU model, because

[Qemu-devel] [PATCH 08/29] qcow2-bitmap: delete bitmap from qcow2 after load

If we load bitmap for r/w bds, it's data in the image should be considered inconsistent from this point. Therefore it is safe to remove it from the image. Signed-off-by: Vladimir Sementsov-Ogievskiy --- block/qcow2-bitmap.c | 227

[Qemu-devel] [PATCH 25/29] qapi: add md5 checksum of last dirty bitmap level to query-block

Reviewed-by: John Snow Reviewed-by: Eric Blake Signed-off-by: Vladimir Sementsov-Ogievskiy --- block/dirty-bitmap.c | 1 + include/qemu/hbitmap.h | 8 qapi/block-core.json | 5 - util/hbitmap.c | 8

[Qemu-devel] [Patch v2 06/29] s390x/cpumodel: generate CPU feature group lists

Feature groups will be very helpful to reduce the amount of features typically available in sane configurations. E.g. the MSA facilities introduced loads of subfunctions, which could - in theory - go away in the future, but we want to avoid reporting hundrets of features to the user if usually all

[Qemu-devel] [PATCH] trace-events: fix first line comment in trace-events

Documentation is docs/tracing.txt instead of docs/trace-events.txt. find . -name trace-events -exec \ sed -i "s?See docs/trace-events.txt for syntax documentation.?See docs/tracing.txt for syntax documentation.?" \ {} \; Signed-off-by: Laurent Vivier ---

[Qemu-devel] [PATCH 27/29] qcow2-bitmap: delete in_use bitmaps on image load

Signed-off-by: Vladimir Sementsov-Ogievskiy Signed-off-by: Denis V. Lunev --- block/qcow2-bitmap.c | 95 1 file changed, 95 insertions(+) diff --git a/block/qcow2-bitmap.c b/block/qcow2-bitmap.c

[Qemu-devel] [PATCH 05/29] qcow2-bitmap: structs and consts

Create block/qcow2-bitmap.c Add data structures and constraints accordingly to docs/specs/qcow2.txt Signed-off-by: Vladimir Sementsov-Ogievskiy --- block/Makefile.objs | 2 +- block/qcow2-bitmap.c | 47 +++ block/qcow2.h

Re: [Qemu-devel] [Qemu-block] [PATCH v6 3/4] blockdev: Add dynamic module loading for block drivers

On Tue, Aug 02, 2016 at 10:12:16AM -0400, Colin Lord wrote: > Extend the current module interface to allow for block drivers to be > loaded dynamically on request. The only block drivers that can be > converted into modules are the drivers that don't perform any init > operation except for

[Qemu-devel] [PATCH 13/29] qcow2: add dirty bitmaps extension

Add dirty bitmap extension as specified in docs/specs/qcow2.txt. Load bitmap headers on open. Handle close and update_header. Handle resize: just delete all bitmaps from the image. Not loaded bitmaps will be lost (for now - all except autoloading ones). This may be fixed in future.

[Qemu-devel] [PATCH 03/29] block: fix bdrv_dirty_bitmap_granularity signature

Make getter signature const-correct. This allows other functions with const dirty bitmap parameter use bdrv_dirty_bitmap_granularity(). Reviewed-by: Eric Blake Reviewed-by: John Snow Signed-off-by: Vladimir Sementsov-Ogievskiy ---

[Qemu-devel] [PATCH 19/29] block/dirty-bitmap: add autoload field to BdrvDirtyBitmap

Add a new field. For now it is meaningless. Will be used in future patches. Signed-off-by: Vladimir Sementsov-Ogievskiy Signed-off-by: Denis V. Lunev --- block/dirty-bitmap.c | 14 ++ include/block/dirty-bitmap.h | 2 ++ 2 files

Re: [Qemu-devel] QEMU-guestOS latencies.

On Thu, Jul 28, 2016 at 09:25:41AM +, Nir Levy wrote: > in addition I wish to understand ram allocation and avoid host swaps. I didn't read everything but this stood out. QEMU has a -realtime mlock=on option if you wish to mlock(2) guest memory on the host. Stefan signature.asc

[Qemu-devel] [PATCH 09/29] qcow2-bitmap: add qcow2_bitmap_store()

This function stores block dirty bitmap to qcow2. If the bitmap with the same name, size and granularity already exists, it will be rewritten, if the bitmap with the same name exists but granularity or size does not match, an error will be generated. Signed-off-by: Vladimir Sementsov-Ogievskiy

[Qemu-devel] [PATCH 07/29] qcow2-bitmap: add qcow2_bitmap_load()

This function loads block dirty bitmap from qcow2. Signed-off-by: Vladimir Sementsov-Ogievskiy --- block/qcow2-bitmap.c | 165 ++ block/qcow2.c | 2 + block/qcow2.h | 3 +

[Qemu-devel] [PATCH 22/29] qmp: add persistent flag to block-dirty-bitmap-add

Add optional 'persistent' flag to qmp command block-dirty-bitmap-add. Default is false. Signed-off-by: Vladimir Sementsov-Ogievskiy Signed-off-by: Denis V. Lunev --- blockdev.c | 12 +++- qapi/block-core.json | 3 ++-

[Qemu-devel] [PATCH v6 00/29] qcow2: persistent dirty bitmaps

v6: https://src.openvz.org/users/vsementsov/repos/qemu/browse?at=refs%2Ftags%2Fqcow2-bitmap-v6 based on block-next (https://github.com/XanClic/qemu/commits/block-next) There are a lot of changes, reorderings and additions in comparement with v5. One principal thing: now bitmaps are removed from

[Qemu-devel] [PATCH 18/29] qcow2-bitmap: disallow storing bitmap to other bs

Check, that bitmap is stored to the owning bs. Signed-off-by: Vladimir Sementsov-Ogievskiy --- block/dirty-bitmap.c | 12 block/qcow2-bitmap.c | 5 + include/block/dirty-bitmap.h | 2 ++ 3 files changed, 19 insertions(+) diff --git

[Qemu-devel] [PATCH 12/29] qcow2: add qcow2_delete_bitmaps

Add function to delete dirty bitmaps from image. It will be used in truncate. Signed-off-by: Vladimir Sementsov-Ogievskiy Signed-off-by: Denis V. Lunev --- block/qcow2-bitmap.c | 34 ++ block/qcow2.h| 1 + 2

[Qemu-devel] [PATCH 24/29] qcow2-bitmap: maintian BlockDirtyBitmap.autoload

Sync qcow2 dirty bitmap autload flag and BlockDirtyBitmap autoload flag Signed-off-by: Vladimir Sementsov-Ogievskiy Signed-off-by: Denis V. Lunev --- block/qcow2-bitmap.c | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git

[Qemu-devel] [PATCH 11/29] qcow2-bitmap: check constraints

Check bitmap header constraints as specified in docs/specs/qcow2.txt Signed-off-by: Vladimir Sementsov-Ogievskiy --- block/qcow2-bitmap.c | 39 +++ 1 file changed, 39 insertions(+) diff --git a/block/qcow2-bitmap.c

[Qemu-devel] [PATCH 20/29] qcow2-bitmap: add AUTO flag

The bitmap should be auto-loaded if auto flag is set. Signed-off-by: Vladimir Sementsov-Ogievskiy --- block/qcow2-bitmap.c | 40 +++- 1 file changed, 39 insertions(+), 1 deletion(-) diff --git a/block/qcow2-bitmap.c

[Qemu-devel] [PATCH 15/29] block/dirty-bitmap: introduce persistent bitmaps

Add field 'persistent' to BdrvDirtyBitmap. Store all persistent bitmaps of the BDS in bdrv_close(). Signed-off-by: Vladimir Sementsov-Ogievskiy --- block.c | 2 ++ block/dirty-bitmap.c | 42 ++

<    1   2   3   4   >