QEMU - Recent changes [en]

QMP

LuizCapitulino — Thu, 17 May 2012 18:07:17 GMT

TODO:

← Older revision		Revision as of 18:07, 17 May 2012
(13 intermediate revisions not shown)
Line 1:		Line 1:
	= QEMU Monitor Protocol =		= QEMU Monitor Protocol =

-	The QEMU Monitor Protocol (QMP) is a [http://www.json.org/ JSON]-based protocol which allows applications to communicate with QEMU~~'s Monitor the right way~~.	+	The QEMU Monitor Protocol (QMP) is a [http://www.json.org/ JSON]-based protocol which allows applications to communicate with a QEMU instance.

	QMP's main features are:		QMP's main features are:
Line 14:		Line 14:
	== Status ==		== Status ==

-	A supported version of QMP is available since QEMU 0.~~13 (and a "feature preview" version was available in QEMU 0.12), however several commands in the current API have badly defined semantics~~.	+	A supported version of QMP is available since QEMU 0.14.

-	~~This means that '''~~we will ~~be introducing~~ a deprecation policy ~~soon'''. Users should always check QMP's documentation as soon as a new release of QEMU is out, so that they don't run in~~ the ~~risk of using a deprecated command which may be removed in a future release~~.	+	However, several commands in the current API have badly defined semantics. To address this, we plan to begin adding replacement commands soon. We will also have a deprecation policy for the old commands.

	== Examples ==		== Examples ==

-	~~In the following examples, 'C' stands for 'Client'~~ and ~~'S' stands for 'Server'~~.	+	The first example explains some important details about QMP. The others are simpler and run on top of the first one.

-	~~===~~ Server ~~Greeting ===~~	+	In all examples, 'C' stands for 'Client' and 'S' stands for 'Server'.

-	~~S: { "QMP": { "version": { "qemu": { "micro": 50, "minor": 13, "major": 0 }, "package": "" }, "capabilities": []}}~~	+	=== Capabilities Negotiation ===

-	~~=== Query VM status ===~~	+	When a new QMP connection is established, QMP sends its greeting message and enters ''capabilities negotiation mode''. In this mode, only the "qmp_capabilities" command works. To exit negotiation mode and enter ''command mode'', the qmp_capabilities command must be issued.

-	C: { "execute": "~~query-status~~" }	+	S: {
-	S: { "return": { "~~singlestep~~"~~: false, "running~~": ~~true~~ } }	+	"QMP": {
		+	"version": {
		+	"qemu": {
		+	"micro": 0,
		+	"minor": 0,
		+	"major": 1
		+	},
		+	"package": ""
		+	},
		+	"capabilities": [
		+	]
		+	}
		+	}
		+	C: { "execute": "qmp_capabilities" }
		+	S: { "return": {}}
		+
		+	The "{ "return": {}}" response is QMP's success response. An error response will contain the "error" keyword instead of "return".

	=== Eject a medium ===		=== Eject a medium ===
Line 35:		Line 51:
	C: { "execute": "eject", "arguments": { "device": "ide1-cd0" } }		C: { "execute": "eject", "arguments": { "device": "ide1-cd0" } }
	S: { "return": {}}		S: { "return": {}}
		+
		+	=== Query VM status ===
		+
		+	C: { "execute": "query-status" }
		+	S: {
		+	"return": {
		+	"status": "running",
		+	"singlestep": false,
		+	"running": true
		+	}
		+	}

	=== Asynchronous message ===		=== Asynchronous message ===
Line 43:		Line 70:
	"action": "stop" },		"action": "stop" },
	"timestamp": { "seconds": 1265044230, "microseconds": 450486 } }		"timestamp": { "seconds": 1265044230, "microseconds": 450486 } }
-

	== Development ==		== Development ==

-	Main ~~developers are~~ [mailto:lcapitulino@redhat.com Luiz Capitulino] ~~and [mailto:armbru@redhat~~.~~com Markus Armbruster], but all~~ QMP-related discussions happen on the [http://lists.nongnu.org/mailman/listinfo/qemu-devel qemu-devel] mailing list.	+	Main developer in charge is [mailto:lcapitulino@redhat.com Luiz Capitulino]. All QMP-related discussions happen on the [http://lists.nongnu.org/mailman/listinfo/qemu-devel qemu-devel] mailing list.

	Next features, hot fixes and other patches are stored in the QMP unstable repository:		Next features, hot fixes and other patches are stored in the QMP unstable repository:
Line 57:		Line 83:
	=== TODO ===		=== TODO ===

-	~~==== 0.14 ====~~	+	More or less in order of dependency and importance.
-		+
-	* Re-work the error infrastructure (Markus)	+
-	* Document HMP and ~~QMP handler writing procedure (Luiz)~~	+
-	* Keep decoupling QMP and HMP (Luiz)	+
-	* Asynchronous commands API (requires decoupling HMP and QMP see [[Features/QMP_0.14]]) (Luiz)	+
-	* Disk media change event (Luiz)	+
-	* Improve QMP testing (see [[QMPTestingTodo]]) (all QMP developers)	+
-		+
-	~~==== medium/long term ====~~	+
-		+
-	* Self-description & improved user documentation	+
-	* Convert commands to the Asynchronous commands API	+
-	* Review events implementation	+
-	* Spec review	+
-		+
-	~~=== HMP gap ===~~	+
-		+
-	~~This lists features that exist in HMP (Human Monitor Protocol), but doesn't in QMP ''' causing impact''' to libivrt~~.	+

-	* ~~loadvm~~/~~savevm~~ commands	+	* Finish conversion of old QMP commands to the QAPI
		+	** Missing commands: netdev_add/del, add_graphics_client, device_add, screen_dump
		+	** Commands that possibly depend on the new QMP server: closefd, getfd, qmp_capabilities
		+	* Improve QMP testing
		+	* Integrate the new QMP server (from Anthony's tree)
		+	* Add asynchronous command support
		+	* Convert (possibly all) HMP commands to the QAPI
		+	** Will make them "appear" on QMP
		+	** Will make it possible to make HMP a QMP front-end
		+	* Add the "event" QAPI type
		+	* Add schema instrospection
		+	* Improve QError errors

	== Testing ==		== Testing ==

Features/CPUModels

Ehabkost — Wed, 16 May 2012 16:30:08 GMT

← Older revision		Revision as of 16:30, 16 May 2012
Line 178:		Line 178:
	** Do we need a version that works after the VM is created, so it lists every single bit? (maybe just the "query-cpus" QMP command is already enough for that)		** Do we need a version that works after the VM is created, so it lists every single bit? (maybe just the "query-cpus" QMP command is already enough for that)
	* To be defined: Command to list CPU model aliases (per-machine-type)		* To be defined: Command to list CPU model aliases (per-machine-type)
-	* To be ~~define~~: command to query which CPU flags are really available and can be enabled (based on host hardware + kernel + qemu capabilities)	+	* To be defined: command to query which CPU flags are really available and can be enabled (based on host hardware + kernel + qemu capabilities)

	== <code>-cpu host</code> and feature probing ==		== <code>-cpu host</code> and feature probing ==

Download

AnthonyLiguori — Tue, 15 May 2012 16:02:14 GMT

Releases:

← Older revision		Revision as of 16:02, 15 May 2012
(2 intermediate revisions not shown)
Line 5:		Line 5:
	! Comment		! Comment
	\|-		\|-
-	\| [http://wiki.qemu.org/download/qemu-1.1-~~rc1~~.tar.gz qemu-1.1-~~rc1~~.tar.gz] ([http://wiki.qemu.org/download/qemu-1.1-~~rc1~~.tar.gz.sig signature])	+	\| [http://wiki.qemu.org/download/qemu-1.1.0-rc2.tar.bz2 qemu-1.1.0-rc2.tar.bz2] ([http://wiki.qemu.org/download/qemu-1.1.0-rc2.tar.bz2.sig signature])
	\| Source code ([[ChangeLog/Next\|ChangeLog]])		\| Source code ([[ChangeLog/Next\|ChangeLog]])
	\|-		\|-

Main Page

AnthonyLiguori — Tue, 15 May 2012 16:00:39 GMT

News:

← Older revision		Revision as of 16:00, 15 May 2012
Line 11:		Line 11:

	== News ==		== News ==
		+	'''May 15, 2012'''
		+	*QEMU version 1.1-rc2 is out. See the [[Download\|Download]] page for more information.
		+
	'''May 10, 2012'''		'''May 10, 2012'''
	*QEMU version 1.1-rc1 is out. See the [[Download\|Download]] page for more information.		*QEMU version 1.1-rc1 is out. See the [[Download\|Download]] page for more information.

ChangeLog/1.1

Mdroth — Tue, 15 May 2012 15:20:05 GMT

Guest agent:

← Older revision		Revision as of 15:20, 15 May 2012
(One intermediate revision not shown)
Line 59:		Line 59:

	* qemu-ga has been ported to Windows.		* qemu-ga has been ported to Windows.
		+	* Interfaces added for suspending guests to disk/ram, and retrieving information about network interfaces
		+	* Interfaces for filesystem freeze have been hardened, and no longer depend on guest agent runtime state to determine whether a system is currently frozen.
		+	* An easier to use reset mechanism has been added: guest-sync-delimited

	== Host support ==		== Host support ==

Features/CPUModels

Ehabkost — Tue, 15 May 2012 14:50:43 GMT

Current design proposal:

← Older revision		Revision as of 14:50, 15 May 2012
Line 178:		Line 178:
	** Do we need a version that works after the VM is created, so it lists every single bit? (maybe just the "query-cpus" QMP command is already enough for that)		** Do we need a version that works after the VM is created, so it lists every single bit? (maybe just the "query-cpus" QMP command is already enough for that)
	* To be defined: Command to list CPU model aliases (per-machine-type)		* To be defined: Command to list CPU model aliases (per-machine-type)
		+	* To be define: command to query which CPU flags are really available and can be enabled (based on host hardware + kernel + qemu capabilities)

	== <code>-cpu host</code> and feature probing ==		== <code>-cpu host</code> and feature probing ==

Contribute/SubmitAPatch

Stefan Weil — Mon, 14 May 2012 21:03:36 GMT

Add links to man pages for git-format-patch, git-send-email and git-bisect

← Older revision		Revision as of 21:03, 14 May 2012
Line 8:		Line 8:
	'''Send patches inline''' so they are easy to reply to with review comments. Do not put patches in attachments.		'''Send patches inline''' so they are easy to reply to with review comments. Do not put patches in attachments.

-	'''Use the right patch format'''. <code>git format-patch</code> will produce patch emails in the right format (check the documentation to find out how to drive it). You can then edit the cover letter before using <code>git send-email</code> to mail the files to the mailing list. (We recommend <code>git send-email</code> because mail clients often mangle patches by wrapping long lines or messing up whitespace.)	+	'''Use the right patch format'''. [http://git-scm.com/docs/git-format-patch <code>git format-patch</code>] will produce patch emails in the right format (check the documentation to find out how to drive it). You can then edit the cover letter before using <code>git send-email</code> to mail the files to the mailing list. (We recommend [http://git-scm.com/docs/git-send-email <code>git send-email</code>] because mail clients often mangle patches by wrapping long lines or messing up whitespace.)

	'''Patch emails must include a Signed-off-by: line'''. For more information see [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/SubmittingPatches;h=689e2371095cc5dfea9927120009341f369159aa;hb=f6f94e2ab1b33f0082ac22d71f66385a60d8157f#l297 SubmittingPatches 1.12]. This is vital or we will not be able to apply your patch! Please use your real name to sign a patch (not an alias name).		'''Patch emails must include a Signed-off-by: line'''. For more information see [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/SubmittingPatches;h=689e2371095cc5dfea9927120009341f369159aa;hb=f6f94e2ab1b33f0082ac22d71f66385a60d8157f#l297 SubmittingPatches 1.12]. This is vital or we will not be able to apply your patch! Please use your real name to sign a patch (not an alias name).
Line 20:		Line 20:
	'''Patches should be against current git master'''. There's no point submitting a patch which is based on a released version of QEMU because development will have moved on from then and it probably won't even apply to master. We only apply selected bugfixes to release branches and then only as backports once the code has gone into master.		'''Patches should be against current git master'''. There's no point submitting a patch which is based on a released version of QEMU because development will have moved on from then and it probably won't even apply to master. We only apply selected bugfixes to release branches and then only as backports once the code has gone into master.

-	'''Split up longer patches''' into a patch series of logical code changes. Each change should compile and execute successfully. For instance, don't add a file to the makefile in patch one and then add the file itself in patch two. (This rule is here so that people can later use tools like "git bisect" without hitting points in the commit history where QEMU doesn't work for reasons unrelated to the bug they're chasing.)	+	'''Split up longer patches''' into a patch series of logical code changes. Each change should compile and execute successfully. For instance, don't add a file to the makefile in patch one and then add the file itself in patch two. (This rule is here so that people can later use tools like [http://git-scm.com/docs/git-bisect <code>git bisect</code>] without hitting points in the commit history where QEMU doesn't work for reasons unrelated to the bug they're chasing.)

	'''Don't include irrelevant changes'''. In particular, don't include formatting, coding style or whitespace changes to bits of code that would otherwise not be touched by the patch. (It's OK to fix coding style issues in the immediate area (few lines) of the lines you're changing.) If you think a section of code really does need a reindent or other large-scale style fix, submit this as a separate patch which makes no semantic changes; don't put it in the same patch as your bug fix.		'''Don't include irrelevant changes'''. In particular, don't include formatting, coding style or whitespace changes to bits of code that would otherwise not be touched by the patch. (It's OK to fix coding style issues in the immediate area (few lines) of the lines you're changing.) If you think a section of code really does need a reindent or other large-scale style fix, submit this as a separate patch which makes no semantic changes; don't put it in the same patch as your bug fix.

Contribute/SubmitAPatch

Pm215 — Mon, 14 May 2012 20:48:50 GMT

← Older revision		Revision as of 20:48, 14 May 2012
(One intermediate revision not shown)
Line 7:		Line 7:

	'''Send patches inline''' so they are easy to reply to with review comments. Do not put patches in attachments.		'''Send patches inline''' so they are easy to reply to with review comments. Do not put patches in attachments.
		+
		+	'''Use the right patch format'''. <code>git format-patch</code> will produce patch emails in the right format (check the documentation to find out how to drive it). You can then edit the cover letter before using <code>git send-email</code> to mail the files to the mailing list. (We recommend <code>git send-email</code> because mail clients often mangle patches by wrapping long lines or messing up whitespace.)

	'''Patch emails must include a Signed-off-by: line'''. For more information see [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/SubmittingPatches;h=689e2371095cc5dfea9927120009341f369159aa;hb=f6f94e2ab1b33f0082ac22d71f66385a60d8157f#l297 SubmittingPatches 1.12]. This is vital or we will not be able to apply your patch! Please use your real name to sign a patch (not an alias name).		'''Patch emails must include a Signed-off-by: line'''. For more information see [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/SubmittingPatches;h=689e2371095cc5dfea9927120009341f369159aa;hb=f6f94e2ab1b33f0082ac22d71f66385a60d8157f#l297 SubmittingPatches 1.12]. This is vital or we will not be able to apply your patch! Please use your real name to sign a patch (not an alias name).
Line 30:		Line 32:
	If you fix issues that are raised during review '''resend the entire patch series''' not just the one patch that was changed. This allows maintainers to easily apply the fixed series without having to manually identify which patches are relevant.		If you fix issues that are raised during review '''resend the entire patch series''' not just the one patch that was changed. This allows maintainers to easily apply the fixed series without having to manually identify which patches are relevant.

-	'''When resending patches add a v2/v3 suffix''' (eg [PATCH v2]). This means people can easily identify whether they're looking at the most recent version. (The first version of a patch need not say "v1", just [PATCH] is sufficient.)	+	'''When resending patches add a v2/v3 suffix''' (eg [PATCH v2]). This means people can easily identify whether they're looking at the most recent version. (The first version of a patch need not say "v1", just [PATCH] is sufficient.) For patch series, the version applies to the whole series -- even if you only change one patch, you resend the entire series and mark it as "v2". Don't try to track versions of different patches in the series separately.

	For later versions of patches '''include a summary of changes from previous versions, but not in the commit message itself'''. In an email formatted as a git patch, the commit message is the part above the "---" line, and this will go into the git changelog when the patch is committed. This part should be a self-contained description of what this version of the patch does, written to make sense to anybody who comes back to look at this commit in git in six months' time. The part below the "---" line and above the patch proper (git format-patch puts the diffstat here) is a good place to put remarks for people reading the patch email, and this is where the "changes since previous version" summary belongs.		For later versions of patches '''include a summary of changes from previous versions, but not in the commit message itself'''. In an email formatted as a git patch, the commit message is the part above the "---" line, and this will go into the git changelog when the patch is committed. This part should be a self-contained description of what this version of the patch does, written to make sense to anybody who comes back to look at this commit in git in six months' time. The part below the "---" line and above the patch proper (git format-patch puts the diffstat here) is a good place to put remarks for people reading the patch email, and this is where the "changes since previous version" summary belongs.

ChangeLog/1.1

Pm215 — Mon, 14 May 2012 17:24:37 GMT

User-mode emulation:

← Older revision		Revision as of 17:24, 14 May 2012
(2 intermediate revisions not shown)
Line 10:		Line 10:
	* The syborg machine type has been removed since the Symbian Virtual Platform is no longer relevant with the disbanding of Symbian.		* The syborg machine type has been removed since the Symbian Virtual Platform is no longer relevant with the disbanding of Symbian.
	* A device tree can be passed to the kernel using -dtb option (or alternatively ''-machine dtb=...'').		* A device tree can be passed to the kernel using -dtb option (or alternatively ''-machine dtb=...'').
-	* ~~[new machine types]~~	+	* New 'nuri' and 'smbkc210' models of Samsung Exynos4210 based devboards
		+	* New 'highbank' model of the Calxeda Highbank
		+	* New 'vexpress-a15' model of the Versatile Express Cortex-A15

	=== PowerPC ===		=== PowerPC ===
Line 60:		Line 62:
	== Host support ==		== Host support ==

-	* ~~System emulation on~~ ARM hosts ~~was~~ broken in 1.0 ~~and works again~~	+	* ARM hosts are now supported again (they were broken in 1.0)
	* Sockets and SLIRP on Windows hosts was broken in 0.14 and works again		* Sockets and SLIRP on Windows hosts was broken in 0.14 and works again
	* 64-bit Windows hosts are now supported.		* 64-bit Windows hosts are now supported.
Line 67:		Line 69:

	* User-mode emulation can provide some information from the /proc filesystem.		* User-mode emulation can provide some information from the /proc filesystem.
		+	* On 64-bit hosts user-mode emulation now defaults to reserving 0xf7000000 bytes of address space for the guest. This significantly reduces the likelihood of QEMU having to fail a guest mmap() request when there is still memory available. This reservation can be overridden with the -R command line option.

	== Build dependencies ==		== Build dependencies ==

	* Building QEMU requires glib 2.12 on POSIX systems, and glib 2.20 on Win32 systems.		* Building QEMU requires glib 2.12 on POSIX systems, and glib 2.20 on Win32 systems.

ChangeLog/1.1

Paolo Bonzini — Mon, 14 May 2012 15:11:22 GMT

Live Migration, Save/Restore:

← Older revision		Revision as of 15:11, 14 May 2012
Line 52:		Line 52:

	* Live migration (or save/restore) from QEMU releases prior to 0.13 to QEMU 1.1 is not supported		* Live migration (or save/restore) from QEMU releases prior to 0.13 to QEMU 1.1 is not supported
		+	* Live migration supports IPv6. IPv6 addresses can be expressed as ''tcp:host:port''. Brackets around a numeric host address are required if a port is also specified, otherwise they can be omitted.

	== Guest agent ==		== Guest agent ==

Features/QOM/CPU

AF — Fri, 11 May 2012 21:02:17 GMT

Update status with new qom-1.1 branch

← Older revision		Revision as of 21:02, 11 May 2012
Line 134:		Line 134:
	\|-		\|-
	\|<del>[https://github.com/afaerber/qemu-cpu/commits/qom-cpu-x86 qom-cpu-x86], part 2 (props)</del>		\|<del>[https://github.com/afaerber/qemu-cpu/commits/qom-cpu-x86 qom-cpu-x86], part 2 (props)</del>
		+	\|
		+	\|-
		+	\|'''[http://repo.or.cz/w/qemu/afaerber.git/shortlog/refs/heads/qom-1.1 qom-1.1]'''
	\|		\|
	\|-		\|-

Features/HelperNetworking

Coreyb — Fri, 11 May 2012 14:55:23 GMT

← Older revision		Revision as of 14:55, 11 May 2012
Line 42:		Line 42:

	== Status ==		== Status ==
-	* Patches are in ~~review on the mailing list~~.	+	* Patches are upstream in QEMU 1.1.
-	* Latest version of patches: http://~~www~~.~~mail-archive~~.~~com~~/qemu-devel~~@nongnu.org~~/~~msg91785~~.html	+	* Latest version of patches: http://lists.gnu.org/archive/html/qemu-devel/2012-01/msg03562.html

Features/QOM/CPU

AF — Fri, 11 May 2012 11:14:47 GMT

Update status with new qom-next branch and indicate version all targets have been converted for

← Older revision		Revision as of 11:14, 11 May 2012
Line 64:		Line 64:
	== Status ==		== Status ==

-	QOM CPUState exists, former CPUState is renamed to CPUArchState. All targets have been converted.	+	QOM CPUState exists, former CPUState is renamed to CPUArchState. All targets have been converted for v1.1-rc0.

	Field movements from CPUArchState to CPUState (and subsequent removal of CPUArchState and CPU_COMMON) are being worked on.		Field movements from CPUArchState to CPUState (and subsequent removal of CPUArchState and CPU_COMMON) are being worked on.
Line 137:		Line 137:
	\|-		\|-
	\|[https://github.com/afaerber/qemu-cpu/commits/qom-cpu-1.1 qom-cpu-1.1] (cleanups)		\|[https://github.com/afaerber/qemu-cpu/commits/qom-cpu-1.1 qom-cpu-1.1] (cleanups)
		+	\|
		+	\|-
		+	\|'''[http://repo.or.cz/w/qemu/afaerber.git/shortlog/refs/heads/qom-next qom-next]'''
	\|		\|
	\|-		\|-

Download

AnthonyLiguori — Thu, 10 May 2012 12:49:21 GMT

Releases:

← Older revision		Revision as of 12:49, 10 May 2012
Line 4:		Line 4:
	! File		! File
	! Comment		! Comment
		+	\|-
		+	\| [http://wiki.qemu.org/download/qemu-1.1-rc1.tar.gz qemu-1.1-rc1.tar.gz] ([http://wiki.qemu.org/download/qemu-1.1-rc1.tar.gz.sig signature])
		+	\| Source code ([[ChangeLog/Next\|ChangeLog]])
	\|-		\|-
	\| [http://wiki.qemu.org/download/qemu-1.0.1.tar.gz qemu-1.0.1.tar.gz] ([http://wiki.qemu.org/download/qemu-1.0.1.tar.gz.sig signature])		\| [http://wiki.qemu.org/download/qemu-1.0.1.tar.gz qemu-1.0.1.tar.gz] ([http://wiki.qemu.org/download/qemu-1.0.1.tar.gz.sig signature])
	\| Source code ([[ChangeLog/1.0\|ChangeLog]])		\| Source code ([[ChangeLog/1.0\|ChangeLog]])
-	\|-
-	~~\| [http://wiki.qemu.org/download/qemu-0.15.1.tar.gz qemu-0.15.1.tar.gz] ([http://wiki.qemu.org/download/qemu-0.15.1.tar.gz.sig signature])~~
-	~~\| Source code ([[ChangeLog/0.15\|ChangeLog]])~~
	\|}		\|}

Main Page

AnthonyLiguori — Thu, 10 May 2012 12:48:06 GMT

News:

← Older revision		Revision as of 12:48, 10 May 2012
Line 11:		Line 11:

	== News ==		== News ==
		+	'''May 10, 2012'''
		+	*QEMU version 1.1-rc1 is out. See the [[Download\|Download]] page for more information.
		+
	'''Feb 17, 2012'''		'''Feb 17, 2012'''
	*QEMU version 1.0.1 is out. See the [[Download\|Download]] page for more information.		*QEMU version 1.0.1 is out. See the [[Download\|Download]] page for more information.