Re-implemented based on qmp_qom_set() to facilitate argument parsing.
Warn about ambiguous path arguments.
Reviewed-by: Gonglei <arei.gonglei@huawei.com>
Tested-by: Alistair Francis <alistair.francis@xilinx.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Implement it as a wrapper for QMP qom-list, but mimic the behavior of
scripts/qmp/qom-list in making the path argument optional and listing
the root if absent, to hint users what kind of path to pass.
Reviewed-by: Gonglei <arei.gonglei@huawei.com>
Tested-by: Alistair Francis <alistair.francis@xilinx.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Functionally it is a recursive qom-list with qom-get per non-child<>
property. Some failures needed to be handled, such as trying to read a
pointer property, which is not representable in QMP. Those print a
literal "<EXCEPTION>".
Tested-by: Alistair Francis <alistair.francis@xilinx.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Use DeviceClass::realize() and TypeInfo::instance_init() instead of
the deprecated SysBusDevice::init().
Signed-off-by: Alistair Francis <alistair.francis@xilinx.com>
Reviewed-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Re-add the glx compile test to configure. We can't use pkg-config to
probe for glx, and as long as milkymist-tmu2 privately uses glx (due to
opengl infrastructure in qemu not being ready yet) we must continue to
test for glx to avoid build failures.
Reported-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Max Reitz <mreitz@redhat.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCgAGBQJVBvzsAAoJEArSxjlracoU864QAMBAzk8SDV5Xxz5wF+iqfUUz
ZgDXDjsInQIgfmKo+Fe6xdCcWMD3FEpEqJ0zjn2znr89vO10r7c/BByLwf0Z9/V4
AoeCOntdtRXQfWxN+oVdxMxwbsQnGHXCzLyCzS/5tf4gweFcEM4yhRlOMoJeW879
xPt+F785+MxkgvP1nR+/twx4XwzpdnhxXmiWMiTweTkGORhveELM7S0aiF8YbC69
0GYy1ZPdJlZ8ozcLiorj1gE4ejZ0dhnpaOS1chAYRn6Zu5BwFNgGQeG9NLG5n9O9
S8oePDj7tCde8eiKU0oS4mCppByg3iZ0590YHlFOLGKqKfLJJiYX2HDJAfHO2oL8
qgsCxYjspgtkVVm3Kl3JQ2qOeJ+Ox4kzWLXXlYEt4TUdzB6423z0KRjtgUWUYMFU
Mvc59+0kyhVeUuye6R05UtAPF1bbFUxHPTf+/ComSCmmrbbC7K3gmkxXOyiNNeej
JktL71toAdEEEsE6XBtg8q1taDOySu/4oQMBzMNLpzSbOZw85o5eI5xv39VqbKWi
jp3L5zQlwTE+fYa7/mvs9dXGsl7vJ5i3YkGPe/7DMe8xeRiideOK5X6PRxSBTn+H
tA3sM6be3MRMeT9qmLJGrcy98U2gP/ZKBcNxI0LJs1FqnKCJcFZ7PEgaxcBW/9VV
/AWKoh7/pdslOgQY+ZA7
=HUhc
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/bkoppelmann/tags/pull-tricore-20150316' into staging
TriCore RRR1, RRRR, RRRW, and SYS instructions
# gpg: Signature made Mon Mar 16 15:55:24 2015 GMT using RSA key ID 6B69CA14
# gpg: Good signature from "Bastian Koppelmann <kbastian@mail.uni-paderborn.de>"
* remotes/bkoppelmann/tags/pull-tricore-20150316:
target-tricore: Add instructions of SYS opcode format
target-tricore: Add instructions of RRRW opcode format
target-tricore: Add instructions of RRRR opcode format
target-tricore: Add instructions of RRR1 opcode format, which have 0xe3 as first opcode
target-tricore: Add instructions of RRR1 opcode format, which have 0x63 as first opcode
target-tricore: Add instructions of RRR1 opcode format, which have 0xa3 as first opcode
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The code to check the bitmap for the allocation status of each sector
has been "disabled by reason" ever since the vpc driver existed.
The reason might be that we might end up reading sector by sector
in vpc_read if we really used it. This would be a performance desaster.
The current code would furthermore not work if the disabled parts get
reactivated since vpc_read and vpc_write only use get_sector_offset to
check the allocation status of the first sector of a read/write operation.
This might lead to sectors incorrectly treated as zero in vpc_read and
to sectors getting allocated twice in vpc_write.
Signed-off-by: Peter Lieven <pl@kamp.de>
Message-id: 1425379316-19639-6-git-send-email-pl@kamp.de
Reviewed-by: Max Reitz <mreitz@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
the field is named current size in the spec. Name it accordingly.
Signed-off-by: Peter Lieven <pl@kamp.de>
Reviewed-by: Max Reitz <mreitz@redhat.com>
Message-id: 1425379316-19639-5-git-send-email-pl@kamp.de
Signed-off-by: Max Reitz <mreitz@redhat.com>
The VHD spec [1] allows for total_sectors of 65535 x 16 x 255 (~127GB)
represented by a CHS geometry. If total_sectors is greater
than 65535 x 16 x 255 this geometry is set as a maximum.
Qemu, Hyper-V and disk2vhd use this special geometry as an indicator
to use the image current size from the footer as disk size.
This patch changes vpc_create to effectively calculate a CxHxS geometry
for the given image size if possible while rounding up if necessary.
If the image size is too big to be represented in CHS we set the maximum
and write the exact requested image size into the footer.
This partly reverts commit 258d2edb, but leaves support for >127G disks
intact.
[1] http://download.microsoft.com/download/f/f/e/ffef50a5-07dd-4cf8-aaa3-442c0673a029/Virtual%20Hard%20Disk%20Format%20Spec_10_18_06.doc
Signed-off-by: Peter Lieven <pl@kamp.de>
Message-id: 1425379316-19639-4-git-send-email-pl@kamp.de
Reviewed-by: Max Reitz <mreitz@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
The CHS calculation as done per the VHD spec imposes a maximum image
size of ~127 GB. Real VHD images exist that are larger than that.
Apparently there are two separate non-standard ways to achieve this:
You could use more heads than the spec does - this is the option that
qemu-img create chooses.
However, other images exist where the geometry is set to the maximum
(65535/16/255), but the actual image size is larger. Until now, such
images are truncated at 127 GB when opening them with qemu.
This patch changes the vpc driver to ignore geometry in this case and
only trust the size field in the header.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
[PL: Fixed maximum geometry in the commit msg]
Signed-off-by: Peter Lieven <pl@kamp.de>
Message-id: 1425379316-19639-3-git-send-email-pl@kamp.de
Reviewed-by: Max Reitz <mreitz@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
*pnum can't be greater than s->block_size / BDRV_SECTOR_SIZE for allocated
sectors since there is always a bitmap in between.
Signed-off-by: Peter Lieven <pl@kamp.de>
Reviewed-by: Max Reitz <mreitz@redhat.com>
Message-id: 1425379316-19639-2-git-send-email-pl@kamp.de
Signed-off-by: Max Reitz <mreitz@redhat.com>
All callers are converted, so drop it.
Signed-off-by: Fam Zheng <famz@redhat.com>
Message-id: 1425296209-1476-5-git-send-email-famz@redhat.com
Reviewed-by: Max Reitz <mreitz@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
It is easy to create only self-referential refblocks, but there are
cases where that is impossible. This adds a test for two of those cases
(combined in a single test case).
Suggested-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-id: 1417798412-15330-1-git-send-email-mreitz@redhat.com
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-id: 1423598552-24301-3-git-send-email-mreitz@redhat.com
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
When choosing a new place for the refcount table, alloc_refcount_block()
tries to infer the number of clusters used so far from its argument
cluster_index (which comes from the idea that if any cluster with an
index greater than cluster_index was in use, the refcount table would
have to be big enough already to describe cluster_index).
However, there is a cluster that may be at or after cluster_index, and
which is not covered by the refcount structures, and that is the new
refcount block new_block. Therefore, it should be taken into account for
the blocks_used calculation.
Also, because new_block already describes (or is intended to describe)
cluster_index, we may not put the new refcount structures there.
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-id: 1423598552-24301-2-git-send-email-mreitz@redhat.com
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
qerror_report_err() is a transitional interface to help with
converting existing monitor commands to QMP. It should not be used
elsewhere. Replace by error_report_err().
Commit 6936f29 cleaned that up in qemu-img.c, but two calls have crept
in since. Take care of them the same way.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Error classes are a leftover from the days of "rich" error objects.
New code should always use ERROR_CLASS_GENERIC_ERROR. Commit e246211
added a use of ERROR_CLASS_DEVICE_NOT_FOUND. Replace it.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
We've steered users away from QCOW/QCOW2 encryption for a while,
because it's a flawed design (commit 136cd19 Describe flaws in
qcow/qcow2 encryption in the docs).
In addition to flawed crypto, we have comically bad usability, and
plain old bugs. Let me show you.
= Example images =
I'm going to use a raw image as backing file, and two QCOW2 images,
one encrypted, and one not:
$ qemu-img create -f raw backing.img 4m
Formatting 'backing.img', fmt=raw size=4194304
$ qemu-img create -f qcow2 -o encryption,backing_file=backing.img,backing_fmt=raw geheim.qcow2 4m
Formatting 'geheim.qcow2', fmt=qcow2 size=4194304 backing_file='backing.img' backing_fmt='raw' encryption=on cluster_size=65536 lazy_refcounts=off
$ qemu-img create -f qcow2 -o backing_file=backing.img,backing_fmt=raw normal.qcow2 4m
Formatting 'normal.qcow2', fmt=qcow2 size=4194304 backing_file='backing.img' backing_fmt='raw' encryption=off cluster_size=65536 lazy_refcounts=off
= Usability issues =
== Confusing startup ==
When no image is encrypted, and you don't give -S, QEMU starts the
guest immediately:
$ qemu-system-x86_64 -nodefaults -display none -monitor stdio normal.qcow2
QEMU 2.2.50 monitor - type 'help' for more information
(qemu) info status
VM status: running
But as soon as there's an encrypted image in play, the guest is *not*
started, with no notification whatsoever:
$ qemu-system-x86_64 -nodefaults -display none -monitor stdio geheim.qcow2
QEMU 2.2.50 monitor - type 'help' for more information
(qemu) info status
VM status: paused (prelaunch)
If the user figured out that he needs to type "cont" to enter his
keys, the confusion enters the next level: "cont" asks for at most
*one* key. If more are needed, it then silently does nothing. The
user has to type "cont" once per encrypted image:
$ qemu-system-x86_64 -nodefaults -display none -monitor stdio -drive if=none,file=geheim.qcow2 -drive if=none,file=geheim.qcow2
QEMU 2.2.50 monitor - type 'help' for more information
(qemu) info status
VM status: paused (prelaunch)
(qemu) c
none0 (geheim.qcow2) is encrypted.
Password: ******
(qemu) info status
VM status: paused (prelaunch)
(qemu) c
none1 (geheim.qcow2) is encrypted.
Password: ******
(qemu) info status
VM status: running
== Incorrect passwords not caught ==
All existing encryption schemes give you the GIGO treatment: garbage
password in, garbage data out. Guests usually refuse to mount
garbage, but other usage is prone to data loss.
== Need to stop the guest to add an encrypted image ==
$ qemu-system-x86_64 -nodefaults -display none -monitor stdio
QEMU 2.2.50 monitor - type 'help' for more information
(qemu) info status
VM status: running
(qemu) drive_add "" if=none,file=geheim.qcow2
Guest must be stopped for opening of encrypted image
(qemu) stop
(qemu) drive_add "" if=none,file=geheim.qcow2
OK
Commit c3adb58 added this restriction. Before, we could expose images
lacking an encryption key to guests, with potentially catastrophic
results. See also "Use without key is not always caught".
= Bugs =
== Use without key is not always caught ==
Encrypted images can be in an intermediate state "opened, but no key".
The weird startup behavior and the need to stop the guest are there to
ensure the guest isn't exposed to that state. But other things still
are!
* drive_backup
$ qemu-system-x86_64 -nodefaults -display none -monitor stdio geheim.qcow2
QEMU 2.2.50 monitor - type 'help' for more information
(qemu) drive_backup -f ide0-hd0 out.img raw
Formatting 'out.img', fmt=raw size=4194304
I guess this writes encrypted data to raw image out.img. Good luck
with figuring out how to decrypt that again.
* commit
$ qemu-system-x86_64 -nodefaults -display none -monitor stdio geheim.qcow2
QEMU 2.2.50 monitor - type 'help' for more information
(qemu) commit ide0-hd0
I guess this writes encrypted data into the unencrypted raw backing
image, effectively destroying it.
== QMP device_add of usb-storage fails when it shouldn't ==
When the image is encrypted, device_add creates the device, defers
actually attaching it to when the key becomes available, then fails.
This is wrong. device_add must either create the device and succeed,
or do nothing and fail.
$ qemu-system-x86_64 -nodefaults -display none -usb -qmp stdio -drive if=none,id=foo,file=geheim.qcow2
{"QMP": {"version": {"qemu": {"micro": 50, "minor": 2, "major": 2}, "package": ""}, "capabilities": []}}
{ "execute": "qmp_capabilities" }
{"return": {}}
{ "execute": "device_add", "arguments": { "driver": "usb-storage", "id": "bar", "drive": "foo" } }
{"error": {"class": "DeviceEncrypted", "desc": "'foo' (geheim.qcow2) is encrypted"}}
{"execute":"device_del","arguments": { "id": "bar" } }
{"timestamp": {"seconds": 1426003440, "microseconds": 237181}, "event": "DEVICE_DELETED", "data": {"path": "/machine/peripheral/bar/bar.0/legacy[0]"}}
{"timestamp": {"seconds": 1426003440, "microseconds": 238231}, "event": "DEVICE_DELETED", "data": {"device": "bar", "path": "/machine/peripheral/bar"}}
{"return": {}}
This stuff is worse than useless, it's a trap for users.
If people become sufficiently interested in encrypted images to
contribute a cryptographically sane implementation for QCOW2 (or
whatever other format), then rewriting the necessary support around it
from scratch will likely be easier and yield better results than
fixing up the existing mess.
Let's deprecate the mess now, drop it after a grace period, and move
on.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Commit c4bacaf improved error reporting, but neglected to update
051.out. Commit 2726958 tried to redress, but didn't get it quite
right (punctuation difference), and shortly after commit
ae071cc..master improved error reporting some more, neglecting 051.out
some more. Sorry!
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
As seen with ubuntu-5.10-live-powerpc.iso.
Reported-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Tested-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
Signed-off-by: Richard Henderson <rth@twiddle.net>
Add helpers helper_subadr_h/_ssov which subs one halfword and adds one
halfword, rounds / and saturates each half word independently.
Add microcode helper functions:
* gen_msubad_h/ads_h: multiply two halfwords left justified and sub from the
first one word and add the second one word
/ and saturate each resulting word independetly.
* gen_msubadm_h/adms_h: multiply two halfwords in q-format left justified
and sub from the first one word and add to
the second one word / and saturate each resulting
word independetly.
* gen_msubadr32_h/32s_h: multiply two halfwords in q-format left justified
and sub from the first one word and add to
the second one word, round both results / and
saturate each resulting word independetly.
Reviewed-by: Richard Henderson <rth@twiddle.net>
Signed-off-by: Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
Add helpers:
* msub64_q_ssov: multiply two 32 bit q-format number, sub the result from a
64 bit q-format number and saturate.
* msub32_q_sub_ssov: sub two 64 bit q-format numbers and return a 32 bit
result.
* msubr_q_ssov: multiply two 32 bit q-format numbers, sub the result from a 32 bit
q-format number and saturate.
* msubr_q: multiply two 32 bit q-format numbers and sub the result from a 32 bit
q-format number.
Reviewed-by: Richard Henderson <rth@twiddle.net>
Signed-off-by: Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
Add helpers:
* sub64_ssov: subs two 64 bit values and saturates the result.
* subr_h/_ssov: subs two halfwords from two words in q-format with rounding
/ and saturates each result independetly.
Add microcode generator:
* gen_sub64_d: adds two 64 bit values.
* gen_msub_h/s_h: multiply four halfwords, sub each result left justfied
from two word values / and saturate each result.
* gen_msubm_h/s_h: multiply four halfwords, sub each result left justfied
from two words values in q-format / and saturate each
result.
* gen_msubr32/64_h/s_h: multiply four halfwords, sub each result left
justfied from two halftwords/words values in q-format
/ and saturate each result.
Reviewed-by: Richard Henderson <rth@twiddle.net>
Signed-off-by: Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABCAAGBQJVBtxlAAoJEPSH7xhYctcjokAQALpZdRqCAS89MSFfFMj0uSE+
YL2jELoMHYoOutq7quc/dF5wpQpYeSWYAzcHBpdo63j9VlnoKfQ0CaOGdevnwhZT
KUg9S+9UtvcqJUteZyd/JtY6HA83jXElJB6siTUMHJmdgYY4i5HSfUeYe/jqsfdT
W2TYJQPMu1ecGFAjKJQafZRO0q5gYfR2XeEiAsdynIVvccPFKMKnE5CtoPnJtTPb
83O36K3wi4lg0AgB7ti8QcNSf3JS2WuluKXG1TxrgoxfWAVQ0SQ79pq7xVZ7c4IZ
BErm7ihhlOP/DlGaNsPzcYwVsP6uksm1TE/PO63QoWBxaVjmLPkV0ZLKbGkR8Cr0
ulk/BUSAjXzMDoloVqz27e2SCrCA0p7tpGJ9nw/2xv01GNcVO6EFAJDHFLv8HmnH
yVZDQnqO5wJkrUu5U5WQ1tKIktRZFRoyR0D6nzhAKSOWqFCOKMID6TH8ixmGSxA7
HHzSxs48GHu9pztZ1tNqON1r1Ets5I+Zy760wC60DPeOrSlkcEvgRzfNF26V9cY/
VSp8QedX5RE509HYvh73fVT5+brwPHMs36OSe/LSc4tomXZq83RjfDRjwYrAAAjW
nBugr0hyBrATLiPQSYgt+GNly4Qg09jwkTvRcQqcNf22zKdFM4zjf+wvrbH/+9xa
ZTuPQUSpHMNS3mv/Gj3b
=DZVy
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/juanquintela/tags/migration/20150316' into staging
migration/next for 20150316
# gpg: Signature made Mon Mar 16 13:36:37 2015 GMT using RSA key ID 5872D723
# gpg: Can't check signature: public key not found
* remotes/juanquintela/tags/migration/20150316:
pc: Disable vmdesc submission for old machines
migration: Allow to suppress vmdesc submission
migration: Read JSON VM description on incoming migration
rename save_block_hdr to save_page_header
save_block_hdr: we can recalculate the cont parameter here
save_xbzrle_page: change calling convention
ram_save_page: change calling covention
ram_find_and_save_block: change calling convention
ram: make all save_page functions take a uint64_t parameter
Add migrate_incoming
Add -incoming defer
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* fix handling of execute-never bits in page table walks
* tell kernel to initialize KVM GIC in realize function
* fix handling of STM (user) with r15 in register list
* ignore low bit of PC in M-profile exception return
* fix linux-user get/set_tls syscalls on CPUs with TZ
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABCAAGBQJVBs7oAAoJEDwlJe0UNgzeyFMP/Re3884RXnk5Mc9+57mwJOCh
NjVOiNskvFWwSxmOBWK0Zestr1MWp9zsnr27dj6wu9EqIlSTLbknl8ttnHnHdSrj
C21mD3H/1DXmQyIysHa3g61BQAuOU9UGgG8PSgK6z8IFM7x0+ntcyEzR8BL2qjHU
9YyvENrmbbVaY8/YfvAdqs0d4mp6RVwzPrb/t35CkX0nI2rgGX+wNTsqH/UCIpNb
eD1YeSaUJnaxODhZlZUcTR/D7wAzUmPtp7Le5qwMSH4jm6LTPSAQ2B5WFAfLodGO
Tpb8sXUAAJymnLOjPchYACEH/tS+yLTN40aTYXgq/sc7b6uCwRvEfZzVjJ3cn6Cf
ZEtP2ZwevzS2Uy17tfYs6fxgAdh07dB/lUif5lCg5tvlYa531HhH1uq0QplSxhDR
/uXvl8Q/tAVXLnWDh0uydZ7NuqEv7P+25feL7sAT5I/VUWgYCs3RhwE1lU1JMwih
yMKipD93bg+z7PqtOW/GHjIKyai7yTKhaVNS+BGZaqOIfqWSTFJ0NPFK0SK67kou
+38OMHtORaAnKGFbkBnJQGVjHTgzWPol9r1KuVgsa5zZvhDtNGNhk0A0xLil/Qkh
jwj1O5y+xtYI+JXIDucbcEySwL/RpzEOSKbd7OTsmTVNqhKqoomKUy5e0w/zG1v6
RFuUdUzabLTzT3uqwL+I
=uK1h
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20150316' into staging
target-arm queue:
* fix handling of execute-never bits in page table walks
* tell kernel to initialize KVM GIC in realize function
* fix handling of STM (user) with r15 in register list
* ignore low bit of PC in M-profile exception return
* fix linux-user get/set_tls syscalls on CPUs with TZ
# gpg: Signature made Mon Mar 16 12:39:04 2015 GMT using RSA key ID 14360CDE
# gpg: Good signature from "Peter Maydell <peter.maydell@linaro.org>"
* remotes/pmaydell/tags/pull-target-arm-20150316:
linux-user: Access correct register for get/set_tls syscalls on ARM TZ CPUs
target-arm: Ignore low bit of PC in M-profile exception return
target-arm: Fix handling of STM (user) with r15 in register list
hw/intc/arm_gic: Initialize the vgic in the realize function
target-arm: get_phys_addr_lpae: more xn control
target-arm: fix get_phys_addr_v6/SCTLR_AFE access check
target-arm: convert check_ap to ap_to_rw_prot
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Older PC machine types might by accident be backwards live migration compatible,
but with the new vmdesc self-describing blob in our live migration stream we
would break that compatibility.
Also users wouldn't expect massive behaviorial differences when updating to a
new version of QEMU while retaining their old machine type, especially not
potential breakage in tooling around live migration.
So disable vmdesc submission for old PC machine types.
Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
We now always send a JSON blob describing the migration file format as part
of the migration stream. However, some tools built around QEMU have proven
to stumble over this.
This patch gives the user the chance to disable said self-describing part of
the migration stream. To disable vmdesc submission, just add
-machine suppress-vmdesc=on
to your QEMU command line.
Signed-off-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Juan Quintela <quintela@redhat.com>
One of the really nice things about the VM description format is that it goes
over the wire when live migration is happening. Unfortunately QEMU today closes
any socket once it sees VM_EOF coming, so we never give the VMDESC the chance to
actually land on the wire.
This patch makes QEMU read the description as well. This way we ensure that
anything wire tapping us in between will get the chance to also interpret the
stream.
Along the way we also fix virt tests that assume that number_bytes_sent on the
sender side is equal to number_bytes_read which was true before the VMDESC
patches and is true again with this patch.
Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Tested-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
It has always been a page header, not a block header. Once there, the
flag argument was only passed to make a bit or with it, just do the or
on the caller.
Signed-off-by: Juan Quintela <quintela@redhat.com>
Add a parameter to pass the number of bytes written, and make it return
the number of pages written instead.
Signed-off-by: Juan Quintela <quintela@redhat.com>
Add a parameter to pass the number of bytes written, and make it return
the number of pages written instead.
Signed-off-by: Juan Quintela <quintela@redhat.com>
Add a parameter to pass the number of bytes written, and make it return
the number of pages written instead.
Signed-off-by: Juan Quintela <quintela@redhat.com>
It used to be an int, but then we can't pass directly the
bytes_transferred parameter, that would happen later in the series.
Signed-off-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: Amit Shah <amit.shah@redhat.com>
Add migrate_incoming/migrate-incoming to start an incoming
migration.
Once a qemu has been started with
-incoming defer
the migration can be started by issuing:
migrate_incoming uri
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
-incoming defer causes qemu to wait for an incoming migration
to be specified later. The monitor can be used to set migration
capabilities that may affect the incoming connection process.
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
* remotes/kvaneesh/for-upstream:
virtio: Fix memory leaks reported by Coverity
virtfs-proxy: Fix possible overflow
fsdev/virtfs-proxy-helper: Fix improper use of negative value
hw/9pfs/virtio-9p-posix-acl: Fix out-of-bounds access
9pfs-proxy: tiny cleanups in proxy_pwritev and proxy_preadv
9pfs-local: simplify/optimize local_mapped_attr_path()
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Andreas Färber