izzy/xemu
0
0
Fork 0
mirror of https://github.com/izzy2lost/xemu.git synced 2026-07-06 00:20:22 -07:00
Code Issues Packages Projects Releases Wiki Activity

Merge tag 'pull-target-arm-20240812' of https://git.linaro.org/people/pmaydell/qemu-arm into staging

Browse Source 
* Fix BTI versus CF_PCREL
 * include: Fix typo in name of MAKE_IDENTFIER macro
 * docs: Various txt-to-rST conversions
 * hw/core/ptimer: fix timer zero period condition for freq > 1GHz
 * arm/virt: place power button pin number on a define

# -----BEGIN PGP SIGNATURE-----
#
# iQJNBAABCAA3FiEE4aXFk81BneKOgxXPPCUl7RQ2DN4FAma5+4wZHHBldGVyLm1h
# eWRlbGxAbGluYXJvLm9yZwAKCRA8JSXtFDYM3pX3D/9UVutdg5TsB9N8y5mPaVSn
# Yx0awBgxK5SHWeVgQJBkSdqh6LiGhhukR3VHfNanDELq24s0uLqLW86thgj+iB0H
# 51rnVHJtWtT9mIt0Qq9BlXX8+j0th6hELy/z+/aYdrWI1pmKsGYgF1gRh1vXrg+I
# 0s/S7kZY5CNDBbTXoBNtJfbZRe8fzyy5gUqc/tnw6Qonp8XM1OeG6sg/qF0KwzbB
# 8R7IvnY7gaBWm3daXqrFoxYuR+9i6F8uaFflOm+CarKQc9foH6KEzmfLAYLfGkFZ
# 2ZVHg3uC4k4OicyrpYcWsgumNTzOj8RTI4kV7M8NAj5TXCr+0pO6lnhlAKVGTWiL
# nJrW62dN56w8NVOzcy0tB0xqTHnKIxioGZyU4RDVKHjD/Fy0x7LX7KVmaBEZgyxJ
# oA4zY4KOrCNFsXQlqZgx38v/1hshnIYFN7V5AmfGEfbbKpBznKBQKmuyJ9VwSfGT
# jLwlwU4VMJPsj2Rs70seEl6obgyZicAXIAbqPgtMsvt3H2kKI2jtsNPFka3WaY62
# 0jOEbbFrsKV1//ZExBZdFhqBH/CoiZMvM4jsq1Y/oxAxIWtGv5dmJJsAA3w33YE4
# kNWXfHKAAhydZKeQloMgeOdLliP5UiCfF1FltwAWkLo59GV3TkjwagDU8+pWs9OF
# plOKWaKDUzkHq6G197uaBA==
# =ftoZ
# -----END PGP SIGNATURE-----
# gpg: Signature made Mon 12 Aug 2024 10:09:48 PM AEST
# gpg:                using RSA key E1A5C593CD419DE28E8315CF3C2525ED14360CDE
# gpg:                issuer "peter.maydell@linaro.org"
# gpg: Good signature from "Peter Maydell <peter.maydell@linaro.org>" [full]
# gpg:                 aka "Peter Maydell <pmaydell@gmail.com>" [full]
# gpg:                 aka "Peter Maydell <pmaydell@chiark.greenend.org.uk>" [full]
# gpg:                 aka "Peter Maydell <peter@archaic.org.uk>" [unknown]

* tag 'pull-target-arm-20240812' of https://git.linaro.org/people/pmaydell/qemu-arm:
  arm/virt: place power button pin number on a define
  hw/core/ptimer: fix timer zero period condition for freq > 1GHz
  docs: Typo fix in live disk backup
  docs/interop/prl-xml.rst: Fix minor grammar nits
  docs/interop/prl-xml.txt: Convert to rST
  docs/interop/parallels.txt: Convert to rST
  docs/interop/nbd.txt: Convert to rST
  docs/specs/rocker.txt: Convert to rST
  include: Fix typo in name of MAKE_IDENTFIER macro
  target/arm: Fix BTI versus CF_PCREL

Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
This commit is contained in:
Richard Henderson
2024-08-13 07:59:11 +10:00
parent 87b9ae38d0 ed5031ad5d
commit 6029bc0cf7
23 changed files with 547 additions and 441 deletions
Download Patch File Download Diff File Expand all files Collapse all files
MAINTAINERS
+4 -3
View File
@@ -2465,7 +2465,7 @@ S: Maintained
F: hw/net/rocker/
F: qapi/rocker.json
F: tests/rocker/
F: docs/specs/rocker.txt
F: docs/specs/rocker.rst
e1000x
M: Dmitry Fleytman <dmitry.fleytman@gmail.com>
@@ -3871,7 +3871,7 @@ F: nbd/
F: include/block/nbd*
F: qemu-nbd.*
F: blockdev-nbd.c
F: docs/interop/nbd.txt
F: docs/interop/nbd.rst
F: docs/tools/qemu-nbd.rst
F: tests/qemu-iotests/tests/*nbd*
T: git https://repo.or.cz/qemu/ericb.git nbd
@@ -3964,7 +3964,8 @@ L: qemu-block@nongnu.org
S: Supported
F: block/parallels.c
F: block/parallels-ext.c
F: docs/interop/parallels.txt
F: docs/interop/parallels.rst
F: docs/interop/prl-xml.rst
T: git https://src.openvz.org/scm/~den/qemu.git parallels
qed
docs/interop/index.rst
+3
View File
@@ -14,6 +14,9 @@ are useful for making QEMU interoperate with other software.
dbus-vmstate
dbus-display
live-block-operations
nbd
parallels
prl-xml
pr-helper
qmp-spec
qemu-ga
docs/interop/live-block-operations.rst
+2 -2
View File
@@ -931,8 +931,8 @@ Shutdown the guest, by issuing the ``quit`` QMP command::
}
Live disk backup --- ``blockdev-backup`` and the deprecated``drive-backup``
---------------------------------------------------------------------------
Live disk backup --- ``blockdev-backup`` and the deprecated ``drive-backup``
----------------------------------------------------------------------------
The ``blockdev-backup`` (and the deprecated ``drive-backup``) allows
you to create a point-in-time snapshot.
docs/interop/nbd.rst
+89
View File
@@ -0,0 +1,89 @@
QEMU NBD protocol support
=========================
QEMU supports the NBD protocol, and has an internal NBD client (see
``block/nbd.c``), an internal NBD server (see ``blockdev-nbd.c``), and an
external NBD server tool (see ``qemu-nbd.c``). The common code is placed
in ``nbd/*``.
The NBD protocol is specified here:
https://github.com/NetworkBlockDevice/nbd/blob/master/doc/proto.md
The following paragraphs describe some specific properties of NBD
protocol realization in QEMU.
Metadata namespaces
-------------------
QEMU supports the ``base:allocation`` metadata context as defined in the
NBD protocol specification, and also defines an additional metadata
namespace ``qemu``.
``qemu`` namespace
------------------
The ``qemu`` namespace currently contains two available metadata context
types. The first is related to exposing the contents of a dirty
bitmap alongside the associated disk contents. That metadata context
is named with the following form::
qemu:dirty-bitmap:<dirty-bitmap-export-name>
Each dirty-bitmap metadata context defines only one flag for extents
in reply for ``NBD_CMD_BLOCK_STATUS``:
bit 0:
``NBD_STATE_DIRTY``, set when the extent is "dirty"
The second is related to exposing the source of various extents within
the image, with a single metadata context named::
qemu:allocation-depth
In the allocation depth context, the entire 32-bit value represents a
depth of which layer in a thin-provisioned backing chain provided the
data (0 for unallocated, 1 for the active layer, 2 for the first
backing layer, and so forth).
For ``NBD_OPT_LIST_META_CONTEXT`` the following queries are supported
in addition to the specific ``qemu:allocation-depth`` and
``qemu:dirty-bitmap:<dirty-bitmap-export-name>``:
``qemu:``
returns list of all available metadata contexts in the namespace
``qemu:dirty-bitmap:``
returns list of all available dirty-bitmap metadata contexts
Features by version
-------------------
The following list documents which qemu version first implemented
various features (both as a server exposing the feature, and as a
client taking advantage of the feature when present), to make it
easier to plan for cross-version interoperability. Note that in
several cases, the initial release containing a feature may require
additional patches from the corresponding stable branch to fix bugs in
the operation of that feature.
2.6
``NBD_OPT_STARTTLS`` with TLS X.509 Certificates
2.8
``NBD_CMD_WRITE_ZEROES``
2.10
``NBD_OPT_GO``, ``NBD_INFO_BLOCK``
2.11
``NBD_OPT_STRUCTURED_REPLY``
2.12
``NBD_CMD_BLOCK_STATUS`` for ``base:allocation``
3.0
``NBD_OPT_STARTTLS`` with TLS Pre-Shared Keys (PSK),
``NBD_CMD_BLOCK_STATUS`` for ``qemu:dirty-bitmap:``, ``NBD_CMD_CACHE``
4.2
``NBD_FLAG_CAN_MULTI_CONN`` for shareable read-only exports,
``NBD_CMD_FLAG_FAST_ZERO``
5.2
``NBD_CMD_BLOCK_STATUS`` for ``qemu:allocation-depth``
7.1
``NBD_FLAG_CAN_MULTI_CONN`` for shareable writable exports
8.2
``NBD_OPT_EXTENDED_HEADERS``, ``NBD_FLAG_BLOCK_STATUS_PAYLOAD``
docs/interop/nbd.txt
-72
View File
@@ -1,72 +0,0 @@
QEMU supports the NBD protocol, and has an internal NBD client (see
block/nbd.c), an internal NBD server (see blockdev-nbd.c), and an
external NBD server tool (see qemu-nbd.c). The common code is placed
in nbd/*.
The NBD protocol is specified here:
https://github.com/NetworkBlockDevice/nbd/blob/master/doc/proto.md
The following paragraphs describe some specific properties of NBD
protocol realization in QEMU.
= Metadata namespaces =
QEMU supports the "base:allocation" metadata context as defined in the
NBD protocol specification, and also defines an additional metadata
namespace "qemu".
== "qemu" namespace ==
The "qemu" namespace currently contains two available metadata context
types. The first is related to exposing the contents of a dirty
bitmap alongside the associated disk contents. That metadata context
is named with the following form:
qemu:dirty-bitmap:<dirty-bitmap-export-name>
Each dirty-bitmap metadata context defines only one flag for extents
in reply for NBD_CMD_BLOCK_STATUS:
bit 0: NBD_STATE_DIRTY, set when the extent is "dirty"
The second is related to exposing the source of various extents within
the image, with a single metadata context named:
qemu:allocation-depth
In the allocation depth context, the entire 32-bit value represents a
depth of which layer in a thin-provisioned backing chain provided the
data (0 for unallocated, 1 for the active layer, 2 for the first
backing layer, and so forth).
For NBD_OPT_LIST_META_CONTEXT the following queries are supported
in addition to the specific "qemu:allocation-depth" and
"qemu:dirty-bitmap:<dirty-bitmap-export-name>":
* "qemu:" - returns list of all available metadata contexts in the
namespace.
* "qemu:dirty-bitmap:" - returns list of all available dirty-bitmap
metadata contexts.
= Features by version =
The following list documents which qemu version first implemented
various features (both as a server exposing the feature, and as a
client taking advantage of the feature when present), to make it
easier to plan for cross-version interoperability. Note that in
several cases, the initial release containing a feature may require
additional patches from the corresponding stable branch to fix bugs in
the operation of that feature.
* 2.6: NBD_OPT_STARTTLS with TLS X.509 Certificates
* 2.8: NBD_CMD_WRITE_ZEROES
* 2.10: NBD_OPT_GO, NBD_INFO_BLOCK
* 2.11: NBD_OPT_STRUCTURED_REPLY
* 2.12: NBD_CMD_BLOCK_STATUS for "base:allocation"
* 3.0: NBD_OPT_STARTTLS with TLS Pre-Shared Keys (PSK),
NBD_CMD_BLOCK_STATUS for "qemu:dirty-bitmap:", NBD_CMD_CACHE
* 4.2: NBD_FLAG_CAN_MULTI_CONN for shareable read-only exports,
NBD_CMD_FLAG_FAST_ZERO
* 5.2: NBD_CMD_BLOCK_STATUS for "qemu:allocation-depth"
* 7.1: NBD_FLAG_CAN_MULTI_CONN for shareable writable exports
* 8.2: NBD_OPT_EXTENDED_HEADERS, NBD_FLAG_BLOCK_STATUS_PAYLOAD
docs/interop/parallels.txt → docs/interop/parallels.rst
+58 -50
View File
@@ -1,41 +1,46 @@
= License =
Parallels Expandable Image File Format
======================================
Copyright (c) 2015 Denis Lunev
Copyright (c) 2015 Vladimir Sementsov-Ogievskiy
..
Copyright (c) 2015 Denis Lunev
Copyright (c) 2015 Vladimir Sementsov-Ogievskiy
This work is licensed under the terms of the GNU GPL, version 2 or later.
See the COPYING file in the top-level directory.
This work is licensed under the terms of the GNU GPL, version 2 or later.
See the COPYING file in the top-level directory.
= Parallels Expandable Image File Format =
A Parallels expandable image file consists of three consecutive parts:
* header
* BAT
* data area
* header
* BAT
* data area
All numbers in a Parallels expandable image are stored in little-endian byte
order.
== Definitions ==
Definitions
-----------
Sector A 512-byte data chunk.
Sector
A 512-byte data chunk.
Cluster A data chunk of the size specified in the image header.
Currently, the default size is 1MiB (2048 sectors). In previous
versions, cluster sizes of 63 sectors, 256 and 252 kilobytes were
used.
Cluster
A data chunk of the size specified in the image header.
Currently, the default size is 1MiB (2048 sectors). In previous
versions, cluster sizes of 63 sectors, 256 and 252 kilobytes were used.
BAT Block Allocation Table, an entity that contains information for
guest-to-host I/O data address translation.
BAT
Block Allocation Table, an entity that contains information for
guest-to-host I/O data address translation.
== Header ==
Header
------
The header is placed at the start of an image and contains the following
fields:
fields::
Bytes:
Bytes:
0 - 15: magic
Must contain "WithoutFreeSpace" or "WithouFreSpacExt".
@@ -103,44 +108,46 @@ Bytes:
ext_off must meet the same requirements as cluster offsets
defined by BAT entries (see below).
== BAT ==
BAT
---
BAT is placed immediately after the image header. In the file, BAT is a
contiguous array of 32-bit unsigned little-endian integers with
(bat_entries * 4) bytes size.
``(bat_entries * 4)`` bytes size.
Each BAT entry contains an offset from the start of the file to the
corresponding cluster. The offset set in clusters for "WithouFreSpacExt" images
and in sectors for "WithoutFreeSpace" images.
corresponding cluster. The offset set in clusters for ``WithouFreSpacExt``
images and in sectors for ``WithoutFreeSpace`` images.
If a BAT entry is zero, the corresponding cluster is not allocated and should
be considered as filled with zeroes.
Cluster offsets specified by BAT entries must meet the following requirements:
- the value must not be lower than data offset (provided by header.data_off
or calculated as specified above),
- the value must be lower than the desired file size,
- the value must be unique among all BAT entries,
- the result of (cluster offset - data offset) must be aligned to cluster
size.
- the value must not be lower than data offset (provided by ``header.data_off``
or calculated as specified above)
- the value must be lower than the desired file size
- the value must be unique among all BAT entries
- the result of ``(cluster offset - data offset)`` must be aligned to
cluster size
== Data Area ==
Data Area
---------
The data area is an area from the data offset (provided by header.data_off or
calculated as specified above) to the end of the file. It represents a
The data area is an area from the data offset (provided by ``header.data_off``
or calculated as specified above) to the end of the file. It represents a
contiguous array of clusters. Most of them are allocated by the BAT, some may
be allocated by the ext_off field in the header while other may be allocated by
extensions. All clusters allocated by ext_off and extensions should meet the
same requirements as clusters specified by BAT entries.
be allocated by the ``ext_off`` field in the header while other may be
allocated by extensions. All clusters allocated by ``ext_off`` and extensions
should meet the same requirements as clusters specified by BAT entries.
== Format Extension ==
Format Extension
----------------
The Format Extension is an area 1 cluster in size that provides additional
format features. This cluster is addressed by the ext_off field in the header.
The format of the Format Extension area is the following:
The format of the Format Extension area is the following::
0 - 7: magic
Must be 0xAB234CEF23DCEA87
@@ -149,10 +156,10 @@ The format of the Format Extension area is the following:
The MD5 checksum of the entire Header Extension cluster except
the first 24 bytes.
The above are followed by feature sections or "extensions". The last
extension must be "End of features" (see below).
The above are followed by feature sections or "extensions". The last
extension must be "End of features" (see below).
Each feature section has the following format:
Each feature section has the following format::
0 - 7: magic
The identifier of the feature:
@@ -183,16 +190,17 @@ Each feature section has the following format:
variable: data (data_size bytes)
The above is followed by padding to the next 8 bytes boundary, then the
next extension starts.
The above is followed by padding to the next 8 bytes boundary, then the
next extension starts.
The last extension must be "End of features" with all the fields set to 0.
The last extension must be "End of features" with all the fields set to 0.
=== Dirty bitmaps feature ===
Dirty bitmaps feature
---------------------
This feature provides a way of storing dirty bitmaps in the image. The fields
of its data area are:
of its data area are::
0 - 7: size
The bitmap size, should be equal to disk size in sectors.
@@ -215,7 +223,7 @@ clusters inside the Parallels image file. The offsets of these clusters are
saved in the L1 offset table specified by the feature extension. Each L1 table
entry is a 64 bit integer as described below:
Given an offset in bytes into the bitmap data, corresponding L1 entry is
Given an offset in bytes into the bitmap data, corresponding L1 entry is::
l1_table[offset / cluster_size]
@@ -227,6 +235,6 @@ are assumed to be 1.
If an L1 table entry is not 0 or 1, it contains the corresponding cluster
offset (in 512b sectors). Given an offset in bytes into the bitmap data the
offset in bytes into the image file can be obtained as follows:
offset in bytes into the image file can be obtained as follows::
offset = l1_table[offset / cluster_size] * 512 + (offset % cluster_size)
docs/interop/prl-xml.rst
+192
View File
@@ -0,0 +1,192 @@
Parallels Disk Format
=====================
..
Copyright (c) 2015-2017, Virtuozzo, Inc.
Authors:
2015 Denis Lunev <den@openvz.org>
2015 Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
2016-2017 Klim Kireev <klim.kireev@virtuozzo.com>
2016-2017 Edgar Kaziakhmedov <edgar.kaziakhmedov@virtuozzo.com>
This work is licensed under the terms of the GNU GPL, version 2 or later.
See the COPYING file in the top-level directory.
This specification contains minimal information about Parallels Disk Format,
which is enough to properly work with QEMU. Nevertheless, Parallels Cloud Server
and Parallels Desktop are able to add some unspecified nodes to the xml and use
them, but they are for internal work and don't affect functionality. Also it
uses auxiliary xml ``Snapshot.xml``, which allows storage of optional snapshot
information, but this doesn't influence open/read/write functionality. QEMU and
other software should not use fields not covered in this document or the
``Snapshot.xml`` file, and must leave them as is.
A Parallels disk consists of two parts: the set of snapshots and the disk
descriptor file, which stores information about all files and snapshots.
Definitions
-----------
Snapshot
a record of the contents captured at a particular time, capable
of storing current state. A snapshot has a UUID and a parent UUID.
Snapshot image
an overlay representing the difference between this
snapshot and some earlier snapshot.
Overlay
an image storing the different sectors between two captured states.
Root image
a snapshot image with no parent, the root of the snapshot tree.
Storage
the backing storage for a subset of the virtual disk. When
there is more than one storage in a Parallels disk then that
is referred to as a split image. In this case every storage
covers a specific address space area of the disk and has its
particular root image. Split images are not considered here
and are not supported. Each storage consists of disk
parameters and a list of images. The list of images always
contains a root image and may also contain overlays. The
root image can be an expandable Parallels image file or
plain. Overlays must be expandable.
Description file
``DiskDescriptor.xml`` stores information about disk parameters,
snapshots, and storages.
Top Snapshot
The overlay between actual state and some previous snapshot.
It is not a snapshot in the classical sense because it
serves as the active image that the guest writes to.
Sector
a 512-byte data chunk.
Description file
----------------
All information is placed in a single XML element
``Parallels_disk_image``.
The element has only one attribute, ``Version``, which must be ``1.0``.
The schema of ``DiskDescriptor.xml``::
<Parallels_disk_image Version="1.0">
<Disk_Parameters>
...
</Disk_Parameters>
<StorageData>
...
</StorageData>
<Snapshots>
...
</Snapshots>
</Parallels_disk_image>
``Disk_Parameters`` element
^^^^^^^^^^^^^^^^^^^^^^^^^^^
The ``Disk_Parameters`` element describes the physical layout of the
virtual disk and some general settings.
The ``Disk_Parameters`` element MUST contain the following child elements:
* ``Disk_size`` - number of sectors in the disk,
desired size of the disk.
* ``Cylinders`` - number of the disk cylinders.
* ``Heads`` - number of the disk heads.
* ``Sectors`` - number of the disk sectors per cylinder
(sector size is 512 bytes)
Limitation: The product of the ``Heads``, ``Sectors`` and ``Cylinders``
values MUST be equal to the value of the Disk_size parameter.
* ``Padding`` - must be 0. Parallels Cloud Server and Parallels Desktop may
use padding set to 1; however this case is not covered
by this specification. QEMU and other software should not open
such disks and should not create them.
``StorageData`` element
^^^^^^^^^^^^^^^^^^^^^^^
This element of the file describes the root image and all snapshot images.
The ``StorageData`` element consists of the ``Storage`` child element,
as shown below::
<StorageData>
<Storage>
...
</Storage>
</StorageData>
A ``Storage`` element has the following child elements:
* ``Start`` - start sector of the storage, in case of non split storage
equals to 0.
* ``End`` - number of sector following the last sector, in case of non
split storage equals to ``Disk_size``.
* ``Blocksize`` - storage cluster size, number of sectors per one cluster.
The cluster size for each "Compressed" (see below) image in
a parallels disk must be equal to this field. Note: the cluster
size for a Parallels Expandable Image is in the ``tracks`` field of
its header (see :doc:`parallels`).
* Several ``Image`` child elements.
Each ``Image`` element has the following child elements:
* ``GUID`` - image identifier, UUID in curly brackets.
For instance, ``{12345678-9abc-def1-2345-6789abcdef12}.``
The GUID is used by the Snapshots element to reference images
(see below)
* ``Type`` - image type of the element. It can be:
* ``Plain`` for raw files.
* ``Compressed`` for expanding disks.
* ``File`` - path to image file. The path can be relative to
``DiskDescriptor.xml`` or absolute.
``Snapshots`` element
^^^^^^^^^^^^^^^^^^^^^
The ``Snapshots`` element describes the snapshot relations with the snapshot tree.
The element contains the set of ``Shot`` child elements, as shown below::
<Snapshots>
<TopGUID> ... </TopGUID> /* Optional child element */
<Shot>
...
</Shot>
<Shot>
...
</Shot>
...
</Snapshots>
Each ``Shot`` element contains the following child elements:
* ``GUID`` - an image GUID.
* ``ParentGUID`` - GUID of the image of the parent snapshot.
The software may traverse snapshots from child to parent using the
``<ParentGUID>`` field as reference. The ``ParentGUID`` of the root
snapshot is ``{00000000-0000-0000-0000-000000000000}``.
There should be only one root snapshot.
The Top snapshot could be
described via two ways: via the ``TopGUID`` child
element of the ``Snapshots`` element, or via the predefined GUID
``{5fbaabe3-6958-40ff-92a7-860e329aab41}``. If ``TopGUID`` is defined,
the predefined GUID is interpreted as a normal GUID. All snapshot images
(except the Top Snapshot) should be
opened read-only.
There is another predefined GUID,
``BackupID = {704718e1-2314-44c8-9087-d78ed36b0f4e}``, which is used by
original and some third-party software for backup. QEMU and other
software may operate with images with ``GUID = BackupID`` as usual.
However, it is not recommended to use this
GUID for new disks. The Top snapshot cannot have this GUID.
docs/interop/prl-xml.txt
-158
View File
@@ -1,158 +0,0 @@
= License =
Copyright (c) 2015-2017, Virtuozzo, Inc.
Authors:
2015 Denis Lunev <den@openvz.org>
2015 Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
2016-2017 Klim Kireev <klim.kireev@virtuozzo.com>
2016-2017 Edgar Kaziakhmedov <edgar.kaziakhmedov@virtuozzo.com>
This work is licensed under the terms of the GNU GPL, version 2 or later.
See the COPYING file in the top-level directory.
This specification contains minimal information about Parallels Disk Format,
which is enough to proper work with QEMU. Nevertheless, Parallels Cloud Server
and Parallels Desktop are able to add some unspecified nodes to xml and use
them, but they are for internal work and don't affect functionality. Also it
uses auxiliary xml "Snapshot.xml", which allows to store optional snapshot
information, but it doesn't influence open/read/write functionality. QEMU and
other software should not use fields not covered in this document and
Snapshot.xml file and must leave them as is.
= Parallels Disk Format =
Parallels disk consists of two parts: the set of snapshots and the disk
descriptor file, which stores information about all files and snapshots.
== Definitions ==
Snapshot a record of the contents captured at a particular time,
capable of storing current state. A snapshot has UUID and
parent UUID.
Snapshot image an overlay representing the difference between this
snapshot and some earlier snapshot.
Overlay an image storing the different sectors between two captured
states.
Root image snapshot image with no parent, the root of snapshot tree.
Storage the backing storage for a subset of the virtual disk. When
there is more than one storage in a Parallels disk then that
is referred to as a split image. In this case every storage
covers specific address space area of the disk and has its
particular root image. Split images are not considered here
and are not supported. Each storage consists of disk
parameters and a list of images. The list of images always
contains a root image and may also contain overlays. The
root image can be an expandable Parallels image file or
plain. Overlays must be expandable.
Description DiskDescriptor.xml stores information about disk parameters,
file snapshots, storages.
Top The overlay between actual state and some previous snapshot.
Snapshot It is not a snapshot in the classical sense because it
serves as the active image that the guest writes to.
Sector a 512-byte data chunk.
== Description file ==
All information is placed in a single XML element Parallels_disk_image.
The element has only one attribute "Version", that must be 1.0.
Schema of DiskDescriptor.xml:
<Parallels_disk_image Version="1.0">
<Disk_Parameters>
...
</Disk_Parameters>
<StorageData>
...
</StorageData>
<Snapshots>
...
</Snapshots>
</Parallels_disk_image>
== Disk_Parameters element ==
The Disk_Parameters element describes the physical layout of the virtual disk
and some general settings.
The Disk_Parameters element MUST contain the following child elements:
* Disk_size - number of sectors in the disk,
desired size of the disk.
* Cylinders - number of the disk cylinders.
* Heads - number of the disk heads.
* Sectors - number of the disk sectors per cylinder
(sector size is 512 bytes)
Limitation: Product of the Heads, Sectors and Cylinders
values MUST be equal to the value of the Disk_size parameter.
* Padding - must be 0. Parallels Cloud Server and Parallels Desktop may
use padding set to 1, however this case is not covered
by this spec, QEMU and other software should not open
such disks and should not create them.
== StorageData element ==
This element of the file describes the root image and all snapshot images.
The StorageData element consists of the Storage child element, as shown below:
<StorageData>
<Storage>
...
</Storage>
</StorageData>
A Storage element has following child elements:
* Start - start sector of the storage, in case of non split storage
equals to 0.
* End - number of sector following the last sector, in case of non
split storage equals to Disk_size.
* Blocksize - storage cluster size, number of sectors per one cluster.
Cluster size for each "Compressed" (see below) image in
parallels disk must be equal to this field. Note: cluster
size for Parallels Expandable Image is in 'tracks' field of
its header (see docs/interop/parallels.txt).
* Several Image child elements.
Each Image element has following child elements:
* GUID - image identifier, UUID in curly brackets.
For instance, {12345678-9abc-def1-2345-6789abcdef12}.
The GUID is used by the Snapshots element to reference images
(see below)
* Type - image type of the element. It can be:
"Plain" for raw files.
"Compressed" for expanding disks.
* File - path to image file. Path can be relative to DiskDescriptor.xml or
absolute.
== Snapshots element ==
The Snapshots element describes the snapshot relations with the snapshot tree.
The element contains the set of Shot child elements, as shown below:
<Snapshots>
<TopGUID> ... </TopGUID> /* Optional child element */
<Shot>
...
</Shot>
<Shot>
...
</Shot>
...
</Snapshots>
Each Shot element contains the following child elements:
* GUID - an image GUID.
* ParentGUID - GUID of the image of the parent snapshot.
The software may traverse snapshots from child to parent using <ParentGUID>
field as reference. ParentGUID of root snapshot is
{00000000-0000-0000-0000-000000000000}. There should be only one root
snapshot. Top snapshot could be described via two ways: via TopGUID child
element of the Snapshots element or via predefined GUID
{5fbaabe3-6958-40ff-92a7-860e329aab41}. If TopGUID is defined, predefined GUID is
interpreted as usual GUID. All snapshot images (except Top Snapshot) should be
opened read-only. There is another predefined GUID,
BackupID = {704718e1-2314-44c8-9087-d78ed36b0f4e}, which is used by original and
some third-party software for backup, QEMU and other software may operate with
images with GUID = BackupID as usual, however, it is not recommended to use this
GUID for new disks. Top snapshot cannot have this GUID.
docs/specs/index.rst
+1
View File
@@ -35,3 +35,4 @@ guest hardware that is specific to QEMU.
vmcoreinfo
vmgenid
rapl-msr
rocker
docs/specs/rocker.txt → docs/specs/rocker.rst
+91 -90
View File
File diff suppressed because it is too large Load Diff
hw/arm/virt-acpi-build.c
+3 -3
View File
@@ -154,10 +154,10 @@ static void acpi_dsdt_add_gpio(Aml *scope, const MemMapEntry *gpio_memmap,
aml_append(dev, aml_name_decl("_CRS", crs));
Aml *aei = aml_resource_template();
/* Pin 3 for power button */
const uint32_t pin_list[1] = {3};
const uint32_t pin = GPIO_PIN_POWER_BUTTON;
aml_append(aei, aml_gpio_int(AML_CONSUMER, AML_EDGE, AML_ACTIVE_HIGH,
AML_EXCLUSIVE, AML_PULL_UP, 0, pin_list, 1,
AML_EXCLUSIVE, AML_PULL_UP, 0, &pin, 1,
"GPO0", NULL, 0));
aml_append(dev, aml_name_decl("_AEI", aei));
hw/arm/virt.c
+4 -3
View File
@@ -1004,7 +1004,7 @@ static void virt_powerdown_req(Notifier *n, void *opaque)
if (s->acpi_dev) {
acpi_send_event(s->acpi_dev, ACPI_POWER_DOWN_STATUS);
} else {
/* use gpio Pin 3 for power button event */
/* use gpio Pin for power button event */
qemu_set_irq(qdev_get_gpio_in(gpio_key_dev, 0), 1);
}
}
@@ -1013,7 +1013,8 @@ static void create_gpio_keys(char *fdt, DeviceState *pl061_dev,
uint32_t phandle)
{
gpio_key_dev = sysbus_create_simple("gpio-key", -1,
qdev_get_gpio_in(pl061_dev, 3));
qdev_get_gpio_in(pl061_dev,
GPIO_PIN_POWER_BUTTON));
qemu_fdt_add_subnode(fdt, "/gpio-keys");
qemu_fdt_setprop_string(fdt, "/gpio-keys", "compatible", "gpio-keys");
@@ -1024,7 +1025,7 @@ static void create_gpio_keys(char *fdt, DeviceState *pl061_dev,
qemu_fdt_setprop_cell(fdt, "/gpio-keys/poweroff", "linux,code",
KEY_POWER);
qemu_fdt_setprop_cells(fdt, "/gpio-keys/poweroff",
"gpios", phandle, 3, 0);
"gpios", phandle, GPIO_PIN_POWER_BUTTON, 0);
}
#define SECURE_GPIO_POWEROFF 0
hw/core/ptimer.c
+2 -2
View File
@@ -83,7 +83,7 @@ static void ptimer_reload(ptimer_state *s, int delta_adjust)
delta = s->delta = s->limit;
}
if (s->period == 0) {
if (s->period == 0 && s->period_frac == 0) {
if (!qtest_enabled()) {
fprintf(stderr, "Timer with period zero, disabling\n");
}
@@ -309,7 +309,7 @@ void ptimer_run(ptimer_state *s, int oneshot)
assert(s->in_transaction);
if (was_disabled && s->period == 0) {
if (was_disabled && s->period == 0 && s->period_frac == 0) {
if (!qtest_enabled()) {
fprintf(stderr, "Timer with period zero, disabling\n");
}
include/hw/arm/virt.h
+3
View File
@@ -47,6 +47,9 @@
/* See Linux kernel arch/arm64/include/asm/pvclock-abi.h */
#define PVTIME_SIZE_PER_CPU 64
/* GPIO pins */
#define GPIO_PIN_POWER_BUTTON 3
enum {
VIRT_FLASH,
VIRT_MEM,
include/qapi/qmp/qobject.h
+1 -1
View File
@@ -54,7 +54,7 @@ struct QObject {
typeof(obj) _obj = (obj); \
_obj ? container_of(&_obj->base, QObject, base) : NULL; \
})
#define QOBJECT(obj) QOBJECT_INTERNAL((obj), MAKE_IDENTFIER(_obj))
#define QOBJECT(obj) QOBJECT_INTERNAL((obj), MAKE_IDENTIFIER(_obj))
/* Required for qobject_to() */
#define QTYPE_CAST_TO_QNull QTYPE_QNULL
include/qemu/atomic.h
+1 -1
View File
@@ -128,7 +128,7 @@
_val; \
})
#define qatomic_rcu_read(ptr) \
qatomic_rcu_read_internal((ptr), MAKE_IDENTFIER(_val))
qatomic_rcu_read_internal((ptr), MAKE_IDENTIFIER(_val))
#define qatomic_rcu_set(ptr, i) do { \
qemu_build_assert(sizeof(*ptr) <= ATOMIC_REG_SIZE); \
include/qemu/compiler.h
+1 -1
View File
@@ -38,7 +38,7 @@
#endif
/* Expands into an identifier stemN, where N is another number each time */
#define MAKE_IDENTFIER(stem) glue(stem, __COUNTER__)
#define MAKE_IDENTIFIER(stem) glue(stem, __COUNTER__)
#ifndef likely
#define likely(x) __builtin_expect(!!(x), 1)
include/qemu/osdep.h
+3 -3
View File
@@ -399,7 +399,7 @@ void QEMU_ERROR("code path is reachable")
})
#undef MIN
#define MIN(a, b) \
MIN_INTERNAL((a), (b), MAKE_IDENTFIER(_a), MAKE_IDENTFIER(_b))
MIN_INTERNAL((a), (b), MAKE_IDENTIFIER(_a), MAKE_IDENTIFIER(_b))
#define MAX_INTERNAL(a, b, _a, _b) \
({ \
@@ -408,7 +408,7 @@ void QEMU_ERROR("code path is reachable")
})
#undef MAX
#define MAX(a, b) \
MAX_INTERNAL((a), (b), MAKE_IDENTFIER(_a), MAKE_IDENTFIER(_b))
MAX_INTERNAL((a), (b), MAKE_IDENTIFIER(_a), MAKE_IDENTIFIER(_b))
#ifdef __COVERITY__
# define MIN_CONST(a, b) ((a) < (b) ? (a) : (b))
@@ -440,7 +440,7 @@ void QEMU_ERROR("code path is reachable")
_a == 0 ? _b : (_b == 0 || _b > _a) ? _a : _b; \
})
#define MIN_NON_ZERO(a, b) \
MIN_NON_ZERO_INTERNAL((a), (b), MAKE_IDENTFIER(_a), MAKE_IDENTFIER(_b))
MIN_NON_ZERO_INTERNAL((a), (b), MAKE_IDENTIFIER(_a), MAKE_IDENTIFIER(_b))
/*
* Round number down to multiple. Safe when m is not a power of 2 (see
target/arm/tcg/helper-a64.c
+39
View File
@@ -1877,3 +1877,42 @@ void HELPER(cpyfe)(CPUARMState *env, uint32_t syndrome, uint32_t wdesc,
{
do_cpye(env, syndrome, wdesc, rdesc, false, GETPC());
}
static bool is_guarded_page(CPUARMState *env, target_ulong addr, uintptr_t ra)
{
#ifdef CONFIG_USER_ONLY
return page_get_flags(addr) & PAGE_BTI;
#else
CPUTLBEntryFull *full;
void *host;
int mmu_idx = cpu_mmu_index(env_cpu(env), true);
int flags = probe_access_full(env, addr, 0, MMU_INST_FETCH, mmu_idx,
false, &host, &full, ra);
assert(!(flags & TLB_INVALID_MASK));
return full->extra.arm.guarded;
#endif
}
void HELPER(guarded_page_check)(CPUARMState *env)
{
/*
* We have already verified that bti is enabled, and that the
* instruction at PC is not ok for BTYPE. This is always at
* the beginning of a block, so PC is always up-to-date and
* no unwind is required.
*/
if (is_guarded_page(env, env->pc, 0)) {
raise_exception(env, EXCP_UDEF, syn_btitrap(env->btype),
exception_target_el(env));
}
}
void HELPER(guarded_page_br)(CPUARMState *env, target_ulong pc)
{
/*
* We have already checked for branch via x16 and x17.
* What remains for choosing BTYPE is checking for a guarded page.
*/
env->btype = is_guarded_page(env, pc, GETPC()) ? 3 : 1;
}
target/arm/tcg/helper-a64.h
+3
View File
@@ -133,6 +133,9 @@ DEF_HELPER_4(cpyfp, void, env, i32, i32, i32)
DEF_HELPER_4(cpyfm, void, env, i32, i32, i32)
DEF_HELPER_4(cpyfe, void, env, i32, i32, i32)
DEF_HELPER_FLAGS_1(guarded_page_check, TCG_CALL_NO_WG, void, env)
DEF_HELPER_FLAGS_2(guarded_page_br, TCG_CALL_NO_RWG, void, env, tl)
DEF_HELPER_FLAGS_5(gvec_fdiv_h, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, ptr, i32)
DEF_HELPER_FLAGS_5(gvec_fdiv_s, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, ptr, i32)
DEF_HELPER_FLAGS_5(gvec_fdiv_d, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, ptr, i32)

Some files were not shown because too many files have changed in this diff Show More