[PATCH v2 01/14] qapi: Rename (one) qjson.h to qobject-json.h
We have two different JSON visitors in the tree; and having both
named 'qjson.h' can cause include confusion. Rename the qapi
version.
Why did I pick that one? A later patch plans on deleting the
top-level qjson.c once we have a native JSON output visitor; we
could have renamed that one for less overall churn. On the other
hand, all of the QObject subtypes have their own qFOO.c file, but
qjson.c makes it sound like we have a QTYPE_JSON subclass of
QObject; the new name of qobject-json makes it obvious that the
file is used for conversions between QObject and JSON, and not a
QObject subtype.
Kill trailing whitespace in the renamed tests/check-qobject-json.c
to keep checkpatch.pl happy.
Signed-off-by: Eric Blake <ebl...@redhat.com>
Reviewed-by: Paolo Bonzini <pbonz...@redhat.com>
---
v2: retitle, enhance commit message, rebase to master
---
MAINTAINERS | 2 +-
balloon.c | 2 +-
block.c | 2 +-
block/archipelago.c | 2 +-
block/nbd.c | 2 +-
block/quorum.c| 2 +-
blockjob.c| 2 +-
hw/core/qdev.c| 2 +-
hw/misc/pvpanic.c | 2 +-
hw/net/virtio-net.c | 2 +-
include/qapi/qmp/{qjson.h => qobject-json.h} | 0
include/qapi/qmp/types.h | 2 +-
monitor.c | 2 +-
qapi/qmp-event.c | 2 +-
qemu-img.c| 2 +-
qga/main.c| 2 +-
qobject/Makefile.objs | 3 ++-
qobject/{qjson.c => qobject-json.c} | 2 +-
target-s390x/kvm.c| 2 +-
tests/.gitignore | 2 +-
tests/Makefile| 8
tests/{check-qjson.c => check-qobject-json.c} | 14 +++---
tests/libqtest.c | 2 +-
ui/spice-core.c | 2 +-
vl.c | 2 +-
25 files changed, 34 insertions(+), 33 deletions(-)
rename include/qapi/qmp/{qjson.h => qobject-json.h} (100%)
rename qobject/{qjson.c => qobject-json.c} (99%)
rename tests/{check-qjson.c => check-qobject-json.c} (99%)
diff --git a/MAINTAINERS b/MAINTAINERS
index 55a0fd8..81fd039 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1155,7 +1155,7 @@ X: include/qapi/qmp/dispatch.h
F: tests/check-qdict.c
F: tests/check-qfloat.c
F: tests/check-qint.c
-F: tests/check-qjson.c
+F: tests/check-qobject-json.c
F: tests/check-qlist.c
F: tests/check-qstring.c
T: git git://repo.or.cz/qemu/qmp-unstable.git queue/qmp
diff --git a/balloon.c b/balloon.c
index 0f45d1b..5983b4f 100644
--- a/balloon.c
+++ b/balloon.c
@@ -31,7 +31,7 @@
#include "trace.h"
#include "qmp-commands.h"
#include "qapi/qmp/qerror.h"
-#include "qapi/qmp/qjson.h"
+#include "qapi/qmp/qobject-json.h"
static QEMUBalloonEvent *balloon_event_fn;
static QEMUBalloonStatus *balloon_stat_fn;
diff --git a/block.c b/block.c
index 411edbf..0b7eb00 100644
--- a/block.c
+++ b/block.c
@@ -30,7 +30,7 @@
#include "qemu/module.h"
#include "qapi/qmp/qerror.h"
#include "qapi/qmp/qbool.h"
-#include "qapi/qmp/qjson.h"
+#include "qapi/qmp/qobject-json.h"
#include "sysemu/block-backend.h"
#include "sysemu/sysemu.h"
#include "qemu/notify.h"
diff --git a/block/archipelago.c b/block/archipelago.c
index 855655c..80a1bb5 100644
--- a/block/archipelago.c
+++ b/block/archipelago.c
@@ -56,7 +56,7 @@
#include "qemu/thread.h"
#include "qapi/qmp/qint.h"
#include "qapi/qmp/qstring.h"
-#include "qapi/qmp/qjson.h"
+#include "qapi/qmp/qobject-json.h"
#include "qemu/atomic.h"
#include
diff --git a/block/nbd.c b/block/nbd.c
index 416f42b..ef53083 100644
--- a/block/nbd.c
+++ b/block/nbd.c
@@ -32,7 +32,7 @@
#include "qemu/module.h"
#include "qemu/sockets.h"
#include "qapi/qmp/qdict.h"
-#include "qapi/qmp/qjson.h"
+#include "qapi/qmp/qobject-json.h"
#include "qapi/qmp/qint.h"
#include "qapi/qmp/qstring.h"
diff --git a/block/quorum.c b/block/quorum.c
index 6793f12..a64b40d 100644
--- a/block/quorum.c
+++ b/block/quorum.c
@@ -18,7 +18,7 @@
#include "qapi/qmp/qdict.h"
#include "qapi/qmp/qerror.h"
#include "qapi/qmp/qint.h"
-#include "qapi/qmp/qjson.h"
+#include "qapi/qmp/qobject-json.h"
#include "qapi/qmp/qlist.h"
#include "qapi/qmp/qstring.h"
#include "qapi-event.h"
diff --git a/blockjob.
[PATCH 01/11] qapi: Rename qjson.h to qobject-json.h
We have two different JSON visitors in the tree; and having both
named 'qjson.h' can cause include confusion. Rename the qapi
version.
Kill trailing whitespace in the renamed tests/check-qobject-json.c
to keep checkpatch.pl happy.
Signed-off-by: Eric Blake <ebl...@redhat.com>
---
MAINTAINERS | 2 +-
balloon.c | 2 +-
block.c | 2 +-
block/archipelago.c | 2 +-
block/nbd.c | 2 +-
block/quorum.c| 2 +-
blockjob.c| 2 +-
hw/core/qdev.c| 2 +-
hw/misc/pvpanic.c | 2 +-
hw/net/virtio-net.c | 2 +-
include/qapi/qmp/{qjson.h => qobject-json.h} | 0
include/qapi/qmp/types.h | 2 +-
monitor.c | 2 +-
qapi/qmp-event.c | 2 +-
qemu-img.c| 2 +-
qga/main.c| 2 +-
qobject/Makefile.objs | 3 ++-
qobject/{qjson.c => qobject-json.c} | 2 +-
target-s390x/kvm.c| 2 +-
tests/.gitignore | 2 +-
tests/Makefile| 8
tests/{check-qjson.c => check-qobject-json.c} | 14 +++---
tests/libqtest.c | 2 +-
ui/spice-core.c | 2 +-
vl.c | 2 +-
25 files changed, 34 insertions(+), 33 deletions(-)
rename include/qapi/qmp/{qjson.h => qobject-json.h} (100%)
rename qobject/{qjson.c => qobject-json.c} (99%)
rename tests/{check-qjson.c => check-qobject-json.c} (99%)
diff --git a/MAINTAINERS b/MAINTAINERS
index e8cee1e..c943ff4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1155,7 +1155,7 @@ X: include/qapi/qmp/dispatch.h
F: tests/check-qdict.c
F: tests/check-qfloat.c
F: tests/check-qint.c
-F: tests/check-qjson.c
+F: tests/check-qobject-json.c
F: tests/check-qlist.c
F: tests/check-qstring.c
T: git git://repo.or.cz/qemu/qmp-unstable.git queue/qmp
diff --git a/balloon.c b/balloon.c
index 0f45d1b..5983b4f 100644
--- a/balloon.c
+++ b/balloon.c
@@ -31,7 +31,7 @@
#include "trace.h"
#include "qmp-commands.h"
#include "qapi/qmp/qerror.h"
-#include "qapi/qmp/qjson.h"
+#include "qapi/qmp/qobject-json.h"
static QEMUBalloonEvent *balloon_event_fn;
static QEMUBalloonStatus *balloon_stat_fn;
diff --git a/block.c b/block.c
index 9971976..e611002 100644
--- a/block.c
+++ b/block.c
@@ -29,7 +29,7 @@
#include "qemu/error-report.h"
#include "qemu/module.h"
#include "qapi/qmp/qerror.h"
-#include "qapi/qmp/qjson.h"
+#include "qapi/qmp/qobject-json.h"
#include "sysemu/block-backend.h"
#include "sysemu/sysemu.h"
#include "qemu/notify.h"
diff --git a/block/archipelago.c b/block/archipelago.c
index 855655c..80a1bb5 100644
--- a/block/archipelago.c
+++ b/block/archipelago.c
@@ -56,7 +56,7 @@
#include "qemu/thread.h"
#include "qapi/qmp/qint.h"
#include "qapi/qmp/qstring.h"
-#include "qapi/qmp/qjson.h"
+#include "qapi/qmp/qobject-json.h"
#include "qemu/atomic.h"
#include
diff --git a/block/nbd.c b/block/nbd.c
index cd6a587..9009f4f 100644
--- a/block/nbd.c
+++ b/block/nbd.c
@@ -32,7 +32,7 @@
#include "qemu/module.h"
#include "qemu/sockets.h"
#include "qapi/qmp/qdict.h"
-#include "qapi/qmp/qjson.h"
+#include "qapi/qmp/qobject-json.h"
#include "qapi/qmp/qint.h"
#include "qapi/qmp/qstring.h"
diff --git a/block/quorum.c b/block/quorum.c
index d162459..1e3a278 100644
--- a/block/quorum.c
+++ b/block/quorum.c
@@ -18,7 +18,7 @@
#include "qapi/qmp/qdict.h"
#include "qapi/qmp/qerror.h"
#include "qapi/qmp/qint.h"
-#include "qapi/qmp/qjson.h"
+#include "qapi/qmp/qobject-json.h"
#include "qapi/qmp/qlist.h"
#include "qapi/qmp/qstring.h"
#include "qapi-event.h"
diff --git a/blockjob.c b/blockjob.c
index 80adb9d..84361f7 100644
--- a/blockjob.c
+++ b/blockjob.c
@@ -31,7 +31,7 @@
#include "block/block_int.h"
#include "sysemu/block-backend.h"
#include "qapi/qmp/qerror.h"
-#include "qapi/qmp/qjson.h"
+#include "qapi/qmp/qobject-json.h"
#include "qemu/coroutine.h"
#include "qmp-commands.h"
#include "qemu/timer.h"
diff --git a/hw/core/qdev.c b/hw/core/qdev.c
index b3ad467..a98304d 100644
--- a/hw/core/qdev.c
+++ b/hw/core/qdev.c
@@ -31,7 +31,7 @@
#include "qapi/err
Re: [Qemu-devel] [PATCH v6 14/33] pc-dimm: drop the prefix of pc-dimm
On 10/29/2015 11:56 PM, Xiao Guangrong wrote:
> This patch is generated by this script:
>
> find ./ -name "*.[ch]" -o -name "*.json" -o -name "trace-events" -type f \
> | xargs sed -i "s/PC_DIMM/DIMM/g"
>
> find ./ -name "*.[ch]" -o -name "*.json" -o -name "trace-events" -type f \
> | xargs sed -i "s/PCDIMM/DIMM/g"
>
> find ./ -name "*.[ch]" -o -name "*.json" -o -name "trace-events" -type f \
> | xargs sed -i "s/pc_dimm/dimm/g"
The '-type f' binds only to the '-name trace-events' clause, and not the
'name "*.[ch]"' or '-name "*.json"', but since we don't have any
directories by those names, it didn't matter. You probably could have
eliminated the -type f with no consequences, rather than adding "(" and
")". In fact, you could have used git rather than find to do it:
git grep -il 'pc_\?dimm' | xargs ...
which finds only one additional instance of pc_dimm in
stubs/Makefile.objs - so maybe you should:
git mv stubs/qmp_{pc_,}dimm_device_list.c
either in this patch or as a followup.
Could compress these three sed lines into one, if desired:
find ... | xargs sed -i 's/pc_\?\(dimm\)/\1/ig'
But doesn't really matter. I'm fine if you leave your commit message
as-is, and will let you decide what to do about the stub file name.
>
> find ./ -name "trace-events" -type f | xargs sed -i "s/pc-dimm/dimm/g"
>
> It prepares the work which abstracts dimm device type for both pc-dimm and
> nvdimm
>
> Signed-off-by: Xiao Guangrong <guangrong.x...@linux.intel.com>
> ---
Reviewed-by: Eric Blake <ebl...@redhat.com>
> qapi-schema.json| 8 +--
Touches public interface files, but does not affect ABI, so it is safe.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH v3 14/32] pc-dimm: drop the prefix of pc-dimm
On 10/10/2015 09:52 PM, Xiao Guangrong wrote:
> This patch is generated by this script:
>
> find ./ -name "*.[ch]" -o -name "*.json" -o -name "trace-events" -type f \
> | xargs sed -i "s/PC_DIMM/DIMM/g"
>
> find ./ -name "*.[ch]" -o -name "*.json" -o -name "trace-events" -type f \
> | xargs sed -i "s/PCDIMM/DIMM/g"
>
> find ./ -name "*.[ch]" -o -name "*.json" -o -name "trace-events" -type f \
> | xargs sed -i "s/pc_dimm/dimm/g"
>
> find ./ -name "trace-events" -type f | xargs sed -i "s/pc-dimm/dimm/g"
>
> It prepares the work which abstracts dimm device type for both pc-dimm and
> nvdimm
>
> Signed-off-by: Xiao Guangrong <guangrong.x...@linux.intel.com>
> ---
> hmp.c | 2 +-
> +++ b/qapi-schema.json
> @@ -3684,9 +3684,9 @@
> { 'command': 'query-memdev', 'returns': ['Memdev'] }
>
> ##
> -# @PCDIMMDeviceInfo:
> +# @DIMMDeviceInfo:
> #
> -# PCDIMMDevice state information
> +# DIMMDevice state information
> #
> # @id: #optional device's ID
> #
> @@ -3706,7 +3706,7 @@
> #
> # Since: 2.1
> ##
> -{ 'struct': 'PCDIMMDeviceInfo',
> +{ 'struct': 'DIMMDeviceInfo',
>'data': { '*id': 'str',
> 'addr': 'int',
> 'size': 'int',
> @@ -3725,7 +3725,7 @@
> #
> # Since: 2.1
> ##
> -{ 'union': 'MemoryDeviceInfo', 'data': {'dimm': 'PCDIMMDeviceInfo'} }
> +{ 'union': 'MemoryDeviceInfo', 'data': {'dimm': 'DIMMDeviceInfo'} }
Struct names are not ABI, so this change is safe.
I have not reviewed the rest of the patch, but I don't see any problems
from the qapi perspective.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [RFC PATCH v4] os-android: Add support to android platform
On 10/06/2015 03:47 AM, Stefan Hajnoczi wrote: > On Sat, Oct 03, 2015 at 12:44:14PM +0800, Houcheng Lin wrote: >> diff --git a/configure b/configure >> index d7c24cd..cda88c1 100755 >> +++ b/include/qemu/osdep.h >> @@ -74,6 +74,14 @@ typedef unsigned intuint_fast16_t; >> typedef signed int int_fast16_t; >> #endif >> >> +#ifdef CONFIG_ANDROID >> +/* >> + * For include the basename prototyping in android. >> + */ >> +#include > > Files that use basename(3) should include libgen.h. Why include it > here? What is using basename(3)? POSIX gives basename(3) a worthless contract - it is free to return non-thread-safe storage. Also, it is not portable to Windows-style drive-letters, so I consider any code using to already be suspect. If you are already writing code to be ported to both Unixy and windows systems, you are better off rolling your own alternative to basename (or better, using something else that has already rolled a portable version for you - while I know gnulib does that, we aren't using gnulib; but I assume glib has something along those lines even though I haven't looked for it). -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH 3/3] Target-ppc: Remove unnecessary variable
On 09/25/2015 02:37 AM, Shraddha Barke wrote: > Compress lines and remove the variable. > > +++ b/target-ppc/kvm.c > @@ -1782,8 +1782,7 @@ uint32_t kvmppc_get_tbfreq(void) > > ns++; > > -retval = atoi(ns); > -return retval; > +return atoi(ns); atoi() is lousy; it cannot properly detect user input errors. This should probably be converted to use the appropriate qemu_strtol variant instead. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH v4] ppc/spapr: Implement H_RANDOM hypercall in QEMU
On 09/21/2015 12:00 AM, Thomas Huth wrote: >>> This being said, I am not sure about the use case where a user has a hwrng >>> capable platform and wants to run guests without any hwrng support at all is >>> an appropriate default behavior... I guess we will find more users that want >>> in-kernel being the default if it is available. >>> >>> The patch below modifies yours to do just this: the pseudo-device is only >>> created if hwrng is present and not already created. >> >> I have mixed feelings about this. On the one hand, I agree that it >> would be nice to allow H_RANDOM support by default. On the other hand >> the patch below leaves no way to turn it off for testing purposes. It >> also adds another place where the guest hardware depends on the host >> configuration, which adds to the already substantial mess of ensuring >> that source and destination hardware configuration matches for >> migration. > > I thought about this question on the weekend and came to the same > conclusion. I think if we want to enable this by default, it likely > should rather be done at the libvirt level instead? > Adding hardware by default to existing machine types has been a bane to libvirt usage in the past. If upgrading from an old qemu to a new one suddenly turns on new guest-visible hardware with no change to the command line, then libvirt has a much harder time migrating that guest. It's okay to have a new machine type turn on a feature by default, and to have knobs so that the feature can be turned on even for older machine types, but experience has shown that any new feature MUST come with knobs and a way to learn if the feature can be turned on/off, rather than just blindly assuming that turning it on is the right thing. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH v3] ppc/spapr: Implement H_RANDOM hypercall in QEMU
On 09/11/2015 03:17 AM, Thomas Huth wrote: > The PAPR interface defines a hypercall to pass high-quality > hardware generated random numbers to guests. Recent kernels can > already provide this hypercall to the guest if the right hardware > random number generator is available. But in case the user wants > to use another source like EGD, or QEMU is running with an older > kernel, we should also have this call in QEMU, so that guests that > do not support virtio-rng yet can get good random numbers, too. > > This patch now adds a new pseude-device to QEMU that either s/pseude/pseudo/ > directly provides this hypercall to the guest or is able to > enable the in-kernel hypercall if available. The in-kernel > hypercall can be enabled with the use-kvm property, e.g.: > > qemu-system-ppc64 -device spapr-rng,use-kvm=true > -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [PATCH v4 12/15] Add optional parameters to QMP command query-cpu-definitions
On 03/31/2015 01:46 PM, Eduardo Habkost wrote:
On Mon, Mar 30, 2015 at 04:28:25PM +0200, Michael Mueller wrote:
[...]
##
# @query-cpu-definitions:
#
# Return a list of supported virtual CPU definitions
#
+# @machine: #optional machine type (since 2.4)
+#
+# @accel: #optional accelerator id (since 2.4)
+#
# Returns: a list of CpuDefInfo
#
# Since: 1.2.0
##
-{ 'command': 'query-cpu-definitions', 'returns': ['CpuDefinitionInfo'] }
+{ 'command': 'query-cpu-definitions',
+ 'data': { '*machine': 'str', '*accel': 'AccelId' },
+ 'returns': ['CpuDefinitionInfo'] }
What happens if the new parameters are provided to an old QEMU version
that doesn't accept them? It looks like we need an introspection
mechanism or a new command name.
Providing an optional parameter that a new qemu understands to an older
qemu gracefully errors out about an unknown parameter. But it's
annoying to have to probe for whether the parameter is understood by
exploiting that particular error message from older qemu.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH v4 12/15] Add optional parameters to QMP command query-cpu-definitions
On 03/30/2015 08:28 AM, Michael Mueller wrote:
The patch adds optional parameters to the QMP command query-cpu-definitions.
Thus the signature of routine arch_query_cpu_definitions needs to be changed
for the stub function and all target implementations:
target-arm
target-i386
target-ppc
target-s390
Signed-off-by: Michael Mueller m...@linux.vnet.ibm.com
---
+++ b/qapi-schema.json
@@ -2532,21 +2532,31 @@
#
# @name: the name of the CPU definition
#
+# @default: #optional defines if cpu model is the default (since 2.4)
Reads poorly. How about:
# @default: #optional true if cpu model is the default, omitted if false
(since 2.4)
+#
+# @runnable: #optional defines if cpu model is runnable (since 2.4)
Similarly:
# @runnable: #optional true if cpu model is runnable, omitted if false
(since 2.4)
+#
# Since: 1.2.0
##
{ 'type': 'CpuDefinitionInfo',
- 'data': { 'name': 'str' } }
+ 'data': { 'name': 'str', '*is-default': 'bool', '*runnable': 'bool' } }
##
# @query-cpu-definitions:
#
# Return a list of supported virtual CPU definitions
#
+# @machine: #optional machine type (since 2.4)
+#
+# @accel: #optional accelerator id (since 2.4)
Maybe mention that these two fields are for filtering results.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH v4 11/15] target-s390x: New QMP command query-cpu-model
On 03/30/2015 08:28 AM, Michael Mueller wrote:
This patch implements a new QMP request named 'query-cpu-model'.
It returns the cpu model of cpu 0 and its backing accelerator.
request:
{execute : query-cpu-model }
answer:
{return : {name: 2827-ga2, accel: kvm }}
Alias names are resolved to their respective machine type and GA names
already during cpu instantiation. Thus, also a cpu model like 'host'
which is implemented as alias will return its normalized cpu model name.
Furthermore the patch implements the following function:
- s390_cpu_models_used(), returns true if S390 cpu models are in use
Signed-off-by: Michael Mueller m...@linux.vnet.ibm.com
---
+++ b/qapi-schema.json
@@ -2516,6 +2516,16 @@
{ 'command': 'query-machines', 'returns': ['MachineInfo'] }
##
+# @AccelId
+#
+# Defines accelerator ids
+#
+# Since: 2.4
+##
+{ 'enum': 'AccelId',
+ 'data': ['qtest', 'tcg', 'kvm', 'xen' ] }
Unusual spacing (0 spaces after '[' but 2 spaces before closing ']'?),
but not necessarily wrong.
+##
+# @CpuModelInfo:
+#
+# Virtual CPU model definition.
+#
+# @name: the name of the CPU model definition
+#
+# @accel: AccelId (name) of this cpu models accelerator
s/models/model's/
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH v4 11/15] target-s390x: New QMP command query-cpu-model
On 03/30/2015 02:17 PM, Eduardo Habkost wrote:
On Mon, Mar 30, 2015 at 04:28:24PM +0200, Michael Mueller wrote:
This patch implements a new QMP request named 'query-cpu-model'.
It returns the cpu model of cpu 0 and its backing accelerator.
request:
{execute : query-cpu-model }
answer:
{return : {name: 2827-ga2, accel: kvm }}
If you are returning information about an existing CPU, why not just
extend the output of query-cpus?
(Existing qmp_query_cpus() calls cpu_synchronize_state(), which may be
undesired. But in this case we could add an optional parameter to
disable the return of data that requires stopping the VCPU).
And how would libvirt learn about the existence of that optional
parameter? Without introspection, a new command is easier to query than
learning about whether an optional parameter exists (then again, we're
hoping to get introspection into 2.4, so it may be a moot question).
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH 02/21] userfaultfd: linux/Documentation/vm/userfaultfd.txt
userland to use the UFFD always in +nonblocking mode if combined with POLLIN. + +userfaultfd is also a generic enough feature, that it allows KVM to +implement postcopy live migration (one form of memory externalization +consisting of a virtual machine running with part or all of its memory +residing on a different node in the cloud) without having to modify a +single line of KVM kernel code. Guest async page faults, FOLL_NOWAIT +and all other GUP features works just fine in combination with +userfaults (userfaults trigger async page faults in the guest +scheduler so those guest processes that aren't waiting for userfaults +can keep running in the guest vcpus). + +The primary ioctl to resolve userfaults is UFFDIO_COPY. That +atomically copies a page into the userfault registered range and wakes +up the blocked userfaults (unless uffdio_copy.mode +UFFDIO_COPY_MODE_DONTWAKE is set). Other ioctl works similarly to +UFFDIO_COPY. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [RFC PATCH v2 12/15] cpu-model/s390: Extend QMP command query-cpu-definitions
On 02/17/2015 07:24 AM, Michael Mueller wrote:
This patch implements the QMP command 'query-cpu-definitions' in the S390
context. The command returns a in terms of machine release date descending
sorted list of cpu model names in the current host context.
returns a list of cpu model names sorted by descending release dates.
Does guaranteeing the sorting as part of the interface really matter, or
would it be better to just return the list with no documented sorting
(where callers treat it as unsorted)?
A consumer may
successfully request each listed cpu model as long for a given accelerator
this model is runnable.
Thy QMP type AccelCpuModelInfo is introduced and the type CpuDefinitionInfo
is extended by the optional field 'accelerators'. It contains a list of named
accelerators and some indication whether the associated cpu model is runnable
or the default cpu model. The default cpu model is used either no specific cpu
was requested during QEMU startup or the cpu model with named 'host'.
request:
{execute: query-cpu-definitions}
answer:
{return:
[{name:2964-ga1,accelerators:[{name:kvm,runnable:false,default:false}]},
{name:2828-ga1,accelerators:[{name:kvm,runnable:false,default:false}]},
{name:2827-ga2,accelerators:[{name:kvm,runnable:true,default:true}]},
{name:2827-ga1,accelerators:[{name:kvm,runnable:true,default:false}]},
{name:2818-ga1,accelerators:[{name:kvm,runnable:true,default:false}]},
...
{name:2064-ga1,accelerators:[{runnable:true,name:kvm,default:false}]}
]
}
Looks okay from an interface perspective.
Signed-off-by: Michael Mueller m...@linux.vnet.ibm.com
---
qapi-schema.json | 21 +-
target-s390x/cpu-models.c | 15 +++
target-s390x/cpu-models.h | 1 +
target-s390x/cpu.c| 100
+++---
4 files changed, 130 insertions(+), 7 deletions(-)
diff --git a/qapi-schema.json b/qapi-schema.json
index 9431fc2..a5d38ae 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -2485,16 +2485,35 @@
'data': ['qtest', 'tcg', 'kvm', 'xen' ] }
##
+# @AccelCpuModelInfo:
+#
+# Accelerator specific CPU model data
+#
+# @id: the accelerator id
+#
There is no 'id' field below, did you mean 'name'?
+# @default: cpu model for 'host'
+#
+# @runnable: cpu model can be activated on hosting machine
+#
+# Since: 2.3.0
+#
+##
+{ 'type': 'AccelCpuModelInfo',
+ 'data': { 'name': 'AccelId', 'default': 'bool', 'runnable': 'bool' } }
+
+##
# @CpuDefinitionInfo:
#
# Virtual CPU definition.
#
# @name: the name of the CPU definition
#
+# @accelerators: #optional cpu model offered per accelerator (since 2.3.0)
+#
Must the field be optional, or will we always provide it? Since this is
an output-only field, it is okay for back-compat to make the new field
unconditional.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [RFC PATCH v2 11/15] cpu-model/s390: Add QMP command query-cpu-model
On 02/17/2015 07:24 AM, Michael Mueller wrote:
This patch implements a new QMP request named 'query-cpu-model'.
It returns the cpu model of cpu 0 and its backing accelerator.
request:
{execute : query-cpu-model }
answer:
{return : {name: 2827-ga2, accelerator: kvm }}
Alias names are resolved to their respective machine type and GA names
already during cpu instantiation. Thus, also a cpu model like 'host'
which is implemented as alias will return its normalized cpu model name.
Furthermore the patch implements the following functions:
- s390_cpu_typename(), returns the currently selected cpu type name or NULL
- s390_cpu_models_used(), returns true if S390 cpu models are in use
Signed-off-by: Michael Mueller m...@linux.vnet.ibm.com
---
+##
+# @CpuModelInfo:
+#
+# Virtual CPU model definition.
+#
+# @name: the name of the CPU model definition
+#
+# Since: 2.3.0
+##
+{ 'type': 'CpuModelInfo',
+ 'data': { 'name': 'str', '*accelerator': 'AccelId' } }
You didn't document '*accelerator', including mention that it is
optional (why would it not be output always?).
+
+##
+# @query-cpu-model:
+#
+# Return to current virtual CPU model
s/to/the/
+#
+# Returns: CpuModelInfo
+#
+# Since: 2.3.0
We aren't very consistent on '2.3' vs. '2.3.0', so I won't complain
about that.
+##
+{ 'command': 'query-cpu-model', 'returns': 'CpuModelInfo' }
Seems reasonable from the interface point of view; I have not closely
reviewed the implementation.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [RFC PATCH v2 02/15] cpu-model: Introduce option --probe to switch into probe mode
On 02/17/2015 07:24 AM, Michael Mueller wrote: The option --probe allows to switch into probe mode also for machines different from none. If one or more accelerators are specified these accelerators are used to provide probable properties. If no accelerator is given a list of accellerators that support probing is used. s/accellerators/accelerators/ Signed-off-by: Michael Mueller m...@linux.vnet.ibm.com --- accel.c| 13 - include/sysemu/accel.h | 2 +- qemu-options.hx| 8 vl.c | 7 ++- 4 files changed, 23 insertions(+), 7 deletions(-) -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [QEMU patch 2/2] kvm: allow configuration of tsc deadline timer advancement
On 12/10/2014 09:23 AM, Marcelo Tosatti wrote:
Add machine option and QMP commands to configure TSC deadline
timer advancement.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
---
+##
+# @get-lapic-tscdeadline-advance
+#
+# This command gets the TSC deadline timer advancement.
+#
+# Only supported by KVM acceleration.
+#
+# Since: 2.3
+##
+{ 'command': 'get-lapic-tscdeadline-advance', 'returns': 'int' }
Please don't return a bare int. It is not extensible, if we ever need
multiple named values associated with lapic in the future. Return a
dictionary instead.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [question] updating the base image for all clones which havebeen running for months
On 11/03/2014 01:37 PM, Zhang Haoyu wrote: Hi, all I used base image A to clone so many vm, after running for months, each vm has its own private applications and data, which maybe different from each other. Now, I want to install some applications for all of the clones, what should I do? How would you do it for bare metal? Do the same for your guests. Install the applications on each clone separately, or use some other method to make it available (like installing on a shared network resource). Could you detail installing on a shared network resource? Set up a network file system, like NFS or gluster, install your software on the shared file system, and then make each guest mount the shared file system in order to use the software. The same as you would on bare metal. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH v3 2/2] docs: update ivshmem device spec
On 09/01/2014 03:52 AM, David Marchand wrote: What about upgrading QEMU and ivshmem-server while you have existing guests? You cannot restart ivshmem-server, and the new QEMU would have to talk to the old ivshmem-server. Version negotiation also helps avoid confusion if someone combines ivshmem-server and QEMU from different origins (e.g. built from source and distro packaged). Don't underestimate the likelihood of this happening. Any long-running process (which an ivshmem-server will be) continues running at the old version, even when a package upgrade installs a new qemu binary; the new binary should still be able to manage connections to the already-running server. Even neater would be a solution where an existing ivshmem-server could re-exec an updated ivshmem-server binary that resulted from a distro upgrade, hand over all state required for the new server to take over from the point managed by the old server, so that you aren't stuck running the old binary forever. But that's a lot trickier to write, so it is not necessary for a first implementation; and if you do that, then you have the reverse situation to worry about (the new server must still accept communication from existing old qemu binaries). Note that the goal here is to support upgrades; it is probably okay if downgrading from a new binary back to an old doesn't work correctly (because the new software was using a feature not present in the old). It's a safeguard to prevent hard-to-diagnose failures when the system is misconfigured. Hum, so you want the code to be defensive against mis-use, why not. I wanted to keep modifications on ivshmem as little as possible in a first phase (all the more so as there are potential ivshmem users out there that I think will be impacted by a protocol change). Existing ivshmem users MUST be aware that they are using something that is not yet polished, and be prepared to make the upgrade to the polished version. It's best to minimize the hassle by making them upgrade exactly once to a fully-robust version, rather than to have them upgrade to a slightly-more robust version only to find out we didn't plan ahead well enough to make further extensions in a back-compatible manner. Sending the version as the first vm_id with an associated fd to -1 before sending the real client id should work with existing QEMU client code (hw/misc/ivshmem.c). Do you have a better idea ? Is there a best practice in QEMU for version negotiation that could work with ivshmem protocol ? QMP starts off with a mandatory qmp_capabilities handshake, although we haven't yet had to define any capabilities where cross-versioned communication differs as a result. Migration is somewhat of an example, except that it is one-directional (we don't have a feedback path), so it is somewhat best effort. The qcow2 v3 file format is an example of declaring features, rather than version numbers, and making decisions about whether a feature is compatible (older clients can safely ignore the bit, without corrupting the image but possibly having worse performance) vs. incompatible (older clients must reject the image, because not handling the feature correctly would corrupt the image). The best handshakes are bi-directional - both sides advertise their version (or better, their features), and a well-defined algorithm for settling on the common subset of advertised features then ensures that the two sides know how to talk to each other, or give a reason for either side to disconnect early because of a missing feature. I have a v4 ready with this (and all the pending comments), I will send it later unless a better idea is exposed. Thanks. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [PATCH v4 00/14] ivshmem: update documentation, add client/server tools
On 09/03/2014 07:01 AM, David Marchand wrote: Rather than introducing new files with bugs, followed by patches to clean it up, why not just introduce the new files correct in the first place? I think you are better off squashing in a lot of the cleanup patches into patch 1. Actually, I mentioned this in a previous email but did not get any comment. So, I preferred to send the splitted patches to ease review (from my point of view). It does not ease reviewer time to have a known buggy patch with later cleanups. I'd rather see your best effort at a bug-free patch to begin with, than to spend my time pointing out bugs only to find out you already fixed them later in the series. Once code looks fine enough, I intend to keep only three patches : - one for the initial import of ivshmem-client / server - one for the documentation update - one last with the protocol change If that is your plan for the final series, then that is the same plan you should be using for reviews. You want the reviewers to see your proposed final product, not your intermediate state of how you got there. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [PATCH v4 01/14] contrib: add ivshmem client and server
On 09/02/2014 09:25 AM, David Marchand wrote:
When using ivshmem devices, notifications between guests can be sent as
interrupts using a ivshmem-server (typical use described in documentation).
The client is provided as a debug tool.
Signed-off-by: Olivier Matz olivier.m...@6wind.com
Signed-off-by: David Marchand david.march...@6wind.com
---
+/* parse the size of shm */
+static int
+parse_size(const char *val_str, size_t *val)
+{
+char *endptr;
+unsigned long long tmp;
+
+errno = 0;
+tmp = strtoull(val_str, endptr, 0);
+if ((errno == ERANGE tmp == ULLONG_MAX) || (errno != 0 tmp == 0)) {
+return -1;
+}
This is overly complex; usually, this is just done as:
if (errno)
return -1;
+/* parse an unsigned int */
+static int
+parse_uint(const char *val_str, unsigned *val)
+{
+char *endptr;
+unsigned long tmp;
+
+errno = 0;
+tmp = strtoul(val_str, endptr, 0);
+if ((errno == ERANGE tmp == ULONG_MAX) || (errno != 0 tmp == 0)) {
+return -1;
+}
and again
+if (endptr == val_str || endptr[0] != '\0') {
+return -1;
+}
+*val = tmp;
+return 0;
+}
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [PATCH v4 02/14] docs: update ivshmem device spec
On 09/02/2014 09:25 AM, David Marchand wrote: Add some notes on the parts needed to use ivshmem devices: more specifically, explain the purpose of an ivshmem server and the basic concept to use the ivshmem devices in guests. Move some parts of the documentation and re-organise it. Signed-off-by: David Marchand david.march...@6wind.com Reviewed-by: Claudio Fontana claudio.font...@huawei.com --- docs/specs/ivshmem_device_spec.txt | 124 +++- 1 file changed, 93 insertions(+), 31 deletions(-) -The device currently supports 4 registers of 32-bits each. Registers -are used for synchronization between guests sharing the same memory object when -interrupts are supported (this requires using the shared memory server). +The server must be started on the host before any guest. +It creates a shared memory object then waits for clients to connect on an unix +socket. s/an unix/a unix/ -The server assigns each VM an ID number and sends this ID number to the QEMU -process when the guest starts. +For each client (QEMU processes) that connects to the server: s/processes/process/ +The client IDs are limited to 16 bits because of the current implementation (see +Doorbell register in 'PCI device registers' subsection). Hence on 65536 clients s/on/only/ +At initialisation, when creating the ivshmem device, QEMU gets its ID from the +server then make it available through BAR0 IVPosition register for the VM to use s/make/makes/ -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [PATCH v4 05/14] contrib/ivshmem-*: switch to QEMU headers
On 09/02/2014 09:25 AM, David Marchand wrote:
Reuse parsers from QEMU, C99 boolean.
Signed-off-by: David Marchand david.march...@6wind.com
---
contrib/ivshmem-client/ivshmem-client.c | 12 +
contrib/ivshmem-client/ivshmem-client.h |4 +-
contrib/ivshmem-client/main.c | 12 +
contrib/ivshmem-server/ivshmem-server.c | 14 +-
contrib/ivshmem-server/ivshmem-server.h |4 +-
contrib/ivshmem-server/main.c | 73
+--
6 files changed, 20 insertions(+), 99 deletions(-)
Why introduce code in patch 1 only to rip it back out in patch 5? Why
not just squash these together and just introduce the contrib file
correct on its first commit?
case 'l': /* shm_size */
-if (parse_size(optarg, args-shm_size) 0) {
+parse_option_size(shm_size, optarg, args-shm_size, errp);
+if (errp) {
+error_free(errp);
fprintf(stderr, cannot parse shm size\n);
It would be nicer to print the contents of errp, instead of discarding
what is likely to be a more specific error message.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [PATCH v4 00/14] ivshmem: update documentation, add client/server tools
On 09/02/2014 09:25 AM, David Marchand wrote: Here is a patchset containing an update on ivshmem specs documentation and importing ivshmem server and client tools. These tools have been written from scratch and are not related to what is available in nahanni repository. I put them in contrib/ directory as the qemu-doc.texi was already telling the server was supposed to be there. Changes since v3: - first patch is untouched - just restored the Reviewed-By Claudio in second patch - following patches 3-8 take into account Stefan's comments - patches 9-12 take into account Gonglei's comments - patch 13 adjusts ivshmem-server default values - last patch introduces a change in the ivshmem client-server protocol to check a protocol version at connect time Rather than introducing new files with bugs, followed by patches to clean it up, why not just introduce the new files correct in the first place? I think you are better off squashing in a lot of the cleanup patches into patch 1. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [RFC PATCH 03/17] COLO migration: add a migration capability 'colo'
On 07/23/2014 08:25 AM, Yang Hongyang wrote: Add a migration capability 'colo'. If this capability is on, The migration will never end, and the VM will be continuously checkpointed. Signed-off-by: Yang Hongyang yan...@cn.fujitsu.com --- include/qapi/qmp/qerror.h | 3 +++ migration.c | 6 ++ qapi-schema.json | 5 - 3 files changed, 13 insertions(+), 1 deletion(-) diff --git a/include/qapi/qmp/qerror.h b/include/qapi/qmp/qerror.h index 902d1a7..226b805 100644 --- a/include/qapi/qmp/qerror.h +++ b/include/qapi/qmp/qerror.h @@ -166,4 +166,7 @@ void qerror_report_err(Error *err); #define QERR_SOCKET_CREATE_FAILED \ ERROR_CLASS_GENERIC_ERROR, Failed to create socket +#define QERR_COLO_UNSUPPORTED \ +ERROR_CLASS_GENERIC_ERROR, COLO is not currently supported, please rerun configure with --enable-colo option in order to support COLO feature Unless you plan on using this message in more than one place, we prefer that you don't add new #defines here. Instead, just use error_setg with the message inline. +++ b/qapi-schema.json @@ -491,10 +491,13 @@ # @auto-converge: If enabled, QEMU will automatically throttle down the guest # to speed up convergence of RAM migration. (since 1.6) # +# @colo: The migration will never end, and the VM will instead be continuously +#checkpointed. The feature is disabled by default. (since 2.1) You missed 2.1. This has to be since 2.2. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [RFC PATCH 00/17] COarse-grain LOck-stepping(COLO) Virtual Machines for Non-stop Service
On 07/23/2014 08:25 AM, Yang Hongyang wrote: Virtual machine (VM) replication is a well known technique for providing application-agnostic software-implemented hardware fault tolerance non-stop service. COLO is a high availability solution. Both primary VM (PVM) and secondary VM (SVM) run in parallel. They receive the same request from client, and generate response in parallel too. If the response packets from PVM and SVM are identical, they are released immediately. Otherwise, a VM checkpoint (on demand) is conducted. The idea is presented in Xen summit 2012, and 2013, and academia paper in SOCC 2013. It's also presented in KVM forum 2013: http://www.linux-kvm.org/wiki/images/1/1d/Kvm-forum-2013-COLO.pdf Please refer to above document for detailed information. Please also refer to previous posted RFC proposal: http://lists.nongnu.org/archive/html/qemu-devel/2014-06/msg05567.html The patchset is also hosted on github: https://github.com/macrosheep/qemu/tree/colo_v0.1 This patchset is RFC, implements the frame of colo, without failover and nic/disk replication. But it is ready for demo the COLO idea above QEMU-Kvm. Steps using this patchset to get an overview of COLO: 1. configure the source with --enable-colo option Code that has to be opt-in tends to bitrot, because people don't configure their build-bots to opt in. What sort of penalties does opting in cause to the code if colo is not used? I'd much rather make the default to compile colo unless configured --disable-colo. Are there any pre-req libraries required for it to work? That would be the only reason to make the default of on or off conditional, rather than defaulting to on. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [RFC PATCH 02/17] COLO: introduce an api colo_supported() to indicate COLO support
On 07/23/2014 08:25 AM, Yang Hongyang wrote: introduce an api colo_supported() to indicate COLO support, returns true if colo supported(configured with --enable-colo). Space before () in English sentences: s/supported(configured/supported (configured/ As I mentioned in the cover letter, defaulting to off is probably a bad idea; I'd rather default to on or even make it unconditional if it doesn't negatively affect the code base when not used. Signed-off-by: Yang Hongyang yan...@cn.fujitsu.com --- Makefile.objs | 1 + include/migration/migration-colo.h | 18 ++ migration-colo.c | 16 stubs/Makefile.objs| 1 + stubs/migration-colo.c | 16 5 files changed, 52 insertions(+) create mode 100644 include/migration/migration-colo.h create mode 100644 migration-colo.c create mode 100644 stubs/migration-colo.c -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [RFC PATCH 12/17] COLO ctl: add a RunState RUN_STATE_COLO
On 07/23/2014 08:25 AM, Yang Hongyang wrote: Guest will enter this state when paused to save/resore VM state s/resore/restore/ under colo checkpoint. Signed-off-by: Yang Hongyang yan...@cn.fujitsu.com --- qapi-schema.json | 4 +++- vl.c | 8 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/qapi-schema.json b/qapi-schema.json index 807f5a2..b42171c 100644 --- a/qapi-schema.json +++ b/qapi-schema.json @@ -145,12 +145,14 @@ # @watchdog: the watchdog action is configured to pause and has been triggered # # @guest-panicked: guest has been panicked as a result of guest OS panic +# +# @colo: guest is paused to save/restore VM state under colo checkpoint Missing a '(since 2.2)' designation. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [RFC PATCH 07/17] COLO buffer: implement colo buffer as well as QEMUFileOps based on it
On 07/23/2014 08:25 AM, Yang Hongyang wrote:
We need a buffer to store migration data.
On save side:
all saved data was write into colo buffer first, so that we can know
s/was write/is written/
the total size of the migration data. this can also separate the data
transmission from colo control data, we use colo control data over
socket fd to synchronous both side's stat.
On restore side:
all migration data was read into colo buffer first, then load data
from the buffer: If network error happens while data transmission,
s/while/during/
the slaver can still functinal because the migration data are not yet
s/slaver/slave/
s/functinal/function/
s/are/is/
loaded.
Signed-off-by: Yang Hongyang yan...@cn.fujitsu.com
---
migration-colo.c | 112
+++
1 file changed, 112 insertions(+)
+/* colo buffer */
+
+#define COLO_BUFFER_BASE_SIZE (1000*1000*4ULL)
+#define COLO_BUFFER_MAX_SIZE (1000*1000*1000*10ULL)
Spaces around binary operators.
+
+typedef struct colo_buffer {
For consistency with the rest of the code base, name this ColoBuffer,
not colo_buffer.
+uint8_t *data;
+uint64_t used;
+uint64_t freed;
+uint64_t size;
+} colo_buffer_t;
HACKING says to NOT name types with a trailing _t. Just name the
typedef ColoBuffer.
+static void colo_buffer_destroy(void)
+{
+if (colo_buffer.data) {
+g_free(colo_buffer.data);
+colo_buffer.data = NULL;
g_free(NULL) behaves sanely, just make these two lines unconditional.
+static void colo_buffer_extend(uint64_t len)
+{
+if (len colo_buffer.size - colo_buffer.used) {
+len = len + colo_buffer.used - colo_buffer.size;
+len = ROUND_UP(len, COLO_BUFFER_BASE_SIZE) + COLO_BUFFER_BASE_SIZE;
+
+colo_buffer.size += len;
+if (colo_buffer.size COLO_BUFFER_MAX_SIZE) {
+error_report(colo_buffer overflow!\n);
No trailing \n in error_report().
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [PATCH v2 1/2] contrib: add ivshmem client and server
On 07/20/2014 03:38 AM, David Marchand wrote: When using ivshmem devices, notifications between guests can be sent as interrupts using a ivshmem-server (typical use described in documentation). The client is provided as a debug tool. Signed-off-by: Olivier Matz olivier.m...@6wind.com Signed-off-by: David Marchand david.march...@6wind.com --- contrib/ivshmem-client/Makefile | 26 ++ +++ b/contrib/ivshmem-client/Makefile @@ -0,0 +1,26 @@ +# Copyright 2014 6WIND S.A. +# All rights reserved This file has no other license, and is therefore incompatible with GPLv2. You'll need to resubmit under an appropriately open license. +++ b/contrib/ivshmem-client/ivshmem-client.h @@ -0,0 +1,238 @@ +/* + * Copyright(c) 2014 6WIND S.A. + * All rights reserved. + * + * This work is licensed under the terms of the GNU GPL, version 2. See + * the COPYING file in the top-level directory. I'm not a lawyer, but to me, this license is self-contradictory. You can't have All rights reserved and still be GPL, because the point of the GPL is that you are NOT reserving all rights, but explicitly granting your user various rights (on condition that they likewise grant those rights to others). But you're not the only file in the qemu code base with this questionable mix. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH 1/2] docs: update ivshmem device spec
On 06/20/2014 06:15 AM, David Marchand wrote: Add some notes on the parts needed to use ivshmem devices: more specifically, explain the purpose of an ivshmem server and the basic concept to use the ivshmem devices in guests. Signed-off-by: David Marchand david.march...@6wind.com --- docs/specs/ivshmem_device_spec.txt | 41 ++-- 1 file changed, 35 insertions(+), 6 deletions(-) diff --git a/docs/specs/ivshmem_device_spec.txt b/docs/specs/ivshmem_device_spec.txt index 667a862..7d2b73f 100644 --- a/docs/specs/ivshmem_device_spec.txt +++ b/docs/specs/ivshmem_device_spec.txt @@ -85,12 +85,41 @@ events have occurred. The semantics of interrupt vectors are left to the user's discretion. +IVSHMEM host services +- + +This part is optional (see *Usage in the Guest* section below). + +To handle notifications between users of a ivshmem device, a ivshmem server has s/a ivshmem/an ivshmem/ (twice) +been added. This server is responsible for creating the shared memory and +creating a set of eventfds for each users of the shared memory. It behaves as a +proxy between the different ivshmem clients (QEMU): giving the shared memory fd +to each client, allocating eventfds to new clients and broadcasting to all +clients when a client disappears. + +Apart from the current ivshmem implementation in QEMU, a ivshmem client can be and again +written for debug, for development purposes, or to implement notifications +between host and guests. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [qom-cpu PATCH 2/3] target-i386: Remove unsupported bits from all CPU models
On 06/18/2014 01:55 PM, Eduardo Habkost wrote:
The following CPU features were never supported by neither TCG or KVM,
so they are useless on the CPU model definitions, today:
The overall idea of this series makes sense to me (yes, I'd love to get
libvirt to the point that we can use enforce mode), but I decline to
review the actual contents (it's a bit over my head how all the models
work) and leave it to the experts. But here's a trivial finding:
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 8de1566..2f32d29 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -680,10 +680,11 @@ static X86CPUDefinition builtin_x86_defs[] = {
.family = 16,
.model = 2,
.stepping = 3,
+/* MIssing: CPUID_HT */
s/MIssing/Missing/
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [RFC 0/2] GET_EMULATED_CPUID support with allow-emulation option
On 06/05/2014 01:24 PM, Borislav Petkov wrote: On Thu, Jun 05, 2014 at 04:12:08PM -0300, Eduardo Habkost wrote: In the meantime, we could: * Include the less fine-tuned allow-emulation (or allow-experimental-features) option, which is implemented by this series, for people who use enforce and/or don't care too much about getting other experimental features enabled. * Wait until somebody implements feature=force. What are you going to do with allow-emulation after this? It will become an API and you'll have to support it. If you're worried about not needing the option forever, name it x-allow-emulation; we've already documented that anything with x- prefix is fair game for subsequent removal. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH v3 02/16] x86: Convert debug printfs to QEMU_DPRINTF
[resend, because I got:
- The following addresses had permanent fatal errors -
qemu-de...@nongnu.org
(reason: 550 Invalid address in message header)
I think it was complaining about:
CC: open list:X86 xen-de...@lists.xensource.com
CC: open list:X86 kvm@vger.kernel.org
where the RFCs say you should enclose : inside , as in:
CC: open list:X86 ...
to be fully compliant.]
On 05/17/2014 05:03 PM, Marc Marí wrote:
Modify debug macros to have the same format through the codebase and use
regular
ifs instead of ifdef.
Signed-off-by: Marc Marí marc.mari.barc...@gmail.com
---
hw/i386/kvm/pci-assign.c | 11 ++-
hw/i386/multiboot.c |7 +--
target-i386/kvm.c|9 +
xen-hvm.c|9 +
xen-mapcache.c |9 +
5 files changed, 26 insertions(+), 19 deletions(-)
#ifdef DEVICE_ASSIGNMENT_DEBUG
-#define DEBUG(fmt, ...) \
-do { \
-fprintf(stderr, %s: fmt, __func__ , __VA_ARGS__); \
-} while (0)
+#define DEVICE_ASSIGNMENT_DEBUG_ENABLED 1
#else
-#define DEBUG(fmt, ...)
+#define DEVICE_ASSIGNMENT_DEBUG_ENABLED 0
#endif
+#define DEBUG(fmt, ...) \
+QEMU_DPRINTF(DEVICE_ASSIGNMENT_DEBUG_ENABLED, \
+pci_assign, fmt, ## __VA_ARGS__)
+
Style - you are replacing aligned \ continuation with one-space \
continuation. I don't know if we have a distinct preference, but it's
probably better to leave the style unchanged if checkpatch.pl doesn't
complain about either way.
As that's minor,
Reviewed-by: Eric Blake ebl...@redhat.com
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH v2 01/16] x86: Convert conditional compilation of debug printfs to regular ifs
On 05/13/2014 01:02 AM, Marc Marí wrote:
Modify debug macros to have the same format through the codebase and use
regular
ifs instead of ifdef.
As the debug printf is always put in code, some casting had to be added to
avoid
warnings treated as errors at compile time.
Umm, where in this patch did you add casting? Don't add bogus lines to
the commit message (I was assuming that it might be a case where the
code has type mismatches, and where something like PRId32 would be
better than adding a cast - but couldn't find where that was. Maybe
other patches in the series are affected?)
Signed-off-by: Marc Marí marc.mari.barc...@gmail.com
---
-#define DEBUG(fmt, ...) \
-do { \
-fprintf(stderr, %s: fmt, __func__ , __VA_ARGS__); \
-} while (0)
The old code was line-wrapped to fit in 80 columns...
+#define DEVICE_ASSIGNMENT_DEBUG_ENABLED 1
#else
-#define DEBUG(fmt, ...)
+#define DEVICE_ASSIGNMENT_DEBUG_ENABLED 0
#endif
+#define DEBUG(fmt, ...) QEMU_DPRINTF(DEVICE_ASSIGNMENT_DEBUG_ENABLED,
pci_assign, fmt, ## __VA_ARGS__)
the new code should probably try to do similar:
#define DEBUG(fmt, ...) \
QEMU_DPRINTF(DEVICE_ASSIGNMENT_DEBUG_ENABLED, \
pci_assign, fmt, ## __VA_ARGS__)
Although __VA_ARGS__ is required by C99, the use of ##__VA_ARGS__ is a
gcc extension; are you sure that all other supported compilers handle
it? (I guess that's just clang)
If you want something portable to C99, just use one fewer macro
argument, so that you are guaranteed that __VA_ARGS__ will be non-empty
(that is, subsume fmt into the ...):
#define DEBUG(...) \
QEMU_DPRINTF(DEVICE_ASSIGNMENT_DEBUG_ENABLED, \
pci_assign, __VA_ARGS__)
+#define mb_debug(a...) QEMU_DPRINTF(DEBUG_MULTIBOOT_ENABLED, i386
multiboot, a)
Use of 'a...' as a named var-arg parameter is a gcc extension, not
portable to C99. Again, will this compile on non-gcc? Unnamed ...
coupled with __VA_ARGS__ is the only fully portable way to do var-args.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH v1 RFC 09/10] QEMU: s390: cpu model QMP query-cpu-model
On 05/13/2014 09:00 AM, Michael Mueller wrote:
This patch implements a new QMP request named query-cpu-model. It returns
the cpu model of cpu 0. eg:
request: '{execute : query-cpu-model }
answer: '{return : {name: 2827-ga2}}
Alias names are resolved to their respective machine type and GA names
already during cpu instantiation. Thus, also a cpu name like host,
which is implemented as alias, will return its normalized cpu model name.
+}
+cpu_model = g_try_malloc0(sizeof(*cpu_model));
It's simpler to just use g_malloc0 and rely on glibc's exit-on-OOM
behavior than to try and deal with NULL - this isn't user input (so
unlikely to be so huge as to cause OOM), and would be more in line with
what most other QMP code does. But that said...
+if (!cpu_model) {
+goto out_no_mem;
+}
+cpu_model-name = g_try_malloc0(CPU_MODEL_NAME_LEN);
+if (!cpu_model-name) {
+goto out_no_mem;
+}
+snprintf(cpu_model-name, CPU_MODEL_NAME_LEN - 1, %04x-ga%u,
+ cc-proc-type, cc-mach-ga);
...why not just use g_strdup_printf() instead of trying to size a buffer
yourself? In other words, skip the g_try_malloc0 to begin with.
The fact that you are packing two pieces of information into one string
is a bit worrisome - that means that the client of the QMP command has
to parse the string back into two pieces of information if they ever
need either item in isolation. If the user never has a need to split
the name down into parts, you are okay; I don't know S390 well enough to
know whether anyone will care about type separate from ga. But if
someone DOES care, then the QMP command should return the parts already
split, as in { type: 2827, ga: 2 }, or even as convenience provide
both split and combined forms: { name: 2827-ga2, type: 2827, ga: 2 }
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [libvirt] [Qemu-devel] [uq/master PATCH 0/7] x86 CPU subclasses, take 7
On 01/31/2014 11:51 AM, Eduardo Habkost wrote: Allowing -device may be okay, since in the (very?) long term -device can be replaced by -object. But -object is definitive. OK, one additional reason to try device_add first. But then we have one additional problem: * We want to allow libvirt to probe for CPU model information when running QEMU using -machine none (because libvirt already does that, and we don't want to require libvirt to run QEMU multiple times) * device_add driver=model-x86_64-cpu requires an icc-bus to be present * -machine none doesn't have any bus * I don't see a way to create an icc-bus through QMP (is there a way?) Is the icc-bus something that makes sense for all architectures, so that libvirt could just blindly request a command line that uses '-machine none' but also instantiates the icc-bus? Even if icc-bus is x86-specific, libvirt DOES have some notion of what architecture a qemu executable will be targetting, and could modify the command line based on what architecture it guesses the binary will support, if only for the purpose of minimizing qemu invocations for its probe of supported cpus. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH v3 0/2] Intel MPX feature support at Qemu
On 12/06/2013 07:06 AM, Liu, Jinsong wrote: Intel has released Memory Protection Extensions (MPX) recently. Please refer to http://download-software.intel.com/sites/default/files/319433-015.pdf These 2 patches are version2 to support Intel MPX at qemu side. You still aren't threading correctly, which makes it hard to track your series. Please review http://wiki.qemu.org/Contribute/SubmitAPatch and make sure your 'git send-email' settings allow for proper threading; a good way to test that is to first send the patch series to yourself to ensure your environment is set up correctly. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [ANNOUNCE] Key Signing Party at KVM Forum 2013
for each key
you'd signed.
That is relatively slow because it runs gpg --refresh ...
If you've already done that, you can run it like this:
env use_temp_keyring=n refresh=n ./cross-sign YOUR_GPG_KEY_ID
cross-sign:
=
#!/bin/bash
ME=${0##*/}
case $# in
1) my_id=$1 ;;
*) echo Usage: $ME YOUR_GPG_KEY_ID 12; exit 1;;
esac
: ${use_temp_keyring=y}
: ${refresh=y}
# Key IDs of the people who participated in the kvm gpg key-signing.
keys='3bb08b22 2527436a eb918653 6a56d670 3e7e013f f83fa044 d3e87138
fe702db5 241786dd 39bcff63 d018682b 7c18c076 5682e5ff 14360cde c03363f4
74ff0269 afbe8e67 c88f2fd6 aaa7a078 0bd1fee1 7ae5e714 854083b6 f108b584
81ab73c8 c11804f0 4aa920d7'
# Given gpg --list-sig ... output, print only those lines that start
# with uid and contain an @; print each unique name only once.
uid_name_filter() { grep '^uid.*@' | sort -t'' -u -k1,1 | sed 's/^uid
*/ /'; }
if test $use_temp_keyring = y; then
# Create a temporary directory in which to download keys.
export GNUPGHOME=$(mktemp -d)
# Remove it upon interrupt and upon normal termination.
for sig in 1 2 3 13 15; do eval trap 'exit $(expr $sig + 128)' $sig;
done
trap 'rm -fr $GNUPGHOME' 0
# Use a server that's better than the default.
echo keyserver hkp://pool.sks-keyservers.net $GNUPGHOME/gpg.conf
# Get latest keys/signatures from key servers.
gpg --recv-keys $(echo $keys)
else
test $refresh = y \
gpg --refresh-keys $(echo $keys)
fi
echo who appears not to have signed $my_id:
s=$(gpg --list-sig $my_id)
gpg --list-keys \
$(for i in $(echo $keys); do echo $s | grep -q $i || echo $i; done) \
| uid_name_filter
echo
echo who has not yet uploaded a signature by $my_id on their key:
for i in $(echo $keys); do
gpg --list-sig $i | grep -qi $my_id || gpg --list-key $i
done | uid_name_filter
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [libvirt-users] Questions on how to reset ID numbers for virt Guests.
On 09/11/2013 01:59 AM, Daniel P. Berrange wrote: On Wed, Sep 11, 2013 at 09:47:07AM +0200, Paolo Bonzini wrote: Il 11/09/2013 00:27, James Sparenberg ha scritto: I'm doing some experimenting in our Development lab and as a result I'm kickstarting over and over Virtual guests. This is of course causing the guest Id to increment by one with each test. I've googled around and tried searching the list but have not found out how (if at all) it would be possible to reset the ID number back to 1 more than is in use. Also is there a limit where I run out of ID's? (for example does it only go up to 99?) No, there is no limit. Well, 'int' will wrap eventually, but you'd need to have created a hell of alot of guests for that to be a problem :-) 2**31 (~2 billion), to be exact, since we store it as a signed int, and I'm not sure if all the code paths handle a negative number gracefully (see src/datatypes.h:_virDomain). (Maybe we should have picked a 64-bit type, so that wraparound would not be possible within our lifetimes even with a process spawning guests as fast as possible on current computers - but even with a 32-bit number, it's going to take a lot of hammering to hit wraparound) -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [libvirt] [PATCH v2] kvm: warn if num cpus is greater than num recommended
On 08/28/2013 01:45 AM, Andrew Jones wrote: What I'm more worried about is what number is libvirt supposed to show to the end user, and should libvirt enforce the lower recommended max, or the larger kernel absolute max? Which of the two values does the QMP 'MachineInfo' type return in its 'cpu-max' field during the 'query-machines' command? Should we be modifying QMP to return both values, so that libvirt can also expose the logic to the end user of allowing a recommended vs. larger development max? Machine definitions maintain yet another 'max_cpus'. And it appears that qmp would return that value. It would probably be best if it returned max(qemu_machine.max_cpus, kvm_max_cpus) though. I'm starting to think that we should just keep things simple for most of the virt stack by sticking to enforcing the larger developer max. And then on a production kernel we should just compile KVM_MAX_VCPUS = KVM_SOFT_MAX_VCPUS and be done with it. With that thought, this patch could be dropped too. The alternative seems to be supporting a run-time selectable experimental mode throughout the whole virt stack. Indeed - if it is a number you are unwilling to support, don't compile it into the kernel in the first place. Allowing arbitrary limits that are lower than the maximum imply policy, and policy implies touching the stack (because someone, somewhere in the stack, will have good reason for setting policy different than the lowest layer); fix the maximum instead, and the whole stack complies without having to worry about policy. IMO, this is a case where fewer knobs is better. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [libvirt] [PATCH v2] kvm: warn if num cpus is greater than num recommended
On 08/23/2013 07:24 AM, Andrew Jones wrote: The comment in kvm_max_vcpus() states that it's using the recommended procedure from the kernel API documentation to get the max number of vcpus that kvm supports. It is, but by always returning the maximum number supported. The maximum number should only be used for development purposes. qemu should check KVM_CAP_NR_VCPUS for the recommended number of vcpus. This patch adds a warning if a user specifies a number of cpus between the recommended and max. v2: Incorporate tests for max_cpus, which specifies the maximum number of hotpluggable cpus. An additional note is that the message for the fail case was slightly changed, 'exceeds max cpus' to 'exceeds the maximum cpus'. If this is unacceptable change for users like libvirt, then I'll need to spin a v3. A quick grep of libvirt does not show any dependence on the particular wording exceeds max cpus, so you are probably fine changing that. What I'm more worried about is what number is libvirt supposed to show to the end user, and should libvirt enforce the lower recommended max, or the larger kernel absolute max? Which of the two values does the QMP 'MachineInfo' type return in its 'cpu-max' field during the 'query-machines' command? Should we be modifying QMP to return both values, so that libvirt can also expose the logic to the end user of allowing a recommended vs. larger development max? -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] Are there plans to achieve ram live Snapshot feature?
On 08/09/2013 09:45 AM, Anthony Liguori wrote: Chijianchun chijianc...@huawei.com writes: Now in KVM, when RAM snapshot, vcpus needs stopped, it is Unfriendly restrictions to users. Are there plans to achieve ram live Snapshot feature? I think you mean a live version of the savevm command. You can approximate live migrating to a file, creating an external disk snapshot, then resuming the guest. And libvirt does just that, since libvirt 1.0.5, for its external RAM snapshots. The vcpu pause is a mere fraction of a second, so it is generally not noticeable as any guest downtime. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH] qemu-kvm: fix unmatched RAM alloction/free
On 05/23/2013 07:21 PM, Hao, Xudong wrote: Just git pull. :) This is very similar to commit e7a09b9 (osdep: introduce qemu_anon_ram_free to free qemu_anon_ram_alloc-ed memory, 2013-05-13) OK, this commit do the same thing as my patch, I did not notice qemu upstream tree, just take a look at qemu-kvm tree, but I think this commit should be backport to qemu-kvm tree, because many user are using qemu-kvm for KVM. That argues that the qemu-kvm tree needs one final commit that wipes everything and replaces it with a readme file that tells users to upgrade to the qemu upstream tree, now that the qemu-kvm tree has been merged upstream and is no longer actively maintained. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] KVM call minutes for 2013-04-23
On 04/23/2013 10:06 AM, Eric Blake wrote: we can change drive_mirror to use a new command to see if there are the new features. drive-mirror changed in 1.4 to add optional buf-size parameter; right now, libvirt is forced to limit itself to 1.3 interface (no buf-size or granularity) because there is no introspection and no query-* command that witnesses that the feature is present. Idea was that we need to add a new query-drive-mirror-capabilities (name subject to bikeshedding) command into 1.5 that would let libvirt know that buf-size/granularity is usable (done right, it would also prevent the situation of buf-size being a write-only interface where it is set when starting the mirror but can not be queried later to see what size is in use). Unclear whether anyone was signing up to tackle the addition of a query command counterpart for drive-mirror in time for 1.5. Further discussion on this topic: Luiz proposed such a command: https://lists.gnu.org/archive/html/qemu-devel/2013-04/msg04937.html in the meantime, Paolo and I discussed on IRC, and realized that: 1. Current libvirt does not expose buf-size or granularity to the end user. Until a future libvirt release actually wants to use these options, we are in no rush to get it into qemu 1.5; it's okay to leave things in the same state they were in for 1.4, and have qemu 1.6 be the first release that coordinates with a new libvirt release actually wanting to use the options. 2. At least with drive-mirror, the try-and-fail approach generates a reasonable-enough error message. Having a capability query may allow libvirt to save time and/or give a better quality error message, but this is one case where not knowing whether the parameter exists is not a fatal flaw to the algorithm, since libvirt can still gracefully recover from attempting to use the parameter (only when the user requested a non-default value). Distros that want to prove their value-added quality-of-implementation can easily backport whatever solution goes into qemu 1.6 for nicer detection into the distro stable build, even if the distro is based on 1.5; libvirt will use the nicer detection when available but should have no problems using the try-and-fail approach otherwise. So at this point, I'm comfortable with not trying to add anything into 1.5 dealing with drive-mirror; it feels like too much of a new feature past soft freeze with no known current client, where we would be better off waiting to 1.6 to get the interface right. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: KVM call minutes for 2013-04-23
On 04/23/2013 08:45 AM, Juan Quintela wrote: * 1.5 pending patches (paolo) anthony thinks nothing big is outstanding rdma: not probably for this release, too big change on migration cpu-hotplug: andreas expect to get it for 1.5 * What can libvirt expect in 1.5 for introspection of command-line support? command extensions? libvirt want then * What are the rules for adding optional parameters to existing QMP commands? Would it help if we had introspection of QMP commands? what are the options that each command support. command line could work for 1.5 if we got patches on the next 2 days we can get it. Goal is to provide a QMP command that provides JSON representation of command line options; I will help review whatever is posted to make sure we like the interface. Anthony agreed the implementation should be relatively straightforward and okay to add after soft freeze (but must be before hard freeze). Libvirt has some code that would like to make use of the new command-line introspection; Osier will probably be the first libvirt developer taking advantage of it - if we can swing it, we'd like libvirt 1.0.5 to use the new command (libvirt freezes this weekend for a May 2 release). rest of introspection need 1.6 it is challenging we are interesting into feature introspection and comand extensions? one command to return the schema? Anthony was okay with the idea of a full JSON introspection of all QMP commands, but it is probably too big to squeeze into 1.5 timeframe. Furthermore, while the command will be useful, we should always be thinking about API - having to parse through JSON to see if a feature is present is not always the nicest interface; when adding a new feature, consider improving an existing query-* or adding a counterpart new query-* command that makes it much easier to tell if a feature is available, without having to resort to a QMP introspection. if we change a command, how we change the interface without changing the c-api? c-api is not yet a strong consideration (but see [1] below). Also, there may be ways to design a C api that is robust to extensions (but that means designing it into the QMP up front when adding a new command); there has been some list traffic on this thought. More importantly, adding an optional parameter to an existing command is not okay unless something else is also available to tell whether the feature is usable - QMP introspection would solve this, but is not necessarily the most elegant way. For now, while adding QMP introspection is a good idea, we still want case-by-case review of any command extensions. we can change drive_mirror to use a new command to see if there are the new features. drive-mirror changed in 1.4 to add optional buf-size parameter; right now, libvirt is forced to limit itself to 1.3 interface (no buf-size or granularity) because there is no introspection and no query-* command that witnesses that the feature is present. Idea was that we need to add a new query-drive-mirror-capabilities (name subject to bikeshedding) command into 1.5 that would let libvirt know that buf-size/granularity is usable (done right, it would also prevent the situation of buf-size being a write-only interface where it is set when starting the mirror but can not be queried later to see what size is in use). Unclear whether anyone was signing up to tackle the addition of a query command counterpart for drive-mirror in time for 1.5. if we have a stable c-api we can do test cases that work. Having such a testsuite would make a stable C API more important. Eric will complete this with his undrestanding from libvirt point of view. Also under discussion: the existing QMP 'screendump' command is not ideal (not extensible, doesn't allow fd passing, hard-coded output format). This was used as an example command that should not be extended until we have appropriate feature detection in place; probably easier to add a new QMP command than to add parameters to the existing one. At any rate, we're late enough that 'screendump' probably won't be improved in 1.5, so we have the full 1.6 cycle to get it right. Not on the phone call, but a recent mail that is related to the topic - feature detection of whether dump-guest-memory supports paging: https://lists.gnu.org/archive/html/qemu-devel/2013-04/msg04613.html -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] KVM call agenda for 2013-04-23
On 04/22/2013 10:11 AM, Juan Quintela wrote: Hi Please send in any agenda topics you are interested in. * What can libvirt expect in 1.5 for introspection of command-line support? * What are the rules for adding optional parameters to existing QMP commands? Would it help if we had introspection of QMP commands? -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [PATCH v13 1/8] save/load cpu runstate
On 03/01/2013 12:36 AM, Hu Tao wrote: On Thu, Feb 28, 2013 at 02:12:37PM -0700, Eric Blake wrote: On 02/28/2013 05:13 AM, Hu Tao wrote: This patch enables preservation of cpu runstate during save/load vm. So when a vm is restored from snapshot, the cpu runstate is restored, too. What happens if a management app wants to override the runstate when restoring the domain? I can think of several useful scenarios: 1. management app pauses the guest, then saves domain state and other things (management state, or disk clones), then resumes the guest. Later, the management wants to revert to the saved state, but have the guest running right away. I guess here, knowing that the guest was saved in a paused state doesn't hurt, since the management app can resume it right away. 2. management app saves domain state of a live guest, then copies that state elsewhere. In its new location, the management app wants to investigate the state for forensic analysis - so even though the guest remembers that it was running, management wants to start it paused. Here, it is important that there must not be a window of time where the guest can run, otherwise, the results are not reproducible. -S takes precedence in the case. But for in-migration, runstate is loaded from src. Given your answer, I think we're okay from the libvirt perspective. My biggest worry about a window where the guest runs unchecked is not a problem, given that libvirt always uses -S on incoming migration. In turn, libvirt has its own mechanisms for tracking whether the outgoing migration was started from a running state, along with API overrides to let a user override whether libvirt will resume the guest on the incoming migration side. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [PATCH v13 5/8] add a new qevent: QEVENT_GUEST_PANICKED
On 02/28/2013 05:13 AM, Hu Tao wrote: This event will be emited when the guest is panicked. Signed-off-by: Wen Congyang we...@cn.fujitsu.com --- include/monitor/monitor.h | 1 + monitor.c | 1 + 2 files changed, 2 insertions(+) Missing documentation in QMP/qmp-events.txt -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [PATCH v13 1/8] save/load cpu runstate
On 02/28/2013 05:13 AM, Hu Tao wrote: This patch enables preservation of cpu runstate during save/load vm. So when a vm is restored from snapshot, the cpu runstate is restored, too. What happens if a management app wants to override the runstate when restoring the domain? I can think of several useful scenarios: 1. management app pauses the guest, then saves domain state and other things (management state, or disk clones), then resumes the guest. Later, the management wants to revert to the saved state, but have the guest running right away. I guess here, knowing that the guest was saved in a paused state doesn't hurt, since the management app can resume it right away. 2. management app saves domain state of a live guest, then copies that state elsewhere. In its new location, the management app wants to investigate the state for forensic analysis - so even though the guest remembers that it was running, management wants to start it paused. Here, it is important that there must not be a window of time where the guest can run, otherwise, the results are not reproducible. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH V4 RESEND 05/22] net: intorduce qemu_del_nic()
On 02/01/2013 12:39 AM, Jason Wang wrote: s/intorduce/introduce/ in the subject To support multiqueue nic, this patch separate the nic destructor from s/separate/separates/ qemu_del_net_client() to a new helper qemu_del_nic() since the mapping bettween s/bettween/between/ NiCState and NetClientState were not 1:1 in multiqueue. The following patches would refactor this function to support multiqueue nic. Signed-off-by: Jason Wang jasow...@redhat.com Signed-off-by: Michael S. Tsirkin m...@redhat.com --- -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH V4 RESEND 15/22] tap: multiqueue support
On 02/01/2013 12:39 AM, Jason Wang wrote: Recently, linux support multiqueue tap which could let userspace call TUNSETIFF for a signle device many times to create multiple file descriptors as s/signle/single/ independent queues. User could also enable/disabe a specific queue through s/disabe/disable/ TUNSETQUEUE. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH V4 00/22] Multiqueue virtio-net
On 01/31/2013 12:00 AM, Jason Wang wrote: On 01/31/2013 02:29 AM, Eric Blake wrote: On 01/30/2013 04:12 AM, Jason Wang wrote: With this changes, user could start a multiqueue virtio-net device through ./qemu -netdev tap,id=hn0,queues=2,vhost=on -device virtio-net-pci,netdev=hn0 Management tools such as libvirt can pass multiple pre-created fds/vhostfds through ./qemu -netdev tap,id=hn0,fds=X:Y,vhostfds=M:N -device virtio-net-pci,netdev=hn0 Do we really need specific fds= parsing, or can we reuse the existing -add-fd command line option to our advantage? I guess what I'm asking is how hotplug will work; and if hotplug takes a file name, shouldn't the command line also take a name; and if the command line takes a name, what's wrong with: ./qemu -add-fd fdset=1,fd=X -add-fd fdset=2,fd=Y -add-fd fdset=3,fd=M -add-fd fdset=4,fd=N -netdev tap,id=hn0,fds=/dev/fdset/1:/dev/fdset/2,vhostfds=/dev/fdset/3:/dev/fdset/4 -device virtio-net-pci,netdev=hn0 AFAIK, tap does not support fdset now, so this requirement is beyond the scope of multiqueue itself. We can do this in the future. Btw does libvirt support add-fd now? Anything that uses qemu_open() supports fdset now. The question I'm asking is whether the command line has a way to pass /path/to/name (which can be presented as /dev/fdset/nnn for add-fd usage) now, or whether it only supports fds=integers. For hotplug, it just work if you pass multiple file descriptors one by one through getfd and then use fds=X:Y,vhostfds=M:N. For hotplug, you can't pass integers; you have to name the fds either way. Either you name it with getfd, or you name it with add-fd. But getfd is not as nice as add-fd when it comes to ensuring that fds are not leaked in qemu, even when the management app such as libvirt restarts. Furthermore, if it is possible to specify taps by pathname instead of by fd inheritance, then using getfd means you have to support two different approaches in QMP to distinguish which string is being supplied, while supporting add-fd means you only have to support qemu_open() which handles both direct names and fd passing in a single string interface. As for libvirt support of add-fd, I'm currently working with Stefan Berger to get patches applied; the goal is tha libvirt 1.0.3 (end of February) will support add-fd. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH V4 00/22] Multiqueue virtio-net
On 01/31/2013 06:58 AM, Michael S. Tsirkin wrote: For hotplug, it just work if you pass multiple file descriptors one by one through getfd and then use fds=X:Y,vhostfds=M:N. For hotplug, you can't pass integers; you have to name the fds either way. Either you name it with getfd, or you name it with add-fd. But getfd is not as nice as add-fd when it comes to ensuring that fds are not leaked in qemu, even when the management app such as libvirt restarts. Furthermore, if it is possible to specify taps by pathname instead of by fd inheritance, I don't think there's a way to specify taps by pathname. Then using fds=integer:integer on the command line makes the most sense, and QMP uses fds=name:name where name was specified by 'getfd', and there is no way to wire up qemu_open() nor any need to use 'add-fd'. Okay, my question has been answered, your approach looks right now that I know more about how -netdev works to begin with. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH for-1.4 04/12] kvm: Create kvm_arch_vcpu_id() function
On 01/21/2013 06:14 AM, Andreas Färber wrote: glibc is already responsible from converting the 'unsigned long int' of the user declaration back into the 'unsigned int' that the kernel expects for the second argument. The third argument (when present), is generally treated as a pointer (of size appropriate for the architecture). Although there _might_ be an ioctl that uses it directly as an integer instead of dereferencing it as a pointer, those would be the exceptions to the rule. So ... do we have a conclusion what to put into the commit message? :) It looks to me as if kvm-all.c:kvm_vm_ioctl() is using void*. I like unsigned long but maybe uintptr_t would be more correct then? uintptr_t feels more correct - the 3rd (vararg) argument through the ioctl() syscall is always retrieved using the same size as void*. Or should kvm_vm_ioctl() be fixed to use something else instead? Eric's int would be a semantic change for the 64-bit platforms, no? My discussion about 'int' vs. 'unsigned long' was in regards to the second argument KVM_CREATE_VCPU, which your patch does not change (perhaps my fault for jumping in on a conversation mid-thread without actually reading your original patch, which I have now done). That is, KVM_CREATE_VCPU as a constant is always 32 bits (kernel constraint), widened out to unsigned long when passed to the glibc function (due to the glibc signature disagreeing with POSIX), then narrowed back down to 32 bits when forwarded to the kernel syscall. Meanwhile, your patch is fixing the third argument from 'int' to a wider type, which is necessary for passing that value through varargs when the receiving end will retrieve the same argument via a void* variable. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH for-1.4 04/12] kvm: Create kvm_arch_vcpu_id() function
On 01/18/2013 07:20 AM, Eduardo Habkost wrote: Could you suggest a text for me to add please? The argument passed to KVM_CREATE_VCPU now has 'unsigned long' type instead of 'int', as expected by the Linux ioctl() syscall. Maybe an int works on most or all architectures supporting KVM, but it is safer to use an appropriate 'unsigned long' parameter. Interestingly enough, while the Linux syscall uses 'unsigned long', the POSIX definition of ioctl() uses 'int'; so the Linux kernel is already constrained to never use an ioctl value that doesn't fit within 'int', and glibc is already responsible for ensuring that argument promotion of an int doesn't change the behavior of ioctl() in libc when converting it over to the unsigned long syscall semantics expected by the kernel. To find out if 'int' breaks on any architecture, I would need to check the ABI specification for each architecture. I didn't do that, but I am sure we should pass an unsigned long instead, if that's the type expected by the kernel. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH for-1.4 04/12] kvm: Create kvm_arch_vcpu_id() function
On 01/18/2013 09:40 AM, Eduardo Habkost wrote:
On Fri, Jan 18, 2013 at 09:11:42AM -0700, Eric Blake wrote:
On 01/18/2013 07:20 AM, Eduardo Habkost wrote:
Could you suggest a text for me to add please?
The argument passed to KVM_CREATE_VCPU now has 'unsigned long' type
instead of 'int', as expected by the Linux ioctl() syscall. Maybe an int
works on most or all architectures supporting KVM, but it is safer to
use an appropriate 'unsigned long' parameter.
Interestingly enough, while the Linux syscall uses 'unsigned long', the
POSIX definition of ioctl() uses 'int'; so the Linux kernel is already
constrained to never use an ioctl value that doesn't fit within 'int',
Really? What about the ioctl()s that get a pointer as argument on
architectures where pointers don't fit in an int?
Do you have a pointer to the POSIX definition you are talking about?
Note that I'm talking about the the extra ioctl() argument, not the
ioctl() number (that is an unsigned int in the kernel code).
Okay, now you made me go back and check sources.
POSIX 2008 says:
#include stropts.h
int ioctl(int fildes, int request, ... /* arg */);
Gnulib says this about a bug that it works around:
@item
On glibc platforms, the second parameter is of type @code{unsigned long}
rather than @code{int}.
But gnulib also suggests using sys/ioctl.h instead of the POSIX header
stropts.h for getting ioctl(), because stropts.h was declared
obsolete in POSIX 2008 and was never implemented in glibc.
Sure enough, looking at Fedora 18 /usr/include/sys/ioctl.h, I still see:
extern int ioctl (int __fd, unsigned long int __request, ...) __THROW;
Meanwhile, you are correct that the kernel defines request as 32 bits:
linux.git:include/uapi/asm-generic/ioctl.h
/* ioctl command encoding: 32 bits total, command in lower 16 bits,
* size of the parameter structure in the lower 14 bits of the
* upper 16 bits.
* Encoding the size of the parameter structure in the ioctl request
* is useful for catching programs compiled with old versions
* and to avoid overwriting user space outside the user buffer area.
* The highest 2 bits are reserved for indicating the ``access mode''.
* NOTE: This limits the max parameter size to 16kB -1 !
*/
and glibc is already responsible for ensuring that argument promotion of
an int doesn't change the behavior of ioctl() in libc when converting it
over to the unsigned long syscall semantics expected by the kernel.
So a more precise wording of this is:
glibc is already responsible from converting the 'unsigned long int' of
the user declaration back into the 'unsigned int' that the kernel
expects for the second argument. The third argument (when present), is
generally treated as a pointer (of size appropriate for the
architecture). Although there _might_ be an ioctl that uses it directly
as an integer instead of dereferencing it as a pointer, those would be
the exceptions to the rule.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH v3 27/35] postcopy/outgoing: implement forward/backword prefault
On 11/01/2012 11:24 PM, Isaku Yamahata wrote:
+++ b/qapi-schema.json
@@ -2095,7 +2095,8 @@
##
{ 'command': 'migrate',
'data': {'uri': 'str', '*blk': 'bool', '*inc': 'bool', '*detach': 'bool'
,
- '*postcopy': 'bool', '*nobg': 'bool'} }
+ '*postcopy': 'bool', '*nobg': 'bool',
+ '*forward': 'int', '*backward': 'int'} }
Do we really want to be adding new options to migrate (and if so,
where's the documentation), or do we need a new monitor command similar
to migrate-set-capabilities or migrate-set-cache-size?
Okay, migrate-set-capabilities seems usable for boolean and scalable
for future extension.
On the other hand, migrate-set-cache-size takes only single integer
as arguments. So it doesn't seem usable without modification.
How about this?
{ 'type': 'MigrationParameters',
'data': {'parameter': 'name': 'str', 'value': 'int' } }
More like:
{ 'enum': 'MigrationParameterName',
'data': ['ParameterName'... ] }
{ 'type': 'MigrationParameter',
'data': {'parameter': 'MigrationParameterName', 'value': 'int' } }
{ 'command': 'migrate-set-parameters',
'data': { 'parameters' ['MigrationParameters']}}
Yes, this seems more extensible.
{ 'command': 'query-migrate-parameters',
'returns': [['MigrationParameters']]}
One layer too many of [], but yes, this also seems reasonable.
--
Eric Blake ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH v3 24/35] postcopy outgoing: add -p option to migrate command
On 10/30/2012 02:33 AM, Isaku Yamahata wrote:
Added -p option to migrate command for postcopy mode and
introduce postcopy parameter for migration to indicate that postcopy mode
is enabled.
Signed-off-by: Isaku Yamahata yamah...@valinux.co.jp
diff --git a/qapi-schema.json b/qapi-schema.json
index c615ee2..c969e5a 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -2094,7 +2094,8 @@
# Since: 0.14.0
##
{ 'command': 'migrate',
- 'data': {'uri': 'str', '*blk': 'bool', '*inc': 'bool', '*detach': 'bool' }
}
+ 'data': {'uri': 'str', '*blk': 'bool', '*inc': 'bool', '*detach': 'bool' ,
+ '*postcopy': 'bool'} }
You should also document this new variable a few lines earlier,
something like:
# @postcopy: #optional if true, perform a postcopy migration
#(since 1.3, default false)
Also, I have to wonder if this should go through
migrate-set-capabilities rather than adding a new field to 'migrate'.
--
Eric Blake ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH v3 26/35] postcopy/outgoing: add -n options to disable background transfer
On 10/30/2012 02:33 AM, Isaku Yamahata wrote:
This is for benchmark purpose
Signed-off-by: Isaku Yamahata yamah...@valinux.co.jp
+++ b/qapi-schema.json
@@ -2095,7 +2095,7 @@
##
{ 'command': 'migrate',
'data': {'uri': 'str', '*blk': 'bool', '*inc': 'bool', '*detach': 'bool' ,
- '*postcopy': 'bool'} }
+ '*postcopy': 'bool', '*nobg': 'bool'} }
Again, document this option above, and mention that it was introduced in
1.3. In QMP, we prefer easier-to-read strings, I would consider naming
it 'background' with a default of true, where you pass false to get the
new behavior, instead of 'nobg' with a default of false and causing
double-negative logic.
--
Eric Blake ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH v3 27/35] postcopy/outgoing: implement forward/backword prefault
On 10/30/2012 02:33 AM, Isaku Yamahata wrote:
When page is requested, send surrounding pages are also sent.
Signed-off-by: Isaku Yamahata yamah...@valinux.co.jp
---
hmp-commands.hx | 15 -
hmp.c|3 +++
migration-postcopy.c | 57
+-
migration.c | 20 ++
migration.h |2 ++
qapi-schema.json |3 ++-
6 files changed, 89 insertions(+), 11 deletions(-)
diff --git a/hmp-commands.hx b/hmp-commands.hx
index b054760..5e2c77c 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -826,26 +826,31 @@ ETEXI
{
.name = migrate,
-.args_type = detach:-d,blk:-b,inc:-i,postcopy:-p,nobg:-n,uri:s,
-.params = [-d] [-b] [-i] [-p [-n]] uri,
+.args_type = detach:-d,blk:-b,inc:-i,postcopy:-p,nobg:-n,uri:s,
+ forward:i?,backward:i?,
+.params = [-d] [-b] [-i] [-p [-n] uri [forward] [backword],
I don't care what we do to the 'migrate' HMP command, but for QMP...
+++ b/qapi-schema.json
@@ -2095,7 +2095,8 @@
##
{ 'command': 'migrate',
'data': {'uri': 'str', '*blk': 'bool', '*inc': 'bool', '*detach': 'bool' ,
- '*postcopy': 'bool', '*nobg': 'bool'} }
+ '*postcopy': 'bool', '*nobg': 'bool',
+ '*forward': 'int', '*backward': 'int'} }
Do we really want to be adding new options to migrate (and if so,
where's the documentation), or do we need a new monitor command similar
to migrate-set-capabilities or migrate-set-cache-size?
--
Eric Blake ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH v3 29/35] postcopy/outgoing: add movebg mode(-m) to migration command
On 10/30/2012 02:33 AM, Isaku Yamahata wrote:
When movebg mode is enabled, the point to send background page is set
to the next page to on-demand page.
Signed-off-by: Isaku Yamahata yamah...@valinux.co.jp
+ -m for migratoin with postcopy mode enabled with moving position
s/migratoin/migration/
+++ b/qapi-schema.json
@@ -2095,7 +2095,7 @@
##
{ 'command': 'migrate',
'data': {'uri': 'str', '*blk': 'bool', '*inc': 'bool', '*detach': 'bool' ,
- '*postcopy': 'bool', '*nobg': 'bool',
+ '*postcopy': 'bool', '*movebg': 'bool', '*nobg': 'bool',
Another undocumented option, and one which might be better named
'move-background'. Also another candidate for migrate-set-capabilities.
--
Eric Blake ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH v3 34/35] postcopy/outgoing: introduce precopy_count parameter
On 10/30/2012 02:33 AM, Isaku Yamahata wrote: Precopy with this loop number before postcopy mode. This will be implemented by the next patch. Signed-off-by: Isaku Yamahata yamah...@valinux.co.jp --- +++ b/qapi-schema.json @@ -2089,6 +2089,8 @@ # @detach: this argument exists only for compatibility reasons and # is ignored by QEMU # +# @precopy_count: #optional the number of loops of precopy when postcopy +# Finally, a documented addition; but still lacking (since 1.3) designation. Also, QMP prefers '-' over '_', so I would name it precopy-count, if we even decide to attach it to 'migrate' instead of a new command or enhancement to 'migrate-set-capabilities'. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [RFC PATCH v3 11/19] Implement qmp and hmp commands for notification lists
On 09/21/2012 05:17 AM, Vasilis Liaskovitis wrote:
Guest can respond to ACPI hotplug events e.g. with _EJ or _OST method.
This patch implements a tail queue to store guest notifications for memory
hot-add and hot-remove requests.
Guest responses for memory hotplug command on a per-dimm basis can be detected
with the new hmp command info memhp or the new qmp command query-memhp
Naming doesn't match the QMP code.
Examples:
(qemu) device_add dimm,id=ram0
These notification items should probably be part of migration state (not yet
implemented).
In the case of libvirt driving migration, you already said in 10/19 that
libvirt has to start the destination with the populated=on|off fields
correct for each dimm according to the state it was in at the time the
host started the update. Can the host hot unplug memory after migration
has started?
+
+##
+# @MemHpInfo:
+#
+# Information about status of a memory hotplug command
+#
+# @dimm: the Dimm associated with the result
+#
+# @result: the result of the hotplug command
+#
+# Since: 1.3
+#
+##
+{ 'type': 'MemHpInfo',
+ 'data': {'dimm': 'str', 'request': 'str', 'result': 'str'} }
Should 'result' be a bool (true for success, false for still pending) or
an enum, instead of a free-form string? Likewise, isn't 'request' going
to be exactly one of two values (plug or unplug)?
--
Eric Blake ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [RFC PATCH v3 12/19] Implement info memory-total and query-memory-total
On 09/21/2012 05:17 AM, Vasilis Liaskovitis wrote:
Returns total physical memory available to guest in bytes, including
hotplugged
memory. Note that the number reported here may be different from what the
guest
sees e.g. if the guest has not logically onlined hotplugged memory.
This functionality is provided independently of a balloon device, since a
guest can be using ACPI memory hotplug without using a balloon device.
Signed-off-by: Vasilis Liaskovitis vasilis.liaskovi...@profitbricks.com
+++ b/hmp-commands.hx
@@ -1464,6 +1464,8 @@ show qdev device model list
show roms
@item info memory-hotplug
show memory-hotplug
+@item info memory-total
+show memory-total
+++ b/monitor.c
@@ -2747,6 +2747,13 @@ static mon_cmd_t info_cmds[] = {
.mhandler.info = hmp_info_memory_hotplug,
},
{
+.name = memory-total,
We're split on HMP naming conventions ('-' vs. '_'); we have 'show
migrate_capabilities' but 'show block-jobs'. Oh well, that's life.
Reviewed-by: Eric Blake ebl...@redhat.com
--
Eric Blake ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [libvirt-users] Kernel unresponsive after booting 700+ vm's on a single host
On 09/10/2012 07:51 AM, Alfred Bratterud wrote: For a research project we are trying to boot a very large amount of tiny, custom built VM's on KVM/ubuntu. The maximum VM-count achieved was 1000, but with substantial slowness, and eventually kernel failure, while the cpu/memory loads were nowhere near limits. Where is the likely bottleneck? Any solutions, workarounds, hacks or dirty tricks? Are you using cgroups? There have been some known bottlenecks in the kernel cgroup code, where it scales very miserably; and since libvirt uses a different cgroup per VM by default when cgroups are enabled, that might explain part of the problem. Other than that, if you can profile the slowdowns, I'm sure people would be interested in the results. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH 4/4] kvm: i386: Add classic PCI device assignment
On 09/05/2012 01:04 PM, Blue Swirl wrote: I don't mind GPLv2+, if people want to share code from QEMU in GPLv3 projects, GPLv2+ enables that. The advantage of 100% GPLv2+ (or other GPLv3 compatible) would be that QEMU could share code from GPLv3 projects, specifically latest binutils. Reinventing a disassembler for ever growing x86 assembly is no fun. Not quite right. If qemu is 100% GPLv2+ and binutils is GPLv3+, then binutils can borrow code from qemu and the result is that binutils is still GPLv3+; but in the converse direction, if qemu borrows code from binutils then qemu is no longer 100% GPLv2+ but becomes GPLv3+ by tainting. That is, requesting GPLv2+ allows qemu code to be reused elsewhere, but does not help qemu import external code that is not already GPLv2+. But if new code is coming in and happens to be under GPLv2, that just means that the contribution cannot be used outside of QEMU in a GPLv3 project. That's fine and that's a decision for the submitter to make. This policy means that we are locked in with GPLv2. I'm afraid we're already locked at GPLv2 (and not GPLv2+), for good or for bad. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
On 08/13/2012 12:21 PM, Marcelo Tosatti wrote: On Wed, Aug 08, 2012 at 10:43:01AM +0800, Wen Congyang wrote: We can know the guest is panicked when the guest runs on xen. But we do not have such feature on kvm. Another purpose of this feature is: management app(for example: libvirt) can do auto dump when the guest is panicked. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is panicked. We have three solutions to implement this feature: 1. use vmcall 2. use I/O port 3. use virtio-serial. We have decided to avoid touching hypervisor. The reason why I choose choose the I/O port is: 1. it is easier to implememt 2. it does not depend any virtual device 3. it can work when starting the kernel How about searching for the Kernel panic - not syncing string in the guests serial output? Say libvirtd could take an action upon that? Advantages: - It works for all architectures. - It does not depend on any virtual device. But it _does_ depend on a serial console, and furthermore requires libvirt to tee the serial console (right now, libvirt can treat the console as an opaque pass-through to the end user, but if you expect libvirt to parse the serial console for a particular string, you've lost some efficiency). - It works as early as serial console output does (panics before that should be rare). - It allows you to see why the guest panicked. I think your arguments for a serial console have already been made and refuted in earlier versions of this patch series, which is WHY this series is still applicable. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [RFC PATCH v2 13/21] Implement memory hotplug notification lists
On 07/11/2012 04:31 AM, Vasilis Liaskovitis wrote:
Guest can respond to ACPI hotplug events e.g. with _EJ or _OST method.
This patch implements a tail queue to store guest notifications for memory
hot-add and hot-remove requests.
Guest responses for memory hotplug command on a per-dimm basis can be detected
with the new hmp command info memhp or the new qmp command query-memhp
Examples:
+++ b/qapi-schema.json
@@ -1862,3 +1862,29 @@
# Since: 0.14.0
##
{ 'command': 'netdev_del', 'data': {'id': 'str'} }
+
+##
+# @MemHpInfo:
+#
+# Information about status of a memory hotplug command
+#
+# @Dimm: the Dimm associated with the result
+#
+# @result: the result of the hotplug command
+#
+# Since: 1.1.3
Should probably be 1.2, not 1.1.3.
+#
+##
+{ 'type': 'MemHpInfo',
+ 'data': {'Dimm': 'str', 'request': 'str', 'result': 'str'} }
Why the upper case? Wouldn't 'dimm' be more consistent?
+
+##
+# @query-memhp:
Why are we abbreviating? It might be better to name the QMP command
query-memory-hotplug
+#
+# Returns a list of information about pending hotplug commands
+#
+# Returns: a list of @MemhpInfo
+#
+# Since: 1.1.3
Likewise for 1.2.
+
+- Dimm: Dimm name (json-str)
+- request: type of hot request: hot-add or hot-remove (json-str)
+- result: result of the hotplug request for this Dimm success or failure
(json-str)
This may need tweaks (such as s/Dimm/dimm/) based on resolution of above
comments.
--
Eric Blake ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [RFC PATCH v2 19/21] Implement info memtotal and query-memtotal
On 07/11/2012 04:32 AM, Vasilis Liaskovitis wrote:
Returns total memory of guest in bytes, including hotplugged memory.
Signed-off-by: Vasilis Liaskovitis vasilis.liaskovi...@profitbricks.com
Should this instead be merged with query-balloon output, so that we have
a single command that shows all aspects of memory usage (both balloon
and hotplug at once)?
@@ -1888,3 +1888,15 @@
# Since: 1.1.3
##
{ 'command': 'query-memhp', 'returns': ['MemHpInfo'] }
+
+##
+# @query-memtotal:
A more generic name might be 'query-memory', especially if we merge
balloon and hotplug information into one command.
+#
+# Returns total memory in bytes, including hotplugged dimms
+#
+# Returns: a l
truncated
--
Eric Blake ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH 2/3] KVM: Use -cpu best as default on x86
On 07/09/2012 06:10 AM, Alexander Graf wrote: This fixes a lot of subtle breakage in the GNU toolchain (libgmp) which hicks up on QEMU's non-existent CPU models. s/hicks up/hiccups/ v2 - v3: - fix typo in commit message but not all of them :) -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH 2/3] KVM: Use -cpu best as default on x86
On 07/09/2012 07:48 AM, Alexander Graf wrote: On 09.07.2012, at 15:47, Eric Blake wrote: On 07/09/2012 06:10 AM, Alexander Graf wrote: This fixes a lot of subtle breakage in the GNU toolchain (libgmp) which hicks up on QEMU's non-existent CPU models. s/hicks up/hiccups/ v2 - v3: - fix typo in commit message but not all of them :) I hope you don't expect me to respin now :) I don't. If someone wants to touch it up, great; if not, it's not the first typo in a commit. :) -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] KVM call agenda for Tuesday, July 3rd
On 07/02/2012 04:16 AM, Juan Quintela wrote: Hi Please send in any agenda items you are interested in covering. Can we discuss the future of 'getfd', the possibility of 'pass-fd', or even the enhancement of all existing monitor commands to take an optional 'nfds' JSON argument for atomic management of fd passing? Which commands need to reopen a file with different access, and do we bite the bullet to special case all of those commands to allow fd passing or can we make qemu_open() coupled with high-level fd passing generic enough to satisfy all of our reopen needs? -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH] Fixes related to processing of qemu's -numa option
On 06/18/2012 04:05 PM, Andreas Färber wrote: Am 17.06.2012 22:12, schrieb Chegu Vinod: diff --git a/vl.c b/vl.c index 204d85b..1906412 100644 --- a/vl.c +++ b/vl.c @@ -28,6 +28,7 @@ #include errno.h #include sys/time.h #include zlib.h +#include sched.h Did you check whether this and the macros you're using are available on POSIX and mingw32? vl.c is a pretty central file. POSIX, yes. mingw32, no. Use of preprocessor conditionals is probably in order. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [QEMU 1.1 PATCH v2] Expose CPUID leaf 7 only for -cpu host
On 05/17/2012 10:26 AM, Eduardo Habkost wrote: The problem is that this makes the resulting CPU feature flags unpredictable and dependent on the host CPU and kernel version. This breaks live-migration badly if migrating from a host CPU that supports some features on that CPUID leaf (running a recent kenrel) to a kernel s/kenrel/kernel/ -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH v2] deal with guest paniced event
On 03/06/2012 06:58 PM, Wen Congyang wrote: When the host knows the guest is paniced, it will set exit_reason to KVM_EXIT_GUEST_PANICED. So if qemu receive this exit_reason, we can send a event to tell management application that the guest is paniced and set the guest status to RUN_STATE_PANICED. s/PANICED/PANICKED/ throughout your series, for the correct spelling of the past tense of panic. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PULL] Urgent memory fix for kvm with unaligned memory slots
On 03/01/2012 10:03 AM, Avi Kivity wrote: -ram = memory_region_get_ram_ptr(mr) + section-offset_within_region; +ram = memory_region_get_ram_ptr(mr) + section-offset_within_region + delta; Am I crazy, or does this look wrong? Could be both. Why do you thing it is wrong? Line wrapping makes it look like we are adding two lines, one line ending in 'section-offset_within_region', and the next line starting with 'delta;', which is a syntax error. But without line wrapping, we are adding just one line with 'offset_within_region + delta;' at the end of that line. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
blockdev operations [was: [Qemu-devel] KVM call agenda for Tuesday 28th]
On 02/28/2012 07:58 AM, Stefan Hajnoczi wrote:
On Tue, Feb 28, 2012 at 2:47 PM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 28/02/2012 15:39, Stefan Hajnoczi ha scritto:
I'm not a fan of transactions or freeze/thaw (if used to atomically
perform other commands).
We should not export low-level block device operations so that
external software can micromanage via QMP. I don't think this is a
good idea because it takes the block device offline and possibly
blocks the VM. We're reaching a level comparable to an HTTP interface
for acquiring pthread mutex, doing some operations, and then another
HTTP request to unlock it. This is micromanagement it will create
more problems because we will have to support lots of little API
functions.
So you're for extending Jeff's patches to group mirroring etc.?
That's also my favorite one, assuming we can do it in time for 1.1.
Yes, that's the approach I like the most. It's relatively clean and
leaves us space to develop -blockdev.
Here's the idea I was forming based on today's call:
Jeff's idea of a group operation can be extended to allow multiple
operations while reusing the framework. For oVirt, we need the ability
to open a mirror (by passing the mirror file alongside the name of the
new external snapshot), as well as reopening a blockdev (to pivot to the
other side of an already-open mirror).
Is there a way to express a designated union in QMP? I'm thinking
something along the lines of having the overall group command take a
list of operations, where each operation can either be 'create a
snapshot', 'create a snapshot and mirror', or 'reopen a mirror'.
I'm thinking it might look something like:
{ 'enum': 'BlockdevOp',
'data': [ 'snapshot', 'snapshot-mirror', 'reopen' ] }
{ 'type': 'BlockdevAction',
'data': {'device': 'str', 'op': 'BlockdevOp',
'file': 'str', '*format': 'str', '*reuse': 'bool',
'*mirror': 'str', '*mirror-format': 'str' } }
{ 'command': 'blkdev-group-action-sync',
'data': { 'actionlist': [ 'BlockdevAction' ] } }
The overall command is atomic - either all operations will succeed, or
the command returns an error pointing to the name of the device that
failed leaving all devices in their pre-command state. Then, for each
requested operation:
If op is 'snapshot', then 'file' names the new snapshot file; 'reuse' is
optional (defaults to false) to say whether qemu creates the file from
scratch, or opens an existing file with the backing file already
populated correctly. 'format' gives the format of 'file', defaulting to
qcow2. 'mirror' and 'mirror-format' must not be given.
If op is 'snapshot-mirror', then 'mirror' is mandatory; and both 'file'
and 'mirror' are opened as a new mirrored snapshot. Again, 'reuse'
affects whether qemu creates the new files from scratch or trusts oVirt
to pre-create both files with backing file information; and 'format' and
'mirror-format' allow control over the image format being opened.
If op is 'reopen', then 'file' is the name of the file to be opened to
replace the current file tied to the blockdev, with type given by
'format'. 'reuse', 'mirror', and 'mirror-format' must not be given.
--
Eric Blake ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] KVM call agenda for Tuesday 28th
On 02/27/2012 05:22 AM, Juan Quintela wrote: Hi Please send in any agenda items you are interested in covering. Given all the threads on snapshot/mirror/migrate/reopen in the blockdev layer, that sounds like a worthwhile topic to discuss on a phone call. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
inconsistent use of $TMP vs. $TMPDIR
I noticed today that various kvm source files are inconsistent on the use of $TMP vs. $TMPDIR: $ git grep -l '\$TMP\b' | cat scripts/Kbuild.include tools/perf/feature-tests.mak $ git grep -l '\$TMPDIR\b' | cat Documentation/lguest/extract According to POSIX, you should probably be using $TMPDIR instead of $TMP when referring to the preferred temporary directory location. http://www.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_03 -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
