F: docs/*/conf.py
F: docs/sphinx/
F: docs/_templates/
+F: docs/devel/docs.rst
Miscellaneous
-------------
--- /dev/null
+
+==================
+QEMU Documentation
+==================
+
+QEMU's documentation is written in reStructuredText format and
+built using the Sphinx documentation generator. We generate both
+the HTML manual and the manpages from the some documentation sources.
+
+hxtool and .hx files
+--------------------
+
+The documentation for QEMU command line options and Human Monitor Protocol
+(HMP) commands is written in files with the ``.hx`` suffix. These
+are processed in two ways:
+
+ * ``scripts/hxtool`` creates C header files from them, which are included
+ in QEMU to do things like handle the ``--help`` option output
+ * a Sphinx extension in ``docs/sphinx/hxtool.py`` generates rST output
+ to be included in the HTML or manpage documentation
+
+The syntax of these ``.hx`` files is simple. It is broadly an
+alternation of C code put into the C output and rST format text
+put into the documention. A few special directives are recognised;
+these are all-caps and must be at the beginning of the line.
+
+``HXCOMM`` is the comment marker. The line, including any arbitrary
+text after the marker, is discarded and appears neither in the C output
+nor the documentation output.
+
+``SRST`` starts a reStructuredText section. Following lines
+are put into the documentation verbatim, and discarded from the C output.
+
+``ERST`` ends the documentation section started with ``SRST``,
+and switches back to a C code section.
+
+``DEFHEADING()`` defines a heading that should appear in both the
+``--help`` output and in the documentation. This directive should
+be in the C code block. If there is a string inside the brackets,
+this is the heading to use. If this string is empty, it produces
+a blank line in the ``--help`` output and is ignored for the rST
+output.
+
+``ARCHHEADING()`` is a variant of ``DEFHEADING()`` which produces
+the heading only if the specified guest architecture was compiled
+into QEMU. This should be avoided in new documentation.
+
+Within C code sections, you should check the comments at the top
+of the file to see what the expected usage is, because this
+varies between files. For instance in ``qemu-options.hx`` we use
+the ``DEF()`` macro to define each option and specify its ``--help``
+text, but in ``hmp-commands.hx`` the C code sections are elements
+of an array of structs of type ``HMPCommand`` which define the
+name, behaviour and help text for each monitor command.
+
+In the file ``qemu-options.hx``, do not try to define a
+reStructuredText label within a documentation section. This file
+is included into two separate Sphinx documents, and some
+versions of Sphinx will complain about the duplicate label
+that results.
build-system
kconfig
+ docs
testing
acpi-bits
qtest
block-coroutine-wrapper
clocks
ebpf_rss
- migration
+ migration/index
multi-process
reset
s390-cpu-topology
s390-dasd-ipl
tracing
- vfio-migration
vfio-iommufd
writing-monitor-commands
virtio-backends
+++ /dev/null
-=========
-Migration
-=========
-
-QEMU has code to load/save the state of the guest that it is running.
-These are two complementary operations. Saving the state just does
-that, saves the state for each device that the guest is running.
-Restoring a guest is just the opposite operation: we need to load the
-state of each device.
-
-For this to work, QEMU has to be launched with the same arguments the
-two times. I.e. it can only restore the state in one guest that has
-the same devices that the one it was saved (this last requirement can
-be relaxed a bit, but for now we can consider that configuration has
-to be exactly the same).
-
-Once that we are able to save/restore a guest, a new functionality is
-requested: migration. This means that QEMU is able to start in one
-machine and being "migrated" to another machine. I.e. being moved to
-another machine.
-
-Next was the "live migration" functionality. This is important
-because some guests run with a lot of state (specially RAM), and it
-can take a while to move all state from one machine to another. Live
-migration allows the guest to continue running while the state is
-transferred. Only while the last part of the state is transferred has
-the guest to be stopped. Typically the time that the guest is
-unresponsive during live migration is the low hundred of milliseconds
-(notice that this depends on a lot of things).
-
-.. contents::
-
-Transports
-==========
-
-The migration stream is normally just a byte stream that can be passed
-over any transport.
-
-- tcp migration: do the migration using tcp sockets
-- unix migration: do the migration using unix sockets
-- exec migration: do the migration using the stdin/stdout through a process.
-- fd migration: do the migration using a file descriptor that is
- passed to QEMU. QEMU doesn't care how this file descriptor is opened.
-
-In addition, support is included for migration using RDMA, which
-transports the page data using ``RDMA``, where the hardware takes care of
-transporting the pages, and the load on the CPU is much lower. While the
-internals of RDMA migration are a bit different, this isn't really visible
-outside the RAM migration code.
-
-All these migration protocols use the same infrastructure to
-save/restore state devices. This infrastructure is shared with the
-savevm/loadvm functionality.
-
-Debugging
-=========
-
-The migration stream can be analyzed thanks to ``scripts/analyze-migration.py``.
-
-Example usage:
-
-.. code-block:: shell
-
- $ qemu-system-x86_64 -display none -monitor stdio
- (qemu) migrate "exec:cat > mig"
- (qemu) q
- $ ./scripts/analyze-migration.py -f mig
- {
- "ram (3)": {
- "section sizes": {
- "pc.ram": "0x0000000008000000",
- ...
-
-See also ``analyze-migration.py -h`` help for more options.
-
-Common infrastructure
-=====================
-
-The files, sockets or fd's that carry the migration stream are abstracted by
-the ``QEMUFile`` type (see ``migration/qemu-file.h``). In most cases this
-is connected to a subtype of ``QIOChannel`` (see ``io/``).
-
-
-Saving the state of one device
-==============================
-
-For most devices, the state is saved in a single call to the migration
-infrastructure; these are *non-iterative* devices. The data for these
-devices is sent at the end of precopy migration, when the CPUs are paused.
-There are also *iterative* devices, which contain a very large amount of
-data (e.g. RAM or large tables). See the iterative device section below.
-
-General advice for device developers
-------------------------------------
-
-- The migration state saved should reflect the device being modelled rather
- than the way your implementation works. That way if you change the implementation
- later the migration stream will stay compatible. That model may include
- internal state that's not directly visible in a register.
-
-- When saving a migration stream the device code may walk and check
- the state of the device. These checks might fail in various ways (e.g.
- discovering internal state is corrupt or that the guest has done something bad).
- Consider carefully before asserting/aborting at this point, since the
- normal response from users is that *migration broke their VM* since it had
- apparently been running fine until then. In these error cases, the device
- should log a message indicating the cause of error, and should consider
- putting the device into an error state, allowing the rest of the VM to
- continue execution.
-
-- The migration might happen at an inconvenient point,
- e.g. right in the middle of the guest reprogramming the device, during
- guest reboot or shutdown or while the device is waiting for external IO.
- It's strongly preferred that migrations do not fail in this situation,
- since in the cloud environment migrations might happen automatically to
- VMs that the administrator doesn't directly control.
-
-- If you do need to fail a migration, ensure that sufficient information
- is logged to identify what went wrong.
-
-- The destination should treat an incoming migration stream as hostile
- (which we do to varying degrees in the existing code). Check that offsets
- into buffers and the like can't cause overruns. Fail the incoming migration
- in the case of a corrupted stream like this.
-
-- Take care with internal device state or behaviour that might become
- migration version dependent. For example, the order of PCI capabilities
- is required to stay constant across migration. Another example would
- be that a special case handled by subsections (see below) might become
- much more common if a default behaviour is changed.
-
-- The state of the source should not be changed or destroyed by the
- outgoing migration. Migrations timing out or being failed by
- higher levels of management, or failures of the destination host are
- not unusual, and in that case the VM is restarted on the source.
- Note that the management layer can validly revert the migration
- even though the QEMU level of migration has succeeded as long as it
- does it before starting execution on the destination.
-
-- Buses and devices should be able to explicitly specify addresses when
- instantiated, and management tools should use those. For example,
- when hot adding USB devices it's important to specify the ports
- and addresses, since implicit ordering based on the command line order
- may be different on the destination. This can result in the
- device state being loaded into the wrong device.
-
-VMState
--------
-
-Most device data can be described using the ``VMSTATE`` macros (mostly defined
-in ``include/migration/vmstate.h``).
-
-An example (from hw/input/pckbd.c)
-
-.. code:: c
-
- static const VMStateDescription vmstate_kbd = {
- .name = "pckbd",
- .version_id = 3,
- .minimum_version_id = 3,
- .fields = (const VMStateField[]) {
- VMSTATE_UINT8(write_cmd, KBDState),
- VMSTATE_UINT8(status, KBDState),
- VMSTATE_UINT8(mode, KBDState),
- VMSTATE_UINT8(pending, KBDState),
- VMSTATE_END_OF_LIST()
- }
- };
-
-We are declaring the state with name "pckbd". The ``version_id`` is
-3, and there are 4 uint8_t fields in the KBDState structure. We
-registered this ``VMSTATEDescription`` with one of the following
-functions. The first one will generate a device ``instance_id``
-different for each registration. Use the second one if you already
-have an id that is different for each instance of the device:
-
-.. code:: c
-
- vmstate_register_any(NULL, &vmstate_kbd, s);
- vmstate_register(NULL, instance_id, &vmstate_kbd, s);
-
-For devices that are ``qdev`` based, we can register the device in the class
-init function:
-
-.. code:: c
-
- dc->vmsd = &vmstate_kbd_isa;
-
-The VMState macros take care of ensuring that the device data section
-is formatted portably (normally big endian) and make some compile time checks
-against the types of the fields in the structures.
-
-VMState macros can include other VMStateDescriptions to store substructures
-(see ``VMSTATE_STRUCT_``), arrays (``VMSTATE_ARRAY_``) and variable length
-arrays (``VMSTATE_VARRAY_``). Various other macros exist for special
-cases.
-
-Note that the format on the wire is still very raw; i.e. a VMSTATE_UINT32
-ends up with a 4 byte bigendian representation on the wire; in the future
-it might be possible to use a more structured format.
-
-Legacy way
-----------
-
-This way is going to disappear as soon as all current users are ported to VMSTATE;
-although converting existing code can be tricky, and thus 'soon' is relative.
-
-Each device has to register two functions, one to save the state and
-another to load the state back.
-
-.. code:: c
-
- int register_savevm_live(const char *idstr,
- int instance_id,
- int version_id,
- SaveVMHandlers *ops,
- void *opaque);
-
-Two functions in the ``ops`` structure are the ``save_state``
-and ``load_state`` functions. Notice that ``load_state`` receives a version_id
-parameter to know what state format is receiving. ``save_state`` doesn't
-have a version_id parameter because it always uses the latest version.
-
-Note that because the VMState macros still save the data in a raw
-format, in many cases it's possible to replace legacy code
-with a carefully constructed VMState description that matches the
-byte layout of the existing code.
-
-Changing migration data structures
-----------------------------------
-
-When we migrate a device, we save/load the state as a series
-of fields. Sometimes, due to bugs or new functionality, we need to
-change the state to store more/different information. Changing the migration
-state saved for a device can break migration compatibility unless
-care is taken to use the appropriate techniques. In general QEMU tries
-to maintain forward migration compatibility (i.e. migrating from
-QEMU n->n+1) and there are users who benefit from backward compatibility
-as well.
-
-Subsections
------------
-
-The most common structure change is adding new data, e.g. when adding
-a newer form of device, or adding that state that you previously
-forgot to migrate. This is best solved using a subsection.
-
-A subsection is "like" a device vmstate, but with a particularity, it
-has a Boolean function that tells if that values are needed to be sent
-or not. If this functions returns false, the subsection is not sent.
-Subsections have a unique name, that is looked for on the receiving
-side.
-
-On the receiving side, if we found a subsection for a device that we
-don't understand, we just fail the migration. If we understand all
-the subsections, then we load the state with success. There's no check
-that a subsection is loaded, so a newer QEMU that knows about a subsection
-can (with care) load a stream from an older QEMU that didn't send
-the subsection.
-
-If the new data is only needed in a rare case, then the subsection
-can be made conditional on that case and the migration will still
-succeed to older QEMUs in most cases. This is OK for data that's
-critical, but in some use cases it's preferred that the migration
-should succeed even with the data missing. To support this the
-subsection can be connected to a device property and from there
-to a versioned machine type.
-
-The 'pre_load' and 'post_load' functions on subsections are only
-called if the subsection is loaded.
-
-One important note is that the outer post_load() function is called "after"
-loading all subsections, because a newer subsection could change the same
-value that it uses. A flag, and the combination of outer pre_load and
-post_load can be used to detect whether a subsection was loaded, and to
-fall back on default behaviour when the subsection isn't present.
-
-Example:
-
-.. code:: c
-
- static bool ide_drive_pio_state_needed(void *opaque)
- {
- IDEState *s = opaque;
-
- return ((s->status & DRQ_STAT) != 0)
- || (s->bus->error_status & BM_STATUS_PIO_RETRY);
- }
-
- const VMStateDescription vmstate_ide_drive_pio_state = {
- .name = "ide_drive/pio_state",
- .version_id = 1,
- .minimum_version_id = 1,
- .pre_save = ide_drive_pio_pre_save,
- .post_load = ide_drive_pio_post_load,
- .needed = ide_drive_pio_state_needed,
- .fields = (const VMStateField[]) {
- VMSTATE_INT32(req_nb_sectors, IDEState),
- VMSTATE_VARRAY_INT32(io_buffer, IDEState, io_buffer_total_len, 1,
- vmstate_info_uint8, uint8_t),
- VMSTATE_INT32(cur_io_buffer_offset, IDEState),
- VMSTATE_INT32(cur_io_buffer_len, IDEState),
- VMSTATE_UINT8(end_transfer_fn_idx, IDEState),
- VMSTATE_INT32(elementary_transfer_size, IDEState),
- VMSTATE_INT32(packet_transfer_size, IDEState),
- VMSTATE_END_OF_LIST()
- }
- };
-
- const VMStateDescription vmstate_ide_drive = {
- .name = "ide_drive",
- .version_id = 3,
- .minimum_version_id = 0,
- .post_load = ide_drive_post_load,
- .fields = (const VMStateField[]) {
- .... several fields ....
- VMSTATE_END_OF_LIST()
- },
- .subsections = (const VMStateDescription * const []) {
- &vmstate_ide_drive_pio_state,
- NULL
- }
- };
-
-Here we have a subsection for the pio state. We only need to
-save/send this state when we are in the middle of a pio operation
-(that is what ``ide_drive_pio_state_needed()`` checks). If DRQ_STAT is
-not enabled, the values on that fields are garbage and don't need to
-be sent.
-
-Connecting subsections to properties
-------------------------------------
-
-Using a condition function that checks a 'property' to determine whether
-to send a subsection allows backward migration compatibility when
-new subsections are added, especially when combined with versioned
-machine types.
-
-For example:
-
- a) Add a new property using ``DEFINE_PROP_BOOL`` - e.g. support-foo and
- default it to true.
- b) Add an entry to the ``hw_compat_`` for the previous version that sets
- the property to false.
- c) Add a static bool support_foo function that tests the property.
- d) Add a subsection with a .needed set to the support_foo function
- e) (potentially) Add an outer pre_load that sets up a default value
- for 'foo' to be used if the subsection isn't loaded.
-
-Now that subsection will not be generated when using an older
-machine type and the migration stream will be accepted by older
-QEMU versions.
-
-Not sending existing elements
------------------------------
-
-Sometimes members of the VMState are no longer needed:
-
- - removing them will break migration compatibility
-
- - making them version dependent and bumping the version will break backward migration
- compatibility.
-
-Adding a dummy field into the migration stream is normally the best way to preserve
-compatibility.
-
-If the field really does need to be removed then:
-
- a) Add a new property/compatibility/function in the same way for subsections above.
- b) replace the VMSTATE macro with the _TEST version of the macro, e.g.:
-
- ``VMSTATE_UINT32(foo, barstruct)``
-
- becomes
-
- ``VMSTATE_UINT32_TEST(foo, barstruct, pre_version_baz)``
-
- Sometime in the future when we no longer care about the ancient versions these can be killed off.
- Note that for backward compatibility it's important to fill in the structure with
- data that the destination will understand.
-
-Any difference in the predicates on the source and destination will end up
-with different fields being enabled and data being loaded into the wrong
-fields; for this reason conditional fields like this are very fragile.
-
-Versions
---------
-
-Version numbers are intended for major incompatible changes to the
-migration of a device, and using them breaks backward-migration
-compatibility; in general most changes can be made by adding Subsections
-(see above) or _TEST macros (see above) which won't break compatibility.
-
-Each version is associated with a series of fields saved. The ``save_state`` always saves
-the state as the newer version. But ``load_state`` sometimes is able to
-load state from an older version.
-
-You can see that there are two version fields:
-
-- ``version_id``: the maximum version_id supported by VMState for that device.
-- ``minimum_version_id``: the minimum version_id that VMState is able to understand
- for that device.
-
-VMState is able to read versions from minimum_version_id to version_id.
-
-There are *_V* forms of many ``VMSTATE_`` macros to load fields for version dependent fields,
-e.g.
-
-.. code:: c
-
- VMSTATE_UINT16_V(ip_id, Slirp, 2),
-
-only loads that field for versions 2 and newer.
-
-Saving state will always create a section with the 'version_id' value
-and thus can't be loaded by any older QEMU.
-
-Massaging functions
--------------------
-
-Sometimes, it is not enough to be able to save the state directly
-from one structure, we need to fill the correct values there. One
-example is when we are using kvm. Before saving the cpu state, we
-need to ask kvm to copy to QEMU the state that it is using. And the
-opposite when we are loading the state, we need a way to tell kvm to
-load the state for the cpu that we have just loaded from the QEMUFile.
-
-The functions to do that are inside a vmstate definition, and are called:
-
-- ``int (*pre_load)(void *opaque);``
-
- This function is called before we load the state of one device.
-
-- ``int (*post_load)(void *opaque, int version_id);``
-
- This function is called after we load the state of one device.
-
-- ``int (*pre_save)(void *opaque);``
-
- This function is called before we save the state of one device.
-
-- ``int (*post_save)(void *opaque);``
-
- This function is called after we save the state of one device
- (even upon failure, unless the call to pre_save returned an error).
-
-Example: You can look at hpet.c, that uses the first three functions
-to massage the state that is transferred.
-
-The ``VMSTATE_WITH_TMP`` macro may be useful when the migration
-data doesn't match the stored device data well; it allows an
-intermediate temporary structure to be populated with migration
-data and then transferred to the main structure.
-
-If you use memory API functions that update memory layout outside
-initialization (i.e., in response to a guest action), this is a strong
-indication that you need to call these functions in a ``post_load`` callback.
-Examples of such memory API functions are:
-
- - memory_region_add_subregion()
- - memory_region_del_subregion()
- - memory_region_set_readonly()
- - memory_region_set_nonvolatile()
- - memory_region_set_enabled()
- - memory_region_set_address()
- - memory_region_set_alias_offset()
-
-Iterative device migration
---------------------------
-
-Some devices, such as RAM, Block storage or certain platform devices,
-have large amounts of data that would mean that the CPUs would be
-paused for too long if they were sent in one section. For these
-devices an *iterative* approach is taken.
-
-The iterative devices generally don't use VMState macros
-(although it may be possible in some cases) and instead use
-qemu_put_*/qemu_get_* macros to read/write data to the stream. Specialist
-versions exist for high bandwidth IO.
-
-
-An iterative device must provide:
-
- - A ``save_setup`` function that initialises the data structures and
- transmits a first section containing information on the device. In the
- case of RAM this transmits a list of RAMBlocks and sizes.
-
- - A ``load_setup`` function that initialises the data structures on the
- destination.
-
- - A ``state_pending_exact`` function that indicates how much more
- data we must save. The core migration code will use this to
- determine when to pause the CPUs and complete the migration.
-
- - A ``state_pending_estimate`` function that indicates how much more
- data we must save. When the estimated amount is smaller than the
- threshold, we call ``state_pending_exact``.
-
- - A ``save_live_iterate`` function should send a chunk of data until
- the point that stream bandwidth limits tell it to stop. Each call
- generates one section.
-
- - A ``save_live_complete_precopy`` function that must transmit the
- last section for the device containing any remaining data.
-
- - A ``load_state`` function used to load sections generated by
- any of the save functions that generate sections.
-
- - ``cleanup`` functions for both save and load that are called
- at the end of migration.
-
-Note that the contents of the sections for iterative migration tend
-to be open-coded by the devices; care should be taken in parsing
-the results and structuring the stream to make them easy to validate.
-
-Device ordering
----------------
-
-There are cases in which the ordering of device loading matters; for
-example in some systems where a device may assert an interrupt during loading,
-if the interrupt controller is loaded later then it might lose the state.
-
-Some ordering is implicitly provided by the order in which the machine
-definition creates devices, however this is somewhat fragile.
-
-The ``MigrationPriority`` enum provides a means of explicitly enforcing
-ordering. Numerically higher priorities are loaded earlier.
-The priority is set by setting the ``priority`` field of the top level
-``VMStateDescription`` for the device.
-
-Stream structure
-================
-
-The stream tries to be word and endian agnostic, allowing migration between hosts
-of different characteristics running the same VM.
-
- - Header
-
- - Magic
- - Version
- - VM configuration section
-
- - Machine type
- - Target page bits
- - List of sections
- Each section contains a device, or one iteration of a device save.
-
- - section type
- - section id
- - ID string (First section of each device)
- - instance id (First section of each device)
- - version id (First section of each device)
- - <device data>
- - Footer mark
- - EOF mark
- - VM Description structure
- Consisting of a JSON description of the contents for analysis only
-
-The ``device data`` in each section consists of the data produced
-by the code described above. For non-iterative devices they have a single
-section; iterative devices have an initial and last section and a set
-of parts in between.
-Note that there is very little checking by the common code of the integrity
-of the ``device data`` contents, that's up to the devices themselves.
-The ``footer mark`` provides a little bit of protection for the case where
-the receiving side reads more or less data than expected.
-
-The ``ID string`` is normally unique, having been formed from a bus name
-and device address, PCI devices and storage devices hung off PCI controllers
-fit this pattern well. Some devices are fixed single instances (e.g. "pc-ram").
-Others (especially either older devices or system devices which for
-some reason don't have a bus concept) make use of the ``instance id``
-for otherwise identically named devices.
-
-Return path
------------
-
-Only a unidirectional stream is required for normal migration, however a
-``return path`` can be created when bidirectional communication is desired.
-This is primarily used by postcopy, but is also used to return a success
-flag to the source at the end of migration.
-
-``qemu_file_get_return_path(QEMUFile* fwdpath)`` gives the QEMUFile* for the return
-path.
-
- Source side
-
- Forward path - written by migration thread
- Return path - opened by main thread, read by return-path thread
-
- Destination side
-
- Forward path - read by main thread
- Return path - opened by main thread, written by main thread AND postcopy
- thread (protected by rp_mutex)
-
-Dirty limit
-=====================
-The dirty limit, short for dirty page rate upper limit, is a new capability
-introduced in the 8.1 QEMU release that uses a new algorithm based on the KVM
-dirty ring to throttle down the guest during live migration.
-
-The algorithm framework is as follows:
-
-::
-
- ------------------------------------------------------------------------------
- main --------------> throttle thread ------------> PREPARE(1) <--------
- thread \ | |
- \ | |
- \ V |
- -\ CALCULATE(2) |
- \ | |
- \ | |
- \ V |
- \ SET PENALTY(3) -----
- -\ |
- \ |
- \ V
- -> virtual CPU thread -------> ACCEPT PENALTY(4)
- ------------------------------------------------------------------------------
-
-When the qmp command qmp_set_vcpu_dirty_limit is called for the first time,
-the QEMU main thread starts the throttle thread. The throttle thread, once
-launched, executes the loop, which consists of three steps:
-
- - PREPARE (1)
-
- The entire work of PREPARE (1) is preparation for the second stage,
- CALCULATE(2), as the name implies. It involves preparing the dirty
- page rate value and the corresponding upper limit of the VM:
- The dirty page rate is calculated via the KVM dirty ring mechanism,
- which tells QEMU how many dirty pages a virtual CPU has had since the
- last KVM_EXIT_DIRTY_RING_FULL exception; The dirty page rate upper
- limit is specified by caller, therefore fetch it directly.
-
- - CALCULATE (2)
-
- Calculate a suitable sleep period for each virtual CPU, which will be
- used to determine the penalty for the target virtual CPU. The
- computation must be done carefully in order to reduce the dirty page
- rate progressively down to the upper limit without oscillation. To
- achieve this, two strategies are provided: the first is to add or
- subtract sleep time based on the ratio of the current dirty page rate
- to the limit, which is used when the current dirty page rate is far
- from the limit; the second is to add or subtract a fixed time when
- the current dirty page rate is close to the limit.
-
- - SET PENALTY (3)
-
- Set the sleep time for each virtual CPU that should be penalized based
- on the results of the calculation supplied by step CALCULATE (2).
-
-After completing the three above stages, the throttle thread loops back
-to step PREPARE (1) until the dirty limit is reached.
-
-On the other hand, each virtual CPU thread reads the sleep duration and
-sleeps in the path of the KVM_EXIT_DIRTY_RING_FULL exception handler, that
-is ACCEPT PENALTY (4). Virtual CPUs tied with writing processes will
-obviously exit to the path and get penalized, whereas virtual CPUs involved
-with read processes will not.
-
-In summary, thanks to the KVM dirty ring technology, the dirty limit
-algorithm will restrict virtual CPUs as needed to keep their dirty page
-rate inside the limit. This leads to more steady reading performance during
-live migration and can aid in improving large guest responsiveness.
-
-Postcopy
-========
-
-'Postcopy' migration is a way to deal with migrations that refuse to converge
-(or take too long to converge) its plus side is that there is an upper bound on
-the amount of migration traffic and time it takes, the down side is that during
-the postcopy phase, a failure of *either* side causes the guest to be lost.
-
-In postcopy the destination CPUs are started before all the memory has been
-transferred, and accesses to pages that are yet to be transferred cause
-a fault that's translated by QEMU into a request to the source QEMU.
-
-Postcopy can be combined with precopy (i.e. normal migration) so that if precopy
-doesn't finish in a given time the switch is made to postcopy.
-
-Enabling postcopy
------------------
-
-To enable postcopy, issue this command on the monitor (both source and
-destination) prior to the start of migration:
-
-``migrate_set_capability postcopy-ram on``
-
-The normal commands are then used to start a migration, which is still
-started in precopy mode. Issuing:
-
-``migrate_start_postcopy``
-
-will now cause the transition from precopy to postcopy.
-It can be issued immediately after migration is started or any
-time later on. Issuing it after the end of a migration is harmless.
-
-Blocktime is a postcopy live migration metric, intended to show how
-long the vCPU was in state of interruptible sleep due to pagefault.
-That metric is calculated both for all vCPUs as overlapped value, and
-separately for each vCPU. These values are calculated on destination
-side. To enable postcopy blocktime calculation, enter following
-command on destination monitor:
-
-``migrate_set_capability postcopy-blocktime on``
-
-Postcopy blocktime can be retrieved by query-migrate qmp command.
-postcopy-blocktime value of qmp command will show overlapped blocking
-time for all vCPU, postcopy-vcpu-blocktime will show list of blocking
-time per vCPU.
-
-.. note::
- During the postcopy phase, the bandwidth limits set using
- ``migrate_set_parameter`` is ignored (to avoid delaying requested pages that
- the destination is waiting for).
-
-Postcopy device transfer
-------------------------
-
-Loading of device data may cause the device emulation to access guest RAM
-that may trigger faults that have to be resolved by the source, as such
-the migration stream has to be able to respond with page data *during* the
-device load, and hence the device data has to be read from the stream completely
-before the device load begins to free the stream up. This is achieved by
-'packaging' the device data into a blob that's read in one go.
-
-Source behaviour
-----------------
-
-Until postcopy is entered the migration stream is identical to normal
-precopy, except for the addition of a 'postcopy advise' command at
-the beginning, to tell the destination that postcopy might happen.
-When postcopy starts the source sends the page discard data and then
-forms the 'package' containing:
-
- - Command: 'postcopy listen'
- - The device state
-
- A series of sections, identical to the precopy streams device state stream
- containing everything except postcopiable devices (i.e. RAM)
- - Command: 'postcopy run'
-
-The 'package' is sent as the data part of a Command: ``CMD_PACKAGED``, and the
-contents are formatted in the same way as the main migration stream.
-
-During postcopy the source scans the list of dirty pages and sends them
-to the destination without being requested (in much the same way as precopy),
-however when a page request is received from the destination, the dirty page
-scanning restarts from the requested location. This causes requested pages
-to be sent quickly, and also causes pages directly after the requested page
-to be sent quickly in the hope that those pages are likely to be used
-by the destination soon.
-
-Destination behaviour
----------------------
-
-Initially the destination looks the same as precopy, with a single thread
-reading the migration stream; the 'postcopy advise' and 'discard' commands
-are processed to change the way RAM is managed, but don't affect the stream
-processing.
-
-::
-
- ------------------------------------------------------------------------------
- 1 2 3 4 5 6 7
- main -----DISCARD-CMD_PACKAGED ( LISTEN DEVICE DEVICE DEVICE RUN )
- thread | |
- | (page request)
- | \___
- v \
- listen thread: --- page -- page -- page -- page -- page --
-
- a b c
- ------------------------------------------------------------------------------
-
-- On receipt of ``CMD_PACKAGED`` (1)
-
- All the data associated with the package - the ( ... ) section in the diagram -
- is read into memory, and the main thread recurses into qemu_loadvm_state_main
- to process the contents of the package (2) which contains commands (3,6) and
- devices (4...)
-
-- On receipt of 'postcopy listen' - 3 -(i.e. the 1st command in the package)
-
- a new thread (a) is started that takes over servicing the migration stream,
- while the main thread carries on loading the package. It loads normal
- background page data (b) but if during a device load a fault happens (5)
- the returned page (c) is loaded by the listen thread allowing the main
- threads device load to carry on.
-
-- The last thing in the ``CMD_PACKAGED`` is a 'RUN' command (6)
-
- letting the destination CPUs start running. At the end of the
- ``CMD_PACKAGED`` (7) the main thread returns to normal running behaviour and
- is no longer used by migration, while the listen thread carries on servicing
- page data until the end of migration.
-
-Postcopy Recovery
------------------
-
-Comparing to precopy, postcopy is special on error handlings. When any
-error happens (in this case, mostly network errors), QEMU cannot easily
-fail a migration because VM data resides in both source and destination
-QEMU instances. On the other hand, when issue happens QEMU on both sides
-will go into a paused state. It'll need a recovery phase to continue a
-paused postcopy migration.
-
-The recovery phase normally contains a few steps:
-
- - When network issue occurs, both QEMU will go into PAUSED state
-
- - When the network is recovered (or a new network is provided), the admin
- can setup the new channel for migration using QMP command
- 'migrate-recover' on destination node, preparing for a resume.
-
- - On source host, the admin can continue the interrupted postcopy
- migration using QMP command 'migrate' with resume=true flag set.
-
- - After the connection is re-established, QEMU will continue the postcopy
- migration on both sides.
-
-During a paused postcopy migration, the VM can logically still continue
-running, and it will not be impacted from any page access to pages that
-were already migrated to destination VM before the interruption happens.
-However, if any of the missing pages got accessed on destination VM, the VM
-thread will be halted waiting for the page to be migrated, it means it can
-be halted until the recovery is complete.
-
-The impact of accessing missing pages can be relevant to different
-configurations of the guest. For example, when with async page fault
-enabled, logically the guest can proactively schedule out the threads
-accessing missing pages.
-
-Postcopy states
----------------
-
-Postcopy moves through a series of states (see postcopy_state) from
-ADVISE->DISCARD->LISTEN->RUNNING->END
-
- - Advise
-
- Set at the start of migration if postcopy is enabled, even
- if it hasn't had the start command; here the destination
- checks that its OS has the support needed for postcopy, and performs
- setup to ensure the RAM mappings are suitable for later postcopy.
- The destination will fail early in migration at this point if the
- required OS support is not present.
- (Triggered by reception of POSTCOPY_ADVISE command)
-
- - Discard
-
- Entered on receipt of the first 'discard' command; prior to
- the first Discard being performed, hugepages are switched off
- (using madvise) to ensure that no new huge pages are created
- during the postcopy phase, and to cause any huge pages that
- have discards on them to be broken.
-
- - Listen
-
- The first command in the package, POSTCOPY_LISTEN, switches
- the destination state to Listen, and starts a new thread
- (the 'listen thread') which takes over the job of receiving
- pages off the migration stream, while the main thread carries
- on processing the blob. With this thread able to process page
- reception, the destination now 'sensitises' the RAM to detect
- any access to missing pages (on Linux using the 'userfault'
- system).
-
- - Running
-
- POSTCOPY_RUN causes the destination to synchronise all
- state and start the CPUs and IO devices running. The main
- thread now finishes processing the migration package and
- now carries on as it would for normal precopy migration
- (although it can't do the cleanup it would do as it
- finishes a normal migration).
-
- - Paused
-
- Postcopy can run into a paused state (normally on both sides when
- happens), where all threads will be temporarily halted mostly due to
- network errors. When reaching paused state, migration will make sure
- the qemu binary on both sides maintain the data without corrupting
- the VM. To continue the migration, the admin needs to fix the
- migration channel using the QMP command 'migrate-recover' on the
- destination node, then resume the migration using QMP command 'migrate'
- again on source node, with resume=true flag set.
-
- - End
-
- The listen thread can now quit, and perform the cleanup of migration
- state, the migration is now complete.
-
-Source side page map
---------------------
-
-The 'migration bitmap' in postcopy is basically the same as in the precopy,
-where each of the bit to indicate that page is 'dirty' - i.e. needs
-sending. During the precopy phase this is updated as the CPU dirties
-pages, however during postcopy the CPUs are stopped and nothing should
-dirty anything any more. Instead, dirty bits are cleared when the relevant
-pages are sent during postcopy.
-
-Postcopy with hugepages
------------------------
-
-Postcopy now works with hugetlbfs backed memory:
-
- a) The linux kernel on the destination must support userfault on hugepages.
- b) The huge-page configuration on the source and destination VMs must be
- identical; i.e. RAMBlocks on both sides must use the same page size.
- c) Note that ``-mem-path /dev/hugepages`` will fall back to allocating normal
- RAM if it doesn't have enough hugepages, triggering (b) to fail.
- Using ``-mem-prealloc`` enforces the allocation using hugepages.
- d) Care should be taken with the size of hugepage used; postcopy with 2MB
- hugepages works well, however 1GB hugepages are likely to be problematic
- since it takes ~1 second to transfer a 1GB hugepage across a 10Gbps link,
- and until the full page is transferred the destination thread is blocked.
-
-Postcopy with shared memory
----------------------------
-
-Postcopy migration with shared memory needs explicit support from the other
-processes that share memory and from QEMU. There are restrictions on the type of
-memory that userfault can support shared.
-
-The Linux kernel userfault support works on ``/dev/shm`` memory and on ``hugetlbfs``
-(although the kernel doesn't provide an equivalent to ``madvise(MADV_DONTNEED)``
-for hugetlbfs which may be a problem in some configurations).
-
-The vhost-user code in QEMU supports clients that have Postcopy support,
-and the ``vhost-user-bridge`` (in ``tests/``) and the DPDK package have changes
-to support postcopy.
-
-The client needs to open a userfaultfd and register the areas
-of memory that it maps with userfault. The client must then pass the
-userfaultfd back to QEMU together with a mapping table that allows
-fault addresses in the clients address space to be converted back to
-RAMBlock/offsets. The client's userfaultfd is added to the postcopy
-fault-thread and page requests are made on behalf of the client by QEMU.
-QEMU performs 'wake' operations on the client's userfaultfd to allow it
-to continue after a page has arrived.
-
-.. note::
- There are two future improvements that would be nice:
- a) Some way to make QEMU ignorant of the addresses in the clients
- address space
- b) Avoiding the need for QEMU to perform ufd-wake calls after the
- pages have arrived
-
-Retro-fitting postcopy to existing clients is possible:
- a) A mechanism is needed for the registration with userfault as above,
- and the registration needs to be coordinated with the phases of
- postcopy. In vhost-user extra messages are added to the existing
- control channel.
- b) Any thread that can block due to guest memory accesses must be
- identified and the implication understood; for example if the
- guest memory access is made while holding a lock then all other
- threads waiting for that lock will also be blocked.
-
-Postcopy Preemption Mode
-------------------------
-
-Postcopy preempt is a new capability introduced in 8.0 QEMU release, it
-allows urgent pages (those got page fault requested from destination QEMU
-explicitly) to be sent in a separate preempt channel, rather than queued in
-the background migration channel. Anyone who cares about latencies of page
-faults during a postcopy migration should enable this feature. By default,
-it's not enabled.
-
-Firmware
-========
-
-Migration migrates the copies of RAM and ROM, and thus when running
-on the destination it includes the firmware from the source. Even after
-resetting a VM, the old firmware is used. Only once QEMU has been restarted
-is the new firmware in use.
-
-- Changes in firmware size can cause changes in the required RAMBlock size
- to hold the firmware and thus migration can fail. In practice it's best
- to pad firmware images to convenient powers of 2 with plenty of space
- for growth.
-
-- Care should be taken with device emulation code so that newer
- emulation code can work with older firmware to allow forward migration.
-
-- Care should be taken with newer firmware so that backward migration
- to older systems with older device emulation code will work.
-
-In some cases it may be best to tie specific firmware versions to specific
-versioned machine types to cut down on the combinations that will need
-support. This is also useful when newer versions of firmware outgrow
-the padding.
-
-
-Backwards compatibility
-=======================
-
-How backwards compatibility works
----------------------------------
-
-When we do migration, we have two QEMU processes: the source and the
-target. There are two cases, they are the same version or they are
-different versions. The easy case is when they are the same version.
-The difficult one is when they are different versions.
-
-There are two things that are different, but they have very similar
-names and sometimes get confused:
-
-- QEMU version
-- machine type version
-
-Let's start with a practical example, we start with:
-
-- qemu-system-x86_64 (v5.2), from now on qemu-5.2.
-- qemu-system-x86_64 (v5.1), from now on qemu-5.1.
-
-Related to this are the "latest" machine types defined on each of
-them:
-
-- pc-q35-5.2 (newer one in qemu-5.2) from now on pc-5.2
-- pc-q35-5.1 (newer one in qemu-5.1) from now on pc-5.1
-
-First of all, migration is only supposed to work if you use the same
-machine type in both source and destination. The QEMU hardware
-configuration needs to be the same also on source and destination.
-Most aspects of the backend configuration can be changed at will,
-except for a few cases where the backend features influence frontend
-device feature exposure. But that is not relevant for this section.
-
-I am going to list the number of combinations that we can have. Let's
-start with the trivial ones, QEMU is the same on source and
-destination:
-
-1 - qemu-5.2 -M pc-5.2 -> migrates to -> qemu-5.2 -M pc-5.2
-
- This is the latest QEMU with the latest machine type.
- This have to work, and if it doesn't work it is a bug.
-
-2 - qemu-5.1 -M pc-5.1 -> migrates to -> qemu-5.1 -M pc-5.1
-
- Exactly the same case than the previous one, but for 5.1.
- Nothing to see here either.
-
-This are the easiest ones, we will not talk more about them in this
-section.
-
-Now we start with the more interesting cases. Consider the case where
-we have the same QEMU version in both sides (qemu-5.2) but we are using
-the latest machine type for that version (pc-5.2) but one of an older
-QEMU version, in this case pc-5.1.
-
-3 - qemu-5.2 -M pc-5.1 -> migrates to -> qemu-5.2 -M pc-5.1
-
- It needs to use the definition of pc-5.1 and the devices as they
- were configured on 5.1, but this should be easy in the sense that
- both sides are the same QEMU and both sides have exactly the same
- idea of what the pc-5.1 machine is.
-
-4 - qemu-5.1 -M pc-5.2 -> migrates to -> qemu-5.1 -M pc-5.2
-
- This combination is not possible as the qemu-5.1 doesn't understand
- pc-5.2 machine type. So nothing to worry here.
-
-Now it comes the interesting ones, when both QEMU processes are
-different. Notice also that the machine type needs to be pc-5.1,
-because we have the limitation than qemu-5.1 doesn't know pc-5.2. So
-the possible cases are:
-
-5 - qemu-5.2 -M pc-5.1 -> migrates to -> qemu-5.1 -M pc-5.1
-
- This migration is known as newer to older. We need to make sure
- when we are developing 5.2 we need to take care about not to break
- migration to qemu-5.1. Notice that we can't make updates to
- qemu-5.1 to understand whatever qemu-5.2 decides to change, so it is
- in qemu-5.2 side to make the relevant changes.
-
-6 - qemu-5.1 -M pc-5.1 -> migrates to -> qemu-5.2 -M pc-5.1
-
- This migration is known as older to newer. We need to make sure
- than we are able to receive migrations from qemu-5.1. The problem is
- similar to the previous one.
-
-If qemu-5.1 and qemu-5.2 were the same, there will not be any
-compatibility problems. But the reason that we create qemu-5.2 is to
-get new features, devices, defaults, etc.
-
-If we get a device that has a new feature, or change a default value,
-we have a problem when we try to migrate between different QEMU
-versions.
-
-So we need a way to tell qemu-5.2 that when we are using machine type
-pc-5.1, it needs to **not** use the feature, to be able to migrate to
-real qemu-5.1.
-
-And the equivalent part when migrating from qemu-5.1 to qemu-5.2.
-qemu-5.2 has to expect that it is not going to get data for the new
-feature, because qemu-5.1 doesn't know about it.
-
-How do we tell QEMU about these device feature changes? In
-hw/core/machine.c:hw_compat_X_Y arrays.
-
-If we change a default value, we need to put back the old value on
-that array. And the device, during initialization needs to look at
-that array to see what value it needs to get for that feature. And
-what are we going to put in that array, the value of a property.
-
-To create a property for a device, we need to use one of the
-DEFINE_PROP_*() macros. See include/hw/qdev-properties.h to find the
-macros that exist. With it, we set the default value for that
-property, and that is what it is going to get in the latest released
-version. But if we want a different value for a previous version, we
-can change that in the hw_compat_X_Y arrays.
-
-hw_compat_X_Y is an array of registers that have the format:
-
-- name_device
-- name_property
-- value
-
-Let's see a practical example.
-
-In qemu-5.2 virtio-blk-device got multi queue support. This is a
-change that is not backward compatible. In qemu-5.1 it has one
-queue. In qemu-5.2 it has the same number of queues as the number of
-cpus in the system.
-
-When we are doing migration, if we migrate from a device that has 4
-queues to a device that have only one queue, we don't know where to
-put the extra information for the other 3 queues, and we fail
-migration.
-
-Similar problem when we migrate from qemu-5.1 that has only one queue
-to qemu-5.2, we only sent information for one queue, but destination
-has 4, and we have 3 queues that are not properly initialized and
-anything can happen.
-
-So, how can we address this problem. Easy, just convince qemu-5.2
-that when it is running pc-5.1, it needs to set the number of queues
-for virtio-blk-devices to 1.
-
-That way we fix the cases 5 and 6.
-
-5 - qemu-5.2 -M pc-5.1 -> migrates to -> qemu-5.1 -M pc-5.1
-
- qemu-5.2 -M pc-5.1 sets number of queues to be 1.
- qemu-5.1 -M pc-5.1 expects number of queues to be 1.
-
- correct. migration works.
-
-6 - qemu-5.1 -M pc-5.1 -> migrates to -> qemu-5.2 -M pc-5.1
-
- qemu-5.1 -M pc-5.1 sets number of queues to be 1.
- qemu-5.2 -M pc-5.1 expects number of queues to be 1.
-
- correct. migration works.
-
-And now the other interesting case, case 3. In this case we have:
-
-3 - qemu-5.2 -M pc-5.1 -> migrates to -> qemu-5.2 -M pc-5.1
-
- Here we have the same QEMU in both sides. So it doesn't matter a
- lot if we have set the number of queues to 1 or not, because
- they are the same.
-
- WRONG!
-
- Think what happens if we do one of this double migrations:
-
- A -> migrates -> B -> migrates -> C
-
- where:
-
- A: qemu-5.1 -M pc-5.1
- B: qemu-5.2 -M pc-5.1
- C: qemu-5.2 -M pc-5.1
-
- migration A -> B is case 6, so number of queues needs to be 1.
-
- migration B -> C is case 3, so we don't care. But actually we
- care because we haven't started the guest in qemu-5.2, it came
- migrated from qemu-5.1. So to be in the safe place, we need to
- always use number of queues 1 when we are using pc-5.1.
-
-Now, how was this done in reality? The following commit shows how it
-was done::
-
- commit 9445e1e15e66c19e42bea942ba810db28052cd05
- Author: Stefan Hajnoczi <stefanha@redhat.com>
- Date: Tue Aug 18 15:33:47 2020 +0100
-
- virtio-blk-pci: default num_queues to -smp N
-
-The relevant parts for migration are::
-
- @@ -1281,7 +1284,8 @@ static Property virtio_blk_properties[] = {
- #endif
- DEFINE_PROP_BIT("request-merging", VirtIOBlock, conf.request_merging, 0,
- true),
- - DEFINE_PROP_UINT16("num-queues", VirtIOBlock, conf.num_queues, 1),
- + DEFINE_PROP_UINT16("num-queues", VirtIOBlock, conf.num_queues,
- + VIRTIO_BLK_AUTO_NUM_QUEUES),
- DEFINE_PROP_UINT16("queue-size", VirtIOBlock, conf.queue_size, 256),
-
-It changes the default value of num_queues. But it fishes it for old
-machine types to have the right value::
-
- @@ -31,6 +31,7 @@
- GlobalProperty hw_compat_5_1[] = {
- ...
- + { "virtio-blk-device", "num-queues", "1"},
- ...
- };
-
-A device with different features on both sides
-----------------------------------------------
-
-Let's assume that we are using the same QEMU binary on both sides,
-just to make the things easier. But we have a device that has
-different features on both sides of the migration. That can be
-because the devices are different, because the kernel driver of both
-devices have different features, whatever.
-
-How can we get this to work with migration. The way to do that is
-"theoretically" easy. You have to get the features that the device
-has in the source of the migration. The features that the device has
-on the target of the migration, you get the intersection of the
-features of both sides, and that is the way that you should launch
-QEMU.
-
-Notice that this is not completely related to QEMU. The most
-important thing here is that this should be handled by the managing
-application that launches QEMU. If QEMU is configured correctly, the
-migration will succeed.
-
-That said, actually doing it is complicated. Almost all devices are
-bad at being able to be launched with only some features enabled.
-With one big exception: cpus.
-
-You can read the documentation for QEMU x86 cpu models here:
-
-https://qemu-project.gitlab.io/qemu/system/qemu-cpu-models.html
-
-See when they talk about migration they recommend that one chooses the
-newest cpu model that is supported for all cpus.
-
-Let's say that we have:
-
-Host A:
-
-Device X has the feature Y
-
-Host B:
-
-Device X has not the feature Y
-
-If we try to migrate without any care from host A to host B, it will
-fail because when migration tries to load the feature Y on
-destination, it will find that the hardware is not there.
-
-Doing this would be the equivalent of doing with cpus:
-
-Host A:
-
-$ qemu-system-x86_64 -cpu host
-
-Host B:
-
-$ qemu-system-x86_64 -cpu host
-
-When both hosts have different cpu features this is guaranteed to
-fail. Especially if Host B has less features than host A. If host A
-has less features than host B, sometimes it works. Important word of
-last sentence is "sometimes".
-
-So, forgetting about cpu models and continuing with the -cpu host
-example, let's see that the differences of the cpus is that Host A and
-B have the following features:
-
-Features: 'pcid' 'stibp' 'taa-no'
-Host A: X X
-Host B: X
-
-And we want to migrate between them, the way configure both QEMU cpu
-will be:
-
-Host A:
-
-$ qemu-system-x86_64 -cpu host,pcid=off,stibp=off
-
-Host B:
-
-$ qemu-system-x86_64 -cpu host,taa-no=off
-
-And you would be able to migrate between them. It is responsibility
-of the management application or of the user to make sure that the
-configuration is correct. QEMU doesn't know how to look at this kind
-of features in general.
-
-Notice that we don't recommend to use -cpu host for migration. It is
-used in this example because it makes the example simpler.
-
-Other devices have worse control about individual features. If they
-want to be able to migrate between hosts that show different features,
-the device needs a way to configure which ones it is going to use.
-
-In this section we have considered that we are using the same QEMU
-binary in both sides of the migration. If we use different QEMU
-versions process, then we need to have into account all other
-differences and the examples become even more complicated.
-
-How to mitigate when we have a backward compatibility error
------------------------------------------------------------
-
-We broke migration for old machine types continuously during
-development. But as soon as we find that there is a problem, we fix
-it. The problem is what happens when we detect after we have done a
-release that something has gone wrong.
-
-Let see how it worked with one example.
-
-After the release of qemu-8.0 we found a problem when doing migration
-of the machine type pc-7.2.
-
-- $ qemu-7.2 -M pc-7.2 -> qemu-7.2 -M pc-7.2
-
- This migration works
-
-- $ qemu-8.0 -M pc-7.2 -> qemu-8.0 -M pc-7.2
-
- This migration works
-
-- $ qemu-8.0 -M pc-7.2 -> qemu-7.2 -M pc-7.2
-
- This migration fails
-
-- $ qemu-7.2 -M pc-7.2 -> qemu-8.0 -M pc-7.2
-
- This migration fails
-
-So clearly something fails when migration between qemu-7.2 and
-qemu-8.0 with machine type pc-7.2. The error messages, and git bisect
-pointed to this commit.
-
-In qemu-8.0 we got this commit::
-
- commit 010746ae1db7f52700cb2e2c46eb94f299cfa0d2
- Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
- Date: Thu Mar 2 13:37:02 2023 +0000
-
- hw/pci/aer: Implement PCI_ERR_UNCOR_MASK register
-
-
-The relevant bits of the commit for our example are this ones::
-
- --- a/hw/pci/pcie_aer.c
- +++ b/hw/pci/pcie_aer.c
- @@ -112,6 +112,10 @@ int pcie_aer_init(PCIDevice *dev,
-
- pci_set_long(dev->w1cmask + offset + PCI_ERR_UNCOR_STATUS,
- PCI_ERR_UNC_SUPPORTED);
- + pci_set_long(dev->config + offset + PCI_ERR_UNCOR_MASK,
- + PCI_ERR_UNC_MASK_DEFAULT);
- + pci_set_long(dev->wmask + offset + PCI_ERR_UNCOR_MASK,
- + PCI_ERR_UNC_SUPPORTED);
-
- pci_set_long(dev->config + offset + PCI_ERR_UNCOR_SEVER,
- PCI_ERR_UNC_SEVERITY_DEFAULT);
-
-The patch changes how we configure PCI space for AER. But QEMU fails
-when the PCI space configuration is different between source and
-destination.
-
-The following commit shows how this got fixed::
-
- commit 5ed3dabe57dd9f4c007404345e5f5bf0e347317f
- Author: Leonardo Bras <leobras@redhat.com>
- Date: Tue May 2 21:27:02 2023 -0300
-
- hw/pci: Disable PCI_ERR_UNCOR_MASK register for machine type < 8.0
-
- [...]
-
-The relevant parts of the fix in QEMU are as follow:
-
-First, we create a new property for the device to be able to configure
-the old behaviour or the new behaviour::
-
- diff --git a/hw/pci/pci.c b/hw/pci/pci.c
- index 8a87ccc8b0..5153ad63d6 100644
- --- a/hw/pci/pci.c
- +++ b/hw/pci/pci.c
- @@ -79,6 +79,8 @@ static Property pci_props[] = {
- DEFINE_PROP_STRING("failover_pair_id", PCIDevice,
- failover_pair_id),
- DEFINE_PROP_UINT32("acpi-index", PCIDevice, acpi_index, 0),
- + DEFINE_PROP_BIT("x-pcie-err-unc-mask", PCIDevice, cap_present,
- + QEMU_PCIE_ERR_UNC_MASK_BITNR, true),
- DEFINE_PROP_END_OF_LIST()
- };
-
-Notice that we enable the feature for new machine types.
-
-Now we see how the fix is done. This is going to depend on what kind
-of breakage happens, but in this case it is quite simple::
-
- diff --git a/hw/pci/pcie_aer.c b/hw/pci/pcie_aer.c
- index 103667c368..374d593ead 100644
- --- a/hw/pci/pcie_aer.c
- +++ b/hw/pci/pcie_aer.c
- @@ -112,10 +112,13 @@ int pcie_aer_init(PCIDevice *dev, uint8_t cap_ver,
- uint16_t offset,
-
- pci_set_long(dev->w1cmask + offset + PCI_ERR_UNCOR_STATUS,
- PCI_ERR_UNC_SUPPORTED);
- - pci_set_long(dev->config + offset + PCI_ERR_UNCOR_MASK,
- - PCI_ERR_UNC_MASK_DEFAULT);
- - pci_set_long(dev->wmask + offset + PCI_ERR_UNCOR_MASK,
- - PCI_ERR_UNC_SUPPORTED);
- +
- + if (dev->cap_present & QEMU_PCIE_ERR_UNC_MASK) {
- + pci_set_long(dev->config + offset + PCI_ERR_UNCOR_MASK,
- + PCI_ERR_UNC_MASK_DEFAULT);
- + pci_set_long(dev->wmask + offset + PCI_ERR_UNCOR_MASK,
- + PCI_ERR_UNC_SUPPORTED);
- + }
-
- pci_set_long(dev->config + offset + PCI_ERR_UNCOR_SEVER,
- PCI_ERR_UNC_SEVERITY_DEFAULT);
-
-I.e. If the property bit is enabled, we configure it as we did for
-qemu-8.0. If the property bit is not set, we configure it as it was in 7.2.
-
-And now, everything that is missing is disabling the feature for old
-machine types::
-
- diff --git a/hw/core/machine.c b/hw/core/machine.c
- index 47a34841a5..07f763eb2e 100644
- --- a/hw/core/machine.c
- +++ b/hw/core/machine.c
- @@ -48,6 +48,7 @@ GlobalProperty hw_compat_7_2[] = {
- { "e1000e", "migrate-timadj", "off" },
- { "virtio-mem", "x-early-migration", "false" },
- { "migration", "x-preempt-pre-7-2", "true" },
- + { TYPE_PCI_DEVICE, "x-pcie-err-unc-mask", "off" },
- };
- const size_t hw_compat_7_2_len = G_N_ELEMENTS(hw_compat_7_2);
-
-And now, when qemu-8.0.1 is released with this fix, all combinations
-are going to work as supposed.
-
-- $ qemu-7.2 -M pc-7.2 -> qemu-7.2 -M pc-7.2 (works)
-- $ qemu-8.0.1 -M pc-7.2 -> qemu-8.0.1 -M pc-7.2 (works)
-- $ qemu-8.0.1 -M pc-7.2 -> qemu-7.2 -M pc-7.2 (works)
-- $ qemu-7.2 -M pc-7.2 -> qemu-8.0.1 -M pc-7.2 (works)
-
-So the normality has been restored and everything is ok, no?
-
-Not really, now our matrix is much bigger. We started with the easy
-cases, migration from the same version to the same version always
-works:
-
-- $ qemu-7.2 -M pc-7.2 -> qemu-7.2 -M pc-7.2
-- $ qemu-8.0 -M pc-7.2 -> qemu-8.0 -M pc-7.2
-- $ qemu-8.0.1 -M pc-7.2 -> qemu-8.0.1 -M pc-7.2
-
-Now the interesting ones. When the QEMU processes versions are
-different. For the 1st set, their fail and we can do nothing, both
-versions are released and we can't change anything.
-
-- $ qemu-7.2 -M pc-7.2 -> qemu-8.0 -M pc-7.2
-- $ qemu-8.0 -M pc-7.2 -> qemu-7.2 -M pc-7.2
-
-This two are the ones that work. The whole point of making the
-change in qemu-8.0.1 release was to fix this issue:
-
-- $ qemu-7.2 -M pc-7.2 -> qemu-8.0.1 -M pc-7.2
-- $ qemu-8.0.1 -M pc-7.2 -> qemu-7.2 -M pc-7.2
-
-But now we found that qemu-8.0 neither can migrate to qemu-7.2 not
-qemu-8.0.1.
-
-- $ qemu-8.0 -M pc-7.2 -> qemu-8.0.1 -M pc-7.2
-- $ qemu-8.0.1 -M pc-7.2 -> qemu-8.0 -M pc-7.2
-
-So, if we start a pc-7.2 machine in qemu-8.0 we can't migrate it to
-anything except to qemu-8.0.
-
-Can we do better?
-
-Yeap. If we know that we are going to do this migration:
-
-- $ qemu-8.0 -M pc-7.2 -> qemu-8.0.1 -M pc-7.2
-
-We can launch the appropriate devices with::
-
- --device...,x-pci-e-err-unc-mask=on
-
-And now we can receive a migration from 8.0. And from now on, we can
-do that migration to new machine types if we remember to enable that
-property for pc-7.2. Notice that we need to remember, it is not
-enough to know that the source of the migration is qemu-8.0. Think of
-this example:
-
-$ qemu-8.0 -M pc-7.2 -> qemu-8.0.1 -M pc-7.2 -> qemu-8.2 -M pc-7.2
-
-In the second migration, the source is not qemu-8.0, but we still have
-that "problem" and have that property enabled. Notice that we need to
-continue having this mark/property until we have this machine
-rebooted. But it is not a normal reboot (that don't reload QEMU) we
-need the machine to poweroff/poweron on a fixed QEMU. And from now
-on we can use the proper real machine.
--- /dev/null
+==============
+Best practices
+==============
+
+Debugging
+=========
+
+The migration stream can be analyzed thanks to ``scripts/analyze-migration.py``.
+
+Example usage:
+
+.. code-block:: shell
+
+ $ qemu-system-x86_64 -display none -monitor stdio
+ (qemu) migrate "exec:cat > mig"
+ (qemu) q
+ $ ./scripts/analyze-migration.py -f mig
+ {
+ "ram (3)": {
+ "section sizes": {
+ "pc.ram": "0x0000000008000000",
+ ...
+
+See also ``analyze-migration.py -h`` help for more options.
+
+Firmware
+========
+
+Migration migrates the copies of RAM and ROM, and thus when running
+on the destination it includes the firmware from the source. Even after
+resetting a VM, the old firmware is used. Only once QEMU has been restarted
+is the new firmware in use.
+
+- Changes in firmware size can cause changes in the required RAMBlock size
+ to hold the firmware and thus migration can fail. In practice it's best
+ to pad firmware images to convenient powers of 2 with plenty of space
+ for growth.
+
+- Care should be taken with device emulation code so that newer
+ emulation code can work with older firmware to allow forward migration.
+
+- Care should be taken with newer firmware so that backward migration
+ to older systems with older device emulation code will work.
+
+In some cases it may be best to tie specific firmware versions to specific
+versioned machine types to cut down on the combinations that will need
+support. This is also useful when newer versions of firmware outgrow
+the padding.
--- /dev/null
+Backwards compatibility
+=======================
+
+How backwards compatibility works
+---------------------------------
+
+When we do migration, we have two QEMU processes: the source and the
+target. There are two cases, they are the same version or they are
+different versions. The easy case is when they are the same version.
+The difficult one is when they are different versions.
+
+There are two things that are different, but they have very similar
+names and sometimes get confused:
+
+- QEMU version
+- machine type version
+
+Let's start with a practical example, we start with:
+
+- qemu-system-x86_64 (v5.2), from now on qemu-5.2.
+- qemu-system-x86_64 (v5.1), from now on qemu-5.1.
+
+Related to this are the "latest" machine types defined on each of
+them:
+
+- pc-q35-5.2 (newer one in qemu-5.2) from now on pc-5.2
+- pc-q35-5.1 (newer one in qemu-5.1) from now on pc-5.1
+
+First of all, migration is only supposed to work if you use the same
+machine type in both source and destination. The QEMU hardware
+configuration needs to be the same also on source and destination.
+Most aspects of the backend configuration can be changed at will,
+except for a few cases where the backend features influence frontend
+device feature exposure. But that is not relevant for this section.
+
+I am going to list the number of combinations that we can have. Let's
+start with the trivial ones, QEMU is the same on source and
+destination:
+
+1 - qemu-5.2 -M pc-5.2 -> migrates to -> qemu-5.2 -M pc-5.2
+
+ This is the latest QEMU with the latest machine type.
+ This have to work, and if it doesn't work it is a bug.
+
+2 - qemu-5.1 -M pc-5.1 -> migrates to -> qemu-5.1 -M pc-5.1
+
+ Exactly the same case than the previous one, but for 5.1.
+ Nothing to see here either.
+
+This are the easiest ones, we will not talk more about them in this
+section.
+
+Now we start with the more interesting cases. Consider the case where
+we have the same QEMU version in both sides (qemu-5.2) but we are using
+the latest machine type for that version (pc-5.2) but one of an older
+QEMU version, in this case pc-5.1.
+
+3 - qemu-5.2 -M pc-5.1 -> migrates to -> qemu-5.2 -M pc-5.1
+
+ It needs to use the definition of pc-5.1 and the devices as they
+ were configured on 5.1, but this should be easy in the sense that
+ both sides are the same QEMU and both sides have exactly the same
+ idea of what the pc-5.1 machine is.
+
+4 - qemu-5.1 -M pc-5.2 -> migrates to -> qemu-5.1 -M pc-5.2
+
+ This combination is not possible as the qemu-5.1 doesn't understand
+ pc-5.2 machine type. So nothing to worry here.
+
+Now it comes the interesting ones, when both QEMU processes are
+different. Notice also that the machine type needs to be pc-5.1,
+because we have the limitation than qemu-5.1 doesn't know pc-5.2. So
+the possible cases are:
+
+5 - qemu-5.2 -M pc-5.1 -> migrates to -> qemu-5.1 -M pc-5.1
+
+ This migration is known as newer to older. We need to make sure
+ when we are developing 5.2 we need to take care about not to break
+ migration to qemu-5.1. Notice that we can't make updates to
+ qemu-5.1 to understand whatever qemu-5.2 decides to change, so it is
+ in qemu-5.2 side to make the relevant changes.
+
+6 - qemu-5.1 -M pc-5.1 -> migrates to -> qemu-5.2 -M pc-5.1
+
+ This migration is known as older to newer. We need to make sure
+ than we are able to receive migrations from qemu-5.1. The problem is
+ similar to the previous one.
+
+If qemu-5.1 and qemu-5.2 were the same, there will not be any
+compatibility problems. But the reason that we create qemu-5.2 is to
+get new features, devices, defaults, etc.
+
+If we get a device that has a new feature, or change a default value,
+we have a problem when we try to migrate between different QEMU
+versions.
+
+So we need a way to tell qemu-5.2 that when we are using machine type
+pc-5.1, it needs to **not** use the feature, to be able to migrate to
+real qemu-5.1.
+
+And the equivalent part when migrating from qemu-5.1 to qemu-5.2.
+qemu-5.2 has to expect that it is not going to get data for the new
+feature, because qemu-5.1 doesn't know about it.
+
+How do we tell QEMU about these device feature changes? In
+hw/core/machine.c:hw_compat_X_Y arrays.
+
+If we change a default value, we need to put back the old value on
+that array. And the device, during initialization needs to look at
+that array to see what value it needs to get for that feature. And
+what are we going to put in that array, the value of a property.
+
+To create a property for a device, we need to use one of the
+DEFINE_PROP_*() macros. See include/hw/qdev-properties.h to find the
+macros that exist. With it, we set the default value for that
+property, and that is what it is going to get in the latest released
+version. But if we want a different value for a previous version, we
+can change that in the hw_compat_X_Y arrays.
+
+hw_compat_X_Y is an array of registers that have the format:
+
+- name_device
+- name_property
+- value
+
+Let's see a practical example.
+
+In qemu-5.2 virtio-blk-device got multi queue support. This is a
+change that is not backward compatible. In qemu-5.1 it has one
+queue. In qemu-5.2 it has the same number of queues as the number of
+cpus in the system.
+
+When we are doing migration, if we migrate from a device that has 4
+queues to a device that have only one queue, we don't know where to
+put the extra information for the other 3 queues, and we fail
+migration.
+
+Similar problem when we migrate from qemu-5.1 that has only one queue
+to qemu-5.2, we only sent information for one queue, but destination
+has 4, and we have 3 queues that are not properly initialized and
+anything can happen.
+
+So, how can we address this problem. Easy, just convince qemu-5.2
+that when it is running pc-5.1, it needs to set the number of queues
+for virtio-blk-devices to 1.
+
+That way we fix the cases 5 and 6.
+
+5 - qemu-5.2 -M pc-5.1 -> migrates to -> qemu-5.1 -M pc-5.1
+
+ qemu-5.2 -M pc-5.1 sets number of queues to be 1.
+ qemu-5.1 -M pc-5.1 expects number of queues to be 1.
+
+ correct. migration works.
+
+6 - qemu-5.1 -M pc-5.1 -> migrates to -> qemu-5.2 -M pc-5.1
+
+ qemu-5.1 -M pc-5.1 sets number of queues to be 1.
+ qemu-5.2 -M pc-5.1 expects number of queues to be 1.
+
+ correct. migration works.
+
+And now the other interesting case, case 3. In this case we have:
+
+3 - qemu-5.2 -M pc-5.1 -> migrates to -> qemu-5.2 -M pc-5.1
+
+ Here we have the same QEMU in both sides. So it doesn't matter a
+ lot if we have set the number of queues to 1 or not, because
+ they are the same.
+
+ WRONG!
+
+ Think what happens if we do one of this double migrations:
+
+ A -> migrates -> B -> migrates -> C
+
+ where:
+
+ A: qemu-5.1 -M pc-5.1
+ B: qemu-5.2 -M pc-5.1
+ C: qemu-5.2 -M pc-5.1
+
+ migration A -> B is case 6, so number of queues needs to be 1.
+
+ migration B -> C is case 3, so we don't care. But actually we
+ care because we haven't started the guest in qemu-5.2, it came
+ migrated from qemu-5.1. So to be in the safe place, we need to
+ always use number of queues 1 when we are using pc-5.1.
+
+Now, how was this done in reality? The following commit shows how it
+was done::
+
+ commit 9445e1e15e66c19e42bea942ba810db28052cd05
+ Author: Stefan Hajnoczi <stefanha@redhat.com>
+ Date: Tue Aug 18 15:33:47 2020 +0100
+
+ virtio-blk-pci: default num_queues to -smp N
+
+The relevant parts for migration are::
+
+ @@ -1281,7 +1284,8 @@ static Property virtio_blk_properties[] = {
+ #endif
+ DEFINE_PROP_BIT("request-merging", VirtIOBlock, conf.request_merging, 0,
+ true),
+ - DEFINE_PROP_UINT16("num-queues", VirtIOBlock, conf.num_queues, 1),
+ + DEFINE_PROP_UINT16("num-queues", VirtIOBlock, conf.num_queues,
+ + VIRTIO_BLK_AUTO_NUM_QUEUES),
+ DEFINE_PROP_UINT16("queue-size", VirtIOBlock, conf.queue_size, 256),
+
+It changes the default value of num_queues. But it fishes it for old
+machine types to have the right value::
+
+ @@ -31,6 +31,7 @@
+ GlobalProperty hw_compat_5_1[] = {
+ ...
+ + { "virtio-blk-device", "num-queues", "1"},
+ ...
+ };
+
+A device with different features on both sides
+----------------------------------------------
+
+Let's assume that we are using the same QEMU binary on both sides,
+just to make the things easier. But we have a device that has
+different features on both sides of the migration. That can be
+because the devices are different, because the kernel driver of both
+devices have different features, whatever.
+
+How can we get this to work with migration. The way to do that is
+"theoretically" easy. You have to get the features that the device
+has in the source of the migration. The features that the device has
+on the target of the migration, you get the intersection of the
+features of both sides, and that is the way that you should launch
+QEMU.
+
+Notice that this is not completely related to QEMU. The most
+important thing here is that this should be handled by the managing
+application that launches QEMU. If QEMU is configured correctly, the
+migration will succeed.
+
+That said, actually doing it is complicated. Almost all devices are
+bad at being able to be launched with only some features enabled.
+With one big exception: cpus.
+
+You can read the documentation for QEMU x86 cpu models here:
+
+https://qemu-project.gitlab.io/qemu/system/qemu-cpu-models.html
+
+See when they talk about migration they recommend that one chooses the
+newest cpu model that is supported for all cpus.
+
+Let's say that we have:
+
+Host A:
+
+Device X has the feature Y
+
+Host B:
+
+Device X has not the feature Y
+
+If we try to migrate without any care from host A to host B, it will
+fail because when migration tries to load the feature Y on
+destination, it will find that the hardware is not there.
+
+Doing this would be the equivalent of doing with cpus:
+
+Host A:
+
+$ qemu-system-x86_64 -cpu host
+
+Host B:
+
+$ qemu-system-x86_64 -cpu host
+
+When both hosts have different cpu features this is guaranteed to
+fail. Especially if Host B has less features than host A. If host A
+has less features than host B, sometimes it works. Important word of
+last sentence is "sometimes".
+
+So, forgetting about cpu models and continuing with the -cpu host
+example, let's see that the differences of the cpus is that Host A and
+B have the following features:
+
+Features: 'pcid' 'stibp' 'taa-no'
+Host A: X X
+Host B: X
+
+And we want to migrate between them, the way configure both QEMU cpu
+will be:
+
+Host A:
+
+$ qemu-system-x86_64 -cpu host,pcid=off,stibp=off
+
+Host B:
+
+$ qemu-system-x86_64 -cpu host,taa-no=off
+
+And you would be able to migrate between them. It is responsibility
+of the management application or of the user to make sure that the
+configuration is correct. QEMU doesn't know how to look at this kind
+of features in general.
+
+Notice that we don't recommend to use -cpu host for migration. It is
+used in this example because it makes the example simpler.
+
+Other devices have worse control about individual features. If they
+want to be able to migrate between hosts that show different features,
+the device needs a way to configure which ones it is going to use.
+
+In this section we have considered that we are using the same QEMU
+binary in both sides of the migration. If we use different QEMU
+versions process, then we need to have into account all other
+differences and the examples become even more complicated.
+
+How to mitigate when we have a backward compatibility error
+-----------------------------------------------------------
+
+We broke migration for old machine types continuously during
+development. But as soon as we find that there is a problem, we fix
+it. The problem is what happens when we detect after we have done a
+release that something has gone wrong.
+
+Let see how it worked with one example.
+
+After the release of qemu-8.0 we found a problem when doing migration
+of the machine type pc-7.2.
+
+- $ qemu-7.2 -M pc-7.2 -> qemu-7.2 -M pc-7.2
+
+ This migration works
+
+- $ qemu-8.0 -M pc-7.2 -> qemu-8.0 -M pc-7.2
+
+ This migration works
+
+- $ qemu-8.0 -M pc-7.2 -> qemu-7.2 -M pc-7.2
+
+ This migration fails
+
+- $ qemu-7.2 -M pc-7.2 -> qemu-8.0 -M pc-7.2
+
+ This migration fails
+
+So clearly something fails when migration between qemu-7.2 and
+qemu-8.0 with machine type pc-7.2. The error messages, and git bisect
+pointed to this commit.
+
+In qemu-8.0 we got this commit::
+
+ commit 010746ae1db7f52700cb2e2c46eb94f299cfa0d2
+ Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+ Date: Thu Mar 2 13:37:02 2023 +0000
+
+ hw/pci/aer: Implement PCI_ERR_UNCOR_MASK register
+
+
+The relevant bits of the commit for our example are this ones::
+
+ --- a/hw/pci/pcie_aer.c
+ +++ b/hw/pci/pcie_aer.c
+ @@ -112,6 +112,10 @@ int pcie_aer_init(PCIDevice *dev,
+
+ pci_set_long(dev->w1cmask + offset + PCI_ERR_UNCOR_STATUS,
+ PCI_ERR_UNC_SUPPORTED);
+ + pci_set_long(dev->config + offset + PCI_ERR_UNCOR_MASK,
+ + PCI_ERR_UNC_MASK_DEFAULT);
+ + pci_set_long(dev->wmask + offset + PCI_ERR_UNCOR_MASK,
+ + PCI_ERR_UNC_SUPPORTED);
+
+ pci_set_long(dev->config + offset + PCI_ERR_UNCOR_SEVER,
+ PCI_ERR_UNC_SEVERITY_DEFAULT);
+
+The patch changes how we configure PCI space for AER. But QEMU fails
+when the PCI space configuration is different between source and
+destination.
+
+The following commit shows how this got fixed::
+
+ commit 5ed3dabe57dd9f4c007404345e5f5bf0e347317f
+ Author: Leonardo Bras <leobras@redhat.com>
+ Date: Tue May 2 21:27:02 2023 -0300
+
+ hw/pci: Disable PCI_ERR_UNCOR_MASK register for machine type < 8.0
+
+ [...]
+
+The relevant parts of the fix in QEMU are as follow:
+
+First, we create a new property for the device to be able to configure
+the old behaviour or the new behaviour::
+
+ diff --git a/hw/pci/pci.c b/hw/pci/pci.c
+ index 8a87ccc8b0..5153ad63d6 100644
+ --- a/hw/pci/pci.c
+ +++ b/hw/pci/pci.c
+ @@ -79,6 +79,8 @@ static Property pci_props[] = {
+ DEFINE_PROP_STRING("failover_pair_id", PCIDevice,
+ failover_pair_id),
+ DEFINE_PROP_UINT32("acpi-index", PCIDevice, acpi_index, 0),
+ + DEFINE_PROP_BIT("x-pcie-err-unc-mask", PCIDevice, cap_present,
+ + QEMU_PCIE_ERR_UNC_MASK_BITNR, true),
+ DEFINE_PROP_END_OF_LIST()
+ };
+
+Notice that we enable the feature for new machine types.
+
+Now we see how the fix is done. This is going to depend on what kind
+of breakage happens, but in this case it is quite simple::
+
+ diff --git a/hw/pci/pcie_aer.c b/hw/pci/pcie_aer.c
+ index 103667c368..374d593ead 100644
+ --- a/hw/pci/pcie_aer.c
+ +++ b/hw/pci/pcie_aer.c
+ @@ -112,10 +112,13 @@ int pcie_aer_init(PCIDevice *dev, uint8_t cap_ver,
+ uint16_t offset,
+
+ pci_set_long(dev->w1cmask + offset + PCI_ERR_UNCOR_STATUS,
+ PCI_ERR_UNC_SUPPORTED);
+ - pci_set_long(dev->config + offset + PCI_ERR_UNCOR_MASK,
+ - PCI_ERR_UNC_MASK_DEFAULT);
+ - pci_set_long(dev->wmask + offset + PCI_ERR_UNCOR_MASK,
+ - PCI_ERR_UNC_SUPPORTED);
+ +
+ + if (dev->cap_present & QEMU_PCIE_ERR_UNC_MASK) {
+ + pci_set_long(dev->config + offset + PCI_ERR_UNCOR_MASK,
+ + PCI_ERR_UNC_MASK_DEFAULT);
+ + pci_set_long(dev->wmask + offset + PCI_ERR_UNCOR_MASK,
+ + PCI_ERR_UNC_SUPPORTED);
+ + }
+
+ pci_set_long(dev->config + offset + PCI_ERR_UNCOR_SEVER,
+ PCI_ERR_UNC_SEVERITY_DEFAULT);
+
+I.e. If the property bit is enabled, we configure it as we did for
+qemu-8.0. If the property bit is not set, we configure it as it was in 7.2.
+
+And now, everything that is missing is disabling the feature for old
+machine types::
+
+ diff --git a/hw/core/machine.c b/hw/core/machine.c
+ index 47a34841a5..07f763eb2e 100644
+ --- a/hw/core/machine.c
+ +++ b/hw/core/machine.c
+ @@ -48,6 +48,7 @@ GlobalProperty hw_compat_7_2[] = {
+ { "e1000e", "migrate-timadj", "off" },
+ { "virtio-mem", "x-early-migration", "false" },
+ { "migration", "x-preempt-pre-7-2", "true" },
+ + { TYPE_PCI_DEVICE, "x-pcie-err-unc-mask", "off" },
+ };
+ const size_t hw_compat_7_2_len = G_N_ELEMENTS(hw_compat_7_2);
+
+And now, when qemu-8.0.1 is released with this fix, all combinations
+are going to work as supposed.
+
+- $ qemu-7.2 -M pc-7.2 -> qemu-7.2 -M pc-7.2 (works)
+- $ qemu-8.0.1 -M pc-7.2 -> qemu-8.0.1 -M pc-7.2 (works)
+- $ qemu-8.0.1 -M pc-7.2 -> qemu-7.2 -M pc-7.2 (works)
+- $ qemu-7.2 -M pc-7.2 -> qemu-8.0.1 -M pc-7.2 (works)
+
+So the normality has been restored and everything is ok, no?
+
+Not really, now our matrix is much bigger. We started with the easy
+cases, migration from the same version to the same version always
+works:
+
+- $ qemu-7.2 -M pc-7.2 -> qemu-7.2 -M pc-7.2
+- $ qemu-8.0 -M pc-7.2 -> qemu-8.0 -M pc-7.2
+- $ qemu-8.0.1 -M pc-7.2 -> qemu-8.0.1 -M pc-7.2
+
+Now the interesting ones. When the QEMU processes versions are
+different. For the 1st set, their fail and we can do nothing, both
+versions are released and we can't change anything.
+
+- $ qemu-7.2 -M pc-7.2 -> qemu-8.0 -M pc-7.2
+- $ qemu-8.0 -M pc-7.2 -> qemu-7.2 -M pc-7.2
+
+This two are the ones that work. The whole point of making the
+change in qemu-8.0.1 release was to fix this issue:
+
+- $ qemu-7.2 -M pc-7.2 -> qemu-8.0.1 -M pc-7.2
+- $ qemu-8.0.1 -M pc-7.2 -> qemu-7.2 -M pc-7.2
+
+But now we found that qemu-8.0 neither can migrate to qemu-7.2 not
+qemu-8.0.1.
+
+- $ qemu-8.0 -M pc-7.2 -> qemu-8.0.1 -M pc-7.2
+- $ qemu-8.0.1 -M pc-7.2 -> qemu-8.0 -M pc-7.2
+
+So, if we start a pc-7.2 machine in qemu-8.0 we can't migrate it to
+anything except to qemu-8.0.
+
+Can we do better?
+
+Yeap. If we know that we are going to do this migration:
+
+- $ qemu-8.0 -M pc-7.2 -> qemu-8.0.1 -M pc-7.2
+
+We can launch the appropriate devices with::
+
+ --device...,x-pci-e-err-unc-mask=on
+
+And now we can receive a migration from 8.0. And from now on, we can
+do that migration to new machine types if we remember to enable that
+property for pc-7.2. Notice that we need to remember, it is not
+enough to know that the source of the migration is qemu-8.0. Think of
+this example:
+
+$ qemu-8.0 -M pc-7.2 -> qemu-8.0.1 -M pc-7.2 -> qemu-8.2 -M pc-7.2
+
+In the second migration, the source is not qemu-8.0, but we still have
+that "problem" and have that property enabled. Notice that we need to
+continue having this mark/property until we have this machine
+rebooted. But it is not a normal reboot (that don't reload QEMU) we
+need the machine to poweroff/poweron on a fixed QEMU. And from now
+on we can use the proper real machine.
--- /dev/null
+Dirty limit
+===========
+
+The dirty limit, short for dirty page rate upper limit, is a new capability
+introduced in the 8.1 QEMU release that uses a new algorithm based on the KVM
+dirty ring to throttle down the guest during live migration.
+
+The algorithm framework is as follows:
+
+::
+
+ ------------------------------------------------------------------------------
+ main --------------> throttle thread ------------> PREPARE(1) <--------
+ thread \ | |
+ \ | |
+ \ V |
+ -\ CALCULATE(2) |
+ \ | |
+ \ | |
+ \ V |
+ \ SET PENALTY(3) -----
+ -\ |
+ \ |
+ \ V
+ -> virtual CPU thread -------> ACCEPT PENALTY(4)
+ ------------------------------------------------------------------------------
+
+When the qmp command qmp_set_vcpu_dirty_limit is called for the first time,
+the QEMU main thread starts the throttle thread. The throttle thread, once
+launched, executes the loop, which consists of three steps:
+
+ - PREPARE (1)
+
+ The entire work of PREPARE (1) is preparation for the second stage,
+ CALCULATE(2), as the name implies. It involves preparing the dirty
+ page rate value and the corresponding upper limit of the VM:
+ The dirty page rate is calculated via the KVM dirty ring mechanism,
+ which tells QEMU how many dirty pages a virtual CPU has had since the
+ last KVM_EXIT_DIRTY_RING_FULL exception; The dirty page rate upper
+ limit is specified by caller, therefore fetch it directly.
+
+ - CALCULATE (2)
+
+ Calculate a suitable sleep period for each virtual CPU, which will be
+ used to determine the penalty for the target virtual CPU. The
+ computation must be done carefully in order to reduce the dirty page
+ rate progressively down to the upper limit without oscillation. To
+ achieve this, two strategies are provided: the first is to add or
+ subtract sleep time based on the ratio of the current dirty page rate
+ to the limit, which is used when the current dirty page rate is far
+ from the limit; the second is to add or subtract a fixed time when
+ the current dirty page rate is close to the limit.
+
+ - SET PENALTY (3)
+
+ Set the sleep time for each virtual CPU that should be penalized based
+ on the results of the calculation supplied by step CALCULATE (2).
+
+After completing the three above stages, the throttle thread loops back
+to step PREPARE (1) until the dirty limit is reached.
+
+On the other hand, each virtual CPU thread reads the sleep duration and
+sleeps in the path of the KVM_EXIT_DIRTY_RING_FULL exception handler, that
+is ACCEPT PENALTY (4). Virtual CPUs tied with writing processes will
+obviously exit to the path and get penalized, whereas virtual CPUs involved
+with read processes will not.
+
+In summary, thanks to the KVM dirty ring technology, the dirty limit
+algorithm will restrict virtual CPUs as needed to keep their dirty page
+rate inside the limit. This leads to more steady reading performance during
+live migration and can aid in improving large guest responsiveness.
--- /dev/null
+Migration features
+==================
+
+Migration has plenty of features to support different use cases.
+
+.. toctree::
+ :maxdepth: 2
+
+ postcopy
+ dirty-limit
+ vfio
+ virtio
--- /dev/null
+Migration
+=========
+
+This is the main entry for QEMU migration documentations. It explains how
+QEMU live migration works.
+
+.. toctree::
+ :maxdepth: 2
+
+ main
+ features
+ compatibility
+ best-practices
--- /dev/null
+===================
+Migration framework
+===================
+
+QEMU has code to load/save the state of the guest that it is running.
+These are two complementary operations. Saving the state just does
+that, saves the state for each device that the guest is running.
+Restoring a guest is just the opposite operation: we need to load the
+state of each device.
+
+For this to work, QEMU has to be launched with the same arguments the
+two times. I.e. it can only restore the state in one guest that has
+the same devices that the one it was saved (this last requirement can
+be relaxed a bit, but for now we can consider that configuration has
+to be exactly the same).
+
+Once that we are able to save/restore a guest, a new functionality is
+requested: migration. This means that QEMU is able to start in one
+machine and being "migrated" to another machine. I.e. being moved to
+another machine.
+
+Next was the "live migration" functionality. This is important
+because some guests run with a lot of state (specially RAM), and it
+can take a while to move all state from one machine to another. Live
+migration allows the guest to continue running while the state is
+transferred. Only while the last part of the state is transferred has
+the guest to be stopped. Typically the time that the guest is
+unresponsive during live migration is the low hundred of milliseconds
+(notice that this depends on a lot of things).
+
+.. contents::
+
+Transports
+==========
+
+The migration stream is normally just a byte stream that can be passed
+over any transport.
+
+- tcp migration: do the migration using tcp sockets
+- unix migration: do the migration using unix sockets
+- exec migration: do the migration using the stdin/stdout through a process.
+- fd migration: do the migration using a file descriptor that is
+ passed to QEMU. QEMU doesn't care how this file descriptor is opened.
+
+In addition, support is included for migration using RDMA, which
+transports the page data using ``RDMA``, where the hardware takes care of
+transporting the pages, and the load on the CPU is much lower. While the
+internals of RDMA migration are a bit different, this isn't really visible
+outside the RAM migration code.
+
+All these migration protocols use the same infrastructure to
+save/restore state devices. This infrastructure is shared with the
+savevm/loadvm functionality.
+
+Common infrastructure
+=====================
+
+The files, sockets or fd's that carry the migration stream are abstracted by
+the ``QEMUFile`` type (see ``migration/qemu-file.h``). In most cases this
+is connected to a subtype of ``QIOChannel`` (see ``io/``).
+
+
+Saving the state of one device
+==============================
+
+For most devices, the state is saved in a single call to the migration
+infrastructure; these are *non-iterative* devices. The data for these
+devices is sent at the end of precopy migration, when the CPUs are paused.
+There are also *iterative* devices, which contain a very large amount of
+data (e.g. RAM or large tables). See the iterative device section below.
+
+General advice for device developers
+------------------------------------
+
+- The migration state saved should reflect the device being modelled rather
+ than the way your implementation works. That way if you change the implementation
+ later the migration stream will stay compatible. That model may include
+ internal state that's not directly visible in a register.
+
+- When saving a migration stream the device code may walk and check
+ the state of the device. These checks might fail in various ways (e.g.
+ discovering internal state is corrupt or that the guest has done something bad).
+ Consider carefully before asserting/aborting at this point, since the
+ normal response from users is that *migration broke their VM* since it had
+ apparently been running fine until then. In these error cases, the device
+ should log a message indicating the cause of error, and should consider
+ putting the device into an error state, allowing the rest of the VM to
+ continue execution.
+
+- The migration might happen at an inconvenient point,
+ e.g. right in the middle of the guest reprogramming the device, during
+ guest reboot or shutdown or while the device is waiting for external IO.
+ It's strongly preferred that migrations do not fail in this situation,
+ since in the cloud environment migrations might happen automatically to
+ VMs that the administrator doesn't directly control.
+
+- If you do need to fail a migration, ensure that sufficient information
+ is logged to identify what went wrong.
+
+- The destination should treat an incoming migration stream as hostile
+ (which we do to varying degrees in the existing code). Check that offsets
+ into buffers and the like can't cause overruns. Fail the incoming migration
+ in the case of a corrupted stream like this.
+
+- Take care with internal device state or behaviour that might become
+ migration version dependent. For example, the order of PCI capabilities
+ is required to stay constant across migration. Another example would
+ be that a special case handled by subsections (see below) might become
+ much more common if a default behaviour is changed.
+
+- The state of the source should not be changed or destroyed by the
+ outgoing migration. Migrations timing out or being failed by
+ higher levels of management, or failures of the destination host are
+ not unusual, and in that case the VM is restarted on the source.
+ Note that the management layer can validly revert the migration
+ even though the QEMU level of migration has succeeded as long as it
+ does it before starting execution on the destination.
+
+- Buses and devices should be able to explicitly specify addresses when
+ instantiated, and management tools should use those. For example,
+ when hot adding USB devices it's important to specify the ports
+ and addresses, since implicit ordering based on the command line order
+ may be different on the destination. This can result in the
+ device state being loaded into the wrong device.
+
+VMState
+-------
+
+Most device data can be described using the ``VMSTATE`` macros (mostly defined
+in ``include/migration/vmstate.h``).
+
+An example (from hw/input/pckbd.c)
+
+.. code:: c
+
+ static const VMStateDescription vmstate_kbd = {
+ .name = "pckbd",
+ .version_id = 3,
+ .minimum_version_id = 3,
+ .fields = (const VMStateField[]) {
+ VMSTATE_UINT8(write_cmd, KBDState),
+ VMSTATE_UINT8(status, KBDState),
+ VMSTATE_UINT8(mode, KBDState),
+ VMSTATE_UINT8(pending, KBDState),
+ VMSTATE_END_OF_LIST()
+ }
+ };
+
+We are declaring the state with name "pckbd". The ``version_id`` is
+3, and there are 4 uint8_t fields in the KBDState structure. We
+registered this ``VMSTATEDescription`` with one of the following
+functions. The first one will generate a device ``instance_id``
+different for each registration. Use the second one if you already
+have an id that is different for each instance of the device:
+
+.. code:: c
+
+ vmstate_register_any(NULL, &vmstate_kbd, s);
+ vmstate_register(NULL, instance_id, &vmstate_kbd, s);
+
+For devices that are ``qdev`` based, we can register the device in the class
+init function:
+
+.. code:: c
+
+ dc->vmsd = &vmstate_kbd_isa;
+
+The VMState macros take care of ensuring that the device data section
+is formatted portably (normally big endian) and make some compile time checks
+against the types of the fields in the structures.
+
+VMState macros can include other VMStateDescriptions to store substructures
+(see ``VMSTATE_STRUCT_``), arrays (``VMSTATE_ARRAY_``) and variable length
+arrays (``VMSTATE_VARRAY_``). Various other macros exist for special
+cases.
+
+Note that the format on the wire is still very raw; i.e. a VMSTATE_UINT32
+ends up with a 4 byte bigendian representation on the wire; in the future
+it might be possible to use a more structured format.
+
+Legacy way
+----------
+
+This way is going to disappear as soon as all current users are ported to VMSTATE;
+although converting existing code can be tricky, and thus 'soon' is relative.
+
+Each device has to register two functions, one to save the state and
+another to load the state back.
+
+.. code:: c
+
+ int register_savevm_live(const char *idstr,
+ int instance_id,
+ int version_id,
+ SaveVMHandlers *ops,
+ void *opaque);
+
+Two functions in the ``ops`` structure are the ``save_state``
+and ``load_state`` functions. Notice that ``load_state`` receives a version_id
+parameter to know what state format is receiving. ``save_state`` doesn't
+have a version_id parameter because it always uses the latest version.
+
+Note that because the VMState macros still save the data in a raw
+format, in many cases it's possible to replace legacy code
+with a carefully constructed VMState description that matches the
+byte layout of the existing code.
+
+Changing migration data structures
+----------------------------------
+
+When we migrate a device, we save/load the state as a series
+of fields. Sometimes, due to bugs or new functionality, we need to
+change the state to store more/different information. Changing the migration
+state saved for a device can break migration compatibility unless
+care is taken to use the appropriate techniques. In general QEMU tries
+to maintain forward migration compatibility (i.e. migrating from
+QEMU n->n+1) and there are users who benefit from backward compatibility
+as well.
+
+Subsections
+-----------
+
+The most common structure change is adding new data, e.g. when adding
+a newer form of device, or adding that state that you previously
+forgot to migrate. This is best solved using a subsection.
+
+A subsection is "like" a device vmstate, but with a particularity, it
+has a Boolean function that tells if that values are needed to be sent
+or not. If this functions returns false, the subsection is not sent.
+Subsections have a unique name, that is looked for on the receiving
+side.
+
+On the receiving side, if we found a subsection for a device that we
+don't understand, we just fail the migration. If we understand all
+the subsections, then we load the state with success. There's no check
+that a subsection is loaded, so a newer QEMU that knows about a subsection
+can (with care) load a stream from an older QEMU that didn't send
+the subsection.
+
+If the new data is only needed in a rare case, then the subsection
+can be made conditional on that case and the migration will still
+succeed to older QEMUs in most cases. This is OK for data that's
+critical, but in some use cases it's preferred that the migration
+should succeed even with the data missing. To support this the
+subsection can be connected to a device property and from there
+to a versioned machine type.
+
+The 'pre_load' and 'post_load' functions on subsections are only
+called if the subsection is loaded.
+
+One important note is that the outer post_load() function is called "after"
+loading all subsections, because a newer subsection could change the same
+value that it uses. A flag, and the combination of outer pre_load and
+post_load can be used to detect whether a subsection was loaded, and to
+fall back on default behaviour when the subsection isn't present.
+
+Example:
+
+.. code:: c
+
+ static bool ide_drive_pio_state_needed(void *opaque)
+ {
+ IDEState *s = opaque;
+
+ return ((s->status & DRQ_STAT) != 0)
+ || (s->bus->error_status & BM_STATUS_PIO_RETRY);
+ }
+
+ const VMStateDescription vmstate_ide_drive_pio_state = {
+ .name = "ide_drive/pio_state",
+ .version_id = 1,
+ .minimum_version_id = 1,
+ .pre_save = ide_drive_pio_pre_save,
+ .post_load = ide_drive_pio_post_load,
+ .needed = ide_drive_pio_state_needed,
+ .fields = (const VMStateField[]) {
+ VMSTATE_INT32(req_nb_sectors, IDEState),
+ VMSTATE_VARRAY_INT32(io_buffer, IDEState, io_buffer_total_len, 1,
+ vmstate_info_uint8, uint8_t),
+ VMSTATE_INT32(cur_io_buffer_offset, IDEState),
+ VMSTATE_INT32(cur_io_buffer_len, IDEState),
+ VMSTATE_UINT8(end_transfer_fn_idx, IDEState),
+ VMSTATE_INT32(elementary_transfer_size, IDEState),
+ VMSTATE_INT32(packet_transfer_size, IDEState),
+ VMSTATE_END_OF_LIST()
+ }
+ };
+
+ const VMStateDescription vmstate_ide_drive = {
+ .name = "ide_drive",
+ .version_id = 3,
+ .minimum_version_id = 0,
+ .post_load = ide_drive_post_load,
+ .fields = (const VMStateField[]) {
+ .... several fields ....
+ VMSTATE_END_OF_LIST()
+ },
+ .subsections = (const VMStateDescription * const []) {
+ &vmstate_ide_drive_pio_state,
+ NULL
+ }
+ };
+
+Here we have a subsection for the pio state. We only need to
+save/send this state when we are in the middle of a pio operation
+(that is what ``ide_drive_pio_state_needed()`` checks). If DRQ_STAT is
+not enabled, the values on that fields are garbage and don't need to
+be sent.
+
+Connecting subsections to properties
+------------------------------------
+
+Using a condition function that checks a 'property' to determine whether
+to send a subsection allows backward migration compatibility when
+new subsections are added, especially when combined with versioned
+machine types.
+
+For example:
+
+ a) Add a new property using ``DEFINE_PROP_BOOL`` - e.g. support-foo and
+ default it to true.
+ b) Add an entry to the ``hw_compat_`` for the previous version that sets
+ the property to false.
+ c) Add a static bool support_foo function that tests the property.
+ d) Add a subsection with a .needed set to the support_foo function
+ e) (potentially) Add an outer pre_load that sets up a default value
+ for 'foo' to be used if the subsection isn't loaded.
+
+Now that subsection will not be generated when using an older
+machine type and the migration stream will be accepted by older
+QEMU versions.
+
+Not sending existing elements
+-----------------------------
+
+Sometimes members of the VMState are no longer needed:
+
+ - removing them will break migration compatibility
+
+ - making them version dependent and bumping the version will break backward migration
+ compatibility.
+
+Adding a dummy field into the migration stream is normally the best way to preserve
+compatibility.
+
+If the field really does need to be removed then:
+
+ a) Add a new property/compatibility/function in the same way for subsections above.
+ b) replace the VMSTATE macro with the _TEST version of the macro, e.g.:
+
+ ``VMSTATE_UINT32(foo, barstruct)``
+
+ becomes
+
+ ``VMSTATE_UINT32_TEST(foo, barstruct, pre_version_baz)``
+
+ Sometime in the future when we no longer care about the ancient versions these can be killed off.
+ Note that for backward compatibility it's important to fill in the structure with
+ data that the destination will understand.
+
+Any difference in the predicates on the source and destination will end up
+with different fields being enabled and data being loaded into the wrong
+fields; for this reason conditional fields like this are very fragile.
+
+Versions
+--------
+
+Version numbers are intended for major incompatible changes to the
+migration of a device, and using them breaks backward-migration
+compatibility; in general most changes can be made by adding Subsections
+(see above) or _TEST macros (see above) which won't break compatibility.
+
+Each version is associated with a series of fields saved. The ``save_state`` always saves
+the state as the newer version. But ``load_state`` sometimes is able to
+load state from an older version.
+
+You can see that there are two version fields:
+
+- ``version_id``: the maximum version_id supported by VMState for that device.
+- ``minimum_version_id``: the minimum version_id that VMState is able to understand
+ for that device.
+
+VMState is able to read versions from minimum_version_id to version_id.
+
+There are *_V* forms of many ``VMSTATE_`` macros to load fields for version dependent fields,
+e.g.
+
+.. code:: c
+
+ VMSTATE_UINT16_V(ip_id, Slirp, 2),
+
+only loads that field for versions 2 and newer.
+
+Saving state will always create a section with the 'version_id' value
+and thus can't be loaded by any older QEMU.
+
+Massaging functions
+-------------------
+
+Sometimes, it is not enough to be able to save the state directly
+from one structure, we need to fill the correct values there. One
+example is when we are using kvm. Before saving the cpu state, we
+need to ask kvm to copy to QEMU the state that it is using. And the
+opposite when we are loading the state, we need a way to tell kvm to
+load the state for the cpu that we have just loaded from the QEMUFile.
+
+The functions to do that are inside a vmstate definition, and are called:
+
+- ``int (*pre_load)(void *opaque);``
+
+ This function is called before we load the state of one device.
+
+- ``int (*post_load)(void *opaque, int version_id);``
+
+ This function is called after we load the state of one device.
+
+- ``int (*pre_save)(void *opaque);``
+
+ This function is called before we save the state of one device.
+
+- ``int (*post_save)(void *opaque);``
+
+ This function is called after we save the state of one device
+ (even upon failure, unless the call to pre_save returned an error).
+
+Example: You can look at hpet.c, that uses the first three functions
+to massage the state that is transferred.
+
+The ``VMSTATE_WITH_TMP`` macro may be useful when the migration
+data doesn't match the stored device data well; it allows an
+intermediate temporary structure to be populated with migration
+data and then transferred to the main structure.
+
+If you use memory API functions that update memory layout outside
+initialization (i.e., in response to a guest action), this is a strong
+indication that you need to call these functions in a ``post_load`` callback.
+Examples of such memory API functions are:
+
+ - memory_region_add_subregion()
+ - memory_region_del_subregion()
+ - memory_region_set_readonly()
+ - memory_region_set_nonvolatile()
+ - memory_region_set_enabled()
+ - memory_region_set_address()
+ - memory_region_set_alias_offset()
+
+Iterative device migration
+--------------------------
+
+Some devices, such as RAM, Block storage or certain platform devices,
+have large amounts of data that would mean that the CPUs would be
+paused for too long if they were sent in one section. For these
+devices an *iterative* approach is taken.
+
+The iterative devices generally don't use VMState macros
+(although it may be possible in some cases) and instead use
+qemu_put_*/qemu_get_* macros to read/write data to the stream. Specialist
+versions exist for high bandwidth IO.
+
+
+An iterative device must provide:
+
+ - A ``save_setup`` function that initialises the data structures and
+ transmits a first section containing information on the device. In the
+ case of RAM this transmits a list of RAMBlocks and sizes.
+
+ - A ``load_setup`` function that initialises the data structures on the
+ destination.
+
+ - A ``state_pending_exact`` function that indicates how much more
+ data we must save. The core migration code will use this to
+ determine when to pause the CPUs and complete the migration.
+
+ - A ``state_pending_estimate`` function that indicates how much more
+ data we must save. When the estimated amount is smaller than the
+ threshold, we call ``state_pending_exact``.
+
+ - A ``save_live_iterate`` function should send a chunk of data until
+ the point that stream bandwidth limits tell it to stop. Each call
+ generates one section.
+
+ - A ``save_live_complete_precopy`` function that must transmit the
+ last section for the device containing any remaining data.
+
+ - A ``load_state`` function used to load sections generated by
+ any of the save functions that generate sections.
+
+ - ``cleanup`` functions for both save and load that are called
+ at the end of migration.
+
+Note that the contents of the sections for iterative migration tend
+to be open-coded by the devices; care should be taken in parsing
+the results and structuring the stream to make them easy to validate.
+
+Device ordering
+---------------
+
+There are cases in which the ordering of device loading matters; for
+example in some systems where a device may assert an interrupt during loading,
+if the interrupt controller is loaded later then it might lose the state.
+
+Some ordering is implicitly provided by the order in which the machine
+definition creates devices, however this is somewhat fragile.
+
+The ``MigrationPriority`` enum provides a means of explicitly enforcing
+ordering. Numerically higher priorities are loaded earlier.
+The priority is set by setting the ``priority`` field of the top level
+``VMStateDescription`` for the device.
+
+Stream structure
+================
+
+The stream tries to be word and endian agnostic, allowing migration between hosts
+of different characteristics running the same VM.
+
+ - Header
+
+ - Magic
+ - Version
+ - VM configuration section
+
+ - Machine type
+ - Target page bits
+ - List of sections
+ Each section contains a device, or one iteration of a device save.
+
+ - section type
+ - section id
+ - ID string (First section of each device)
+ - instance id (First section of each device)
+ - version id (First section of each device)
+ - <device data>
+ - Footer mark
+ - EOF mark
+ - VM Description structure
+ Consisting of a JSON description of the contents for analysis only
+
+The ``device data`` in each section consists of the data produced
+by the code described above. For non-iterative devices they have a single
+section; iterative devices have an initial and last section and a set
+of parts in between.
+Note that there is very little checking by the common code of the integrity
+of the ``device data`` contents, that's up to the devices themselves.
+The ``footer mark`` provides a little bit of protection for the case where
+the receiving side reads more or less data than expected.
+
+The ``ID string`` is normally unique, having been formed from a bus name
+and device address, PCI devices and storage devices hung off PCI controllers
+fit this pattern well. Some devices are fixed single instances (e.g. "pc-ram").
+Others (especially either older devices or system devices which for
+some reason don't have a bus concept) make use of the ``instance id``
+for otherwise identically named devices.
+
+Return path
+-----------
+
+Only a unidirectional stream is required for normal migration, however a
+``return path`` can be created when bidirectional communication is desired.
+This is primarily used by postcopy, but is also used to return a success
+flag to the source at the end of migration.
+
+``qemu_file_get_return_path(QEMUFile* fwdpath)`` gives the QEMUFile* for the return
+path.
+
+ Source side
+
+ Forward path - written by migration thread
+ Return path - opened by main thread, read by return-path thread
+
+ Destination side
+
+ Forward path - read by main thread
+ Return path - opened by main thread, written by main thread AND postcopy
+ thread (protected by rp_mutex)
+
--- /dev/null
+========
+Postcopy
+========
+
+.. contents::
+
+'Postcopy' migration is a way to deal with migrations that refuse to converge
+(or take too long to converge) its plus side is that there is an upper bound on
+the amount of migration traffic and time it takes, the down side is that during
+the postcopy phase, a failure of *either* side causes the guest to be lost.
+
+In postcopy the destination CPUs are started before all the memory has been
+transferred, and accesses to pages that are yet to be transferred cause
+a fault that's translated by QEMU into a request to the source QEMU.
+
+Postcopy can be combined with precopy (i.e. normal migration) so that if precopy
+doesn't finish in a given time the switch is made to postcopy.
+
+Enabling postcopy
+=================
+
+To enable postcopy, issue this command on the monitor (both source and
+destination) prior to the start of migration:
+
+``migrate_set_capability postcopy-ram on``
+
+The normal commands are then used to start a migration, which is still
+started in precopy mode. Issuing:
+
+``migrate_start_postcopy``
+
+will now cause the transition from precopy to postcopy.
+It can be issued immediately after migration is started or any
+time later on. Issuing it after the end of a migration is harmless.
+
+Blocktime is a postcopy live migration metric, intended to show how
+long the vCPU was in state of interruptible sleep due to pagefault.
+That metric is calculated both for all vCPUs as overlapped value, and
+separately for each vCPU. These values are calculated on destination
+side. To enable postcopy blocktime calculation, enter following
+command on destination monitor:
+
+``migrate_set_capability postcopy-blocktime on``
+
+Postcopy blocktime can be retrieved by query-migrate qmp command.
+postcopy-blocktime value of qmp command will show overlapped blocking
+time for all vCPU, postcopy-vcpu-blocktime will show list of blocking
+time per vCPU.
+
+.. note::
+ During the postcopy phase, the bandwidth limits set using
+ ``migrate_set_parameter`` is ignored (to avoid delaying requested pages that
+ the destination is waiting for).
+
+Postcopy internals
+==================
+
+State machine
+-------------
+
+Postcopy moves through a series of states (see postcopy_state) from
+ADVISE->DISCARD->LISTEN->RUNNING->END
+
+ - Advise
+
+ Set at the start of migration if postcopy is enabled, even
+ if it hasn't had the start command; here the destination
+ checks that its OS has the support needed for postcopy, and performs
+ setup to ensure the RAM mappings are suitable for later postcopy.
+ The destination will fail early in migration at this point if the
+ required OS support is not present.
+ (Triggered by reception of POSTCOPY_ADVISE command)
+
+ - Discard
+
+ Entered on receipt of the first 'discard' command; prior to
+ the first Discard being performed, hugepages are switched off
+ (using madvise) to ensure that no new huge pages are created
+ during the postcopy phase, and to cause any huge pages that
+ have discards on them to be broken.
+
+ - Listen
+
+ The first command in the package, POSTCOPY_LISTEN, switches
+ the destination state to Listen, and starts a new thread
+ (the 'listen thread') which takes over the job of receiving
+ pages off the migration stream, while the main thread carries
+ on processing the blob. With this thread able to process page
+ reception, the destination now 'sensitises' the RAM to detect
+ any access to missing pages (on Linux using the 'userfault'
+ system).
+
+ - Running
+
+ POSTCOPY_RUN causes the destination to synchronise all
+ state and start the CPUs and IO devices running. The main
+ thread now finishes processing the migration package and
+ now carries on as it would for normal precopy migration
+ (although it can't do the cleanup it would do as it
+ finishes a normal migration).
+
+ - Paused
+
+ Postcopy can run into a paused state (normally on both sides when
+ happens), where all threads will be temporarily halted mostly due to
+ network errors. When reaching paused state, migration will make sure
+ the qemu binary on both sides maintain the data without corrupting
+ the VM. To continue the migration, the admin needs to fix the
+ migration channel using the QMP command 'migrate-recover' on the
+ destination node, then resume the migration using QMP command 'migrate'
+ again on source node, with resume=true flag set.
+
+ - End
+
+ The listen thread can now quit, and perform the cleanup of migration
+ state, the migration is now complete.
+
+Device transfer
+---------------
+
+Loading of device data may cause the device emulation to access guest RAM
+that may trigger faults that have to be resolved by the source, as such
+the migration stream has to be able to respond with page data *during* the
+device load, and hence the device data has to be read from the stream completely
+before the device load begins to free the stream up. This is achieved by
+'packaging' the device data into a blob that's read in one go.
+
+Source behaviour
+----------------
+
+Until postcopy is entered the migration stream is identical to normal
+precopy, except for the addition of a 'postcopy advise' command at
+the beginning, to tell the destination that postcopy might happen.
+When postcopy starts the source sends the page discard data and then
+forms the 'package' containing:
+
+ - Command: 'postcopy listen'
+ - The device state
+
+ A series of sections, identical to the precopy streams device state stream
+ containing everything except postcopiable devices (i.e. RAM)
+ - Command: 'postcopy run'
+
+The 'package' is sent as the data part of a Command: ``CMD_PACKAGED``, and the
+contents are formatted in the same way as the main migration stream.
+
+During postcopy the source scans the list of dirty pages and sends them
+to the destination without being requested (in much the same way as precopy),
+however when a page request is received from the destination, the dirty page
+scanning restarts from the requested location. This causes requested pages
+to be sent quickly, and also causes pages directly after the requested page
+to be sent quickly in the hope that those pages are likely to be used
+by the destination soon.
+
+Destination behaviour
+---------------------
+
+Initially the destination looks the same as precopy, with a single thread
+reading the migration stream; the 'postcopy advise' and 'discard' commands
+are processed to change the way RAM is managed, but don't affect the stream
+processing.
+
+::
+
+ ------------------------------------------------------------------------------
+ 1 2 3 4 5 6 7
+ main -----DISCARD-CMD_PACKAGED ( LISTEN DEVICE DEVICE DEVICE RUN )
+ thread | |
+ | (page request)
+ | \___
+ v \
+ listen thread: --- page -- page -- page -- page -- page --
+
+ a b c
+ ------------------------------------------------------------------------------
+
+- On receipt of ``CMD_PACKAGED`` (1)
+
+ All the data associated with the package - the ( ... ) section in the diagram -
+ is read into memory, and the main thread recurses into qemu_loadvm_state_main
+ to process the contents of the package (2) which contains commands (3,6) and
+ devices (4...)
+
+- On receipt of 'postcopy listen' - 3 -(i.e. the 1st command in the package)
+
+ a new thread (a) is started that takes over servicing the migration stream,
+ while the main thread carries on loading the package. It loads normal
+ background page data (b) but if during a device load a fault happens (5)
+ the returned page (c) is loaded by the listen thread allowing the main
+ threads device load to carry on.
+
+- The last thing in the ``CMD_PACKAGED`` is a 'RUN' command (6)
+
+ letting the destination CPUs start running. At the end of the
+ ``CMD_PACKAGED`` (7) the main thread returns to normal running behaviour and
+ is no longer used by migration, while the listen thread carries on servicing
+ page data until the end of migration.
+
+Source side page bitmap
+-----------------------
+
+The 'migration bitmap' in postcopy is basically the same as in the precopy,
+where each of the bit to indicate that page is 'dirty' - i.e. needs
+sending. During the precopy phase this is updated as the CPU dirties
+pages, however during postcopy the CPUs are stopped and nothing should
+dirty anything any more. Instead, dirty bits are cleared when the relevant
+pages are sent during postcopy.
+
+Postcopy features
+=================
+
+Postcopy recovery
+-----------------
+
+Comparing to precopy, postcopy is special on error handlings. When any
+error happens (in this case, mostly network errors), QEMU cannot easily
+fail a migration because VM data resides in both source and destination
+QEMU instances. On the other hand, when issue happens QEMU on both sides
+will go into a paused state. It'll need a recovery phase to continue a
+paused postcopy migration.
+
+The recovery phase normally contains a few steps:
+
+ - When network issue occurs, both QEMU will go into PAUSED state
+
+ - When the network is recovered (or a new network is provided), the admin
+ can setup the new channel for migration using QMP command
+ 'migrate-recover' on destination node, preparing for a resume.
+
+ - On source host, the admin can continue the interrupted postcopy
+ migration using QMP command 'migrate' with resume=true flag set.
+
+ - After the connection is re-established, QEMU will continue the postcopy
+ migration on both sides.
+
+During a paused postcopy migration, the VM can logically still continue
+running, and it will not be impacted from any page access to pages that
+were already migrated to destination VM before the interruption happens.
+However, if any of the missing pages got accessed on destination VM, the VM
+thread will be halted waiting for the page to be migrated, it means it can
+be halted until the recovery is complete.
+
+The impact of accessing missing pages can be relevant to different
+configurations of the guest. For example, when with async page fault
+enabled, logically the guest can proactively schedule out the threads
+accessing missing pages.
+
+Postcopy with hugepages
+-----------------------
+
+Postcopy now works with hugetlbfs backed memory:
+
+ a) The linux kernel on the destination must support userfault on hugepages.
+ b) The huge-page configuration on the source and destination VMs must be
+ identical; i.e. RAMBlocks on both sides must use the same page size.
+ c) Note that ``-mem-path /dev/hugepages`` will fall back to allocating normal
+ RAM if it doesn't have enough hugepages, triggering (b) to fail.
+ Using ``-mem-prealloc`` enforces the allocation using hugepages.
+ d) Care should be taken with the size of hugepage used; postcopy with 2MB
+ hugepages works well, however 1GB hugepages are likely to be problematic
+ since it takes ~1 second to transfer a 1GB hugepage across a 10Gbps link,
+ and until the full page is transferred the destination thread is blocked.
+
+Postcopy with shared memory
+---------------------------
+
+Postcopy migration with shared memory needs explicit support from the other
+processes that share memory and from QEMU. There are restrictions on the type of
+memory that userfault can support shared.
+
+The Linux kernel userfault support works on ``/dev/shm`` memory and on ``hugetlbfs``
+(although the kernel doesn't provide an equivalent to ``madvise(MADV_DONTNEED)``
+for hugetlbfs which may be a problem in some configurations).
+
+The vhost-user code in QEMU supports clients that have Postcopy support,
+and the ``vhost-user-bridge`` (in ``tests/``) and the DPDK package have changes
+to support postcopy.
+
+The client needs to open a userfaultfd and register the areas
+of memory that it maps with userfault. The client must then pass the
+userfaultfd back to QEMU together with a mapping table that allows
+fault addresses in the clients address space to be converted back to
+RAMBlock/offsets. The client's userfaultfd is added to the postcopy
+fault-thread and page requests are made on behalf of the client by QEMU.
+QEMU performs 'wake' operations on the client's userfaultfd to allow it
+to continue after a page has arrived.
+
+.. note::
+ There are two future improvements that would be nice:
+ a) Some way to make QEMU ignorant of the addresses in the clients
+ address space
+ b) Avoiding the need for QEMU to perform ufd-wake calls after the
+ pages have arrived
+
+Retro-fitting postcopy to existing clients is possible:
+ a) A mechanism is needed for the registration with userfault as above,
+ and the registration needs to be coordinated with the phases of
+ postcopy. In vhost-user extra messages are added to the existing
+ control channel.
+ b) Any thread that can block due to guest memory accesses must be
+ identified and the implication understood; for example if the
+ guest memory access is made while holding a lock then all other
+ threads waiting for that lock will also be blocked.
+
+Postcopy preemption mode
+------------------------
+
+Postcopy preempt is a new capability introduced in 8.0 QEMU release, it
+allows urgent pages (those got page fault requested from destination QEMU
+explicitly) to be sent in a separate preempt channel, rather than queued in
+the background migration channel. Anyone who cares about latencies of page
+faults during a postcopy migration should enable this feature. By default,
+it's not enabled.
--- /dev/null
+=====================
+VFIO device migration
+=====================
+
+Migration of virtual machine involves saving the state for each device that
+the guest is running on source host and restoring this saved state on the
+destination host. This document details how saving and restoring of VFIO
+devices is done in QEMU.
+
+Migration of VFIO devices consists of two phases: the optional pre-copy phase,
+and the stop-and-copy phase. The pre-copy phase is iterative and allows to
+accommodate VFIO devices that have a large amount of data that needs to be
+transferred. The iterative pre-copy phase of migration allows for the guest to
+continue whilst the VFIO device state is transferred to the destination, this
+helps to reduce the total downtime of the VM. VFIO devices opt-in to pre-copy
+support by reporting the VFIO_MIGRATION_PRE_COPY flag in the
+VFIO_DEVICE_FEATURE_MIGRATION ioctl.
+
+When pre-copy is supported, it's possible to further reduce downtime by
+enabling "switchover-ack" migration capability.
+VFIO migration uAPI defines "initial bytes" as part of its pre-copy data stream
+and recommends that the initial bytes are sent and loaded in the destination
+before stopping the source VM. Enabling this migration capability will
+guarantee that and thus, can potentially reduce downtime even further.
+
+To support migration of multiple devices that might do P2P transactions between
+themselves, VFIO migration uAPI defines an intermediate P2P quiescent state.
+While in the P2P quiescent state, P2P DMA transactions cannot be initiated by
+the device, but the device can respond to incoming ones. Additionally, all
+outstanding P2P transactions are guaranteed to have been completed by the time
+the device enters this state.
+
+All the devices that support P2P migration are first transitioned to the P2P
+quiescent state and only then are they stopped or started. This makes migration
+safe P2P-wise, since starting and stopping the devices is not done atomically
+for all the devices together.
+
+Thus, multiple VFIO devices migration is allowed only if all the devices
+support P2P migration. Single VFIO device migration is allowed regardless of
+P2P migration support.
+
+A detailed description of the UAPI for VFIO device migration can be found in
+the comment for the ``vfio_device_mig_state`` structure in the header file
+linux-headers/linux/vfio.h.
+
+VFIO implements the device hooks for the iterative approach as follows:
+
+* A ``save_setup`` function that sets up migration on the source.
+
+* A ``load_setup`` function that sets the VFIO device on the destination in
+ _RESUMING state.
+
+* A ``state_pending_estimate`` function that reports an estimate of the
+ remaining pre-copy data that the vendor driver has yet to save for the VFIO
+ device.
+
+* A ``state_pending_exact`` function that reads pending_bytes from the vendor
+ driver, which indicates the amount of data that the vendor driver has yet to
+ save for the VFIO device.
+
+* An ``is_active_iterate`` function that indicates ``save_live_iterate`` is
+ active only when the VFIO device is in pre-copy states.
+
+* A ``save_live_iterate`` function that reads the VFIO device's data from the
+ vendor driver during iterative pre-copy phase.
+
+* A ``switchover_ack_needed`` function that checks if the VFIO device uses
+ "switchover-ack" migration capability when this capability is enabled.
+
+* A ``save_state`` function to save the device config space if it is present.
+
+* A ``save_live_complete_precopy`` function that sets the VFIO device in
+ _STOP_COPY state and iteratively copies the data for the VFIO device until
+ the vendor driver indicates that no data remains.
+
+* A ``load_state`` function that loads the config section and the data
+ sections that are generated by the save functions above.
+
+* ``cleanup`` functions for both save and load that perform any migration
+ related cleanup.
+
+
+The VFIO migration code uses a VM state change handler to change the VFIO
+device state when the VM state changes from running to not-running, and
+vice versa.
+
+Similarly, a migration state change handler is used to trigger a transition of
+the VFIO device state when certain changes of the migration state occur. For
+example, the VFIO device state is transitioned back to _RUNNING in case a
+migration failed or was canceled.
+
+System memory dirty pages tracking
+----------------------------------
+
+A ``log_global_start`` and ``log_global_stop`` memory listener callback informs
+the VFIO dirty tracking module to start and stop dirty page tracking. A
+``log_sync`` memory listener callback queries the dirty page bitmap from the
+dirty tracking module and marks system memory pages which were DMA-ed by the
+VFIO device as dirty. The dirty page bitmap is queried per container.
+
+Currently there are two ways dirty page tracking can be done:
+(1) Device dirty tracking:
+In this method the device is responsible to log and report its DMAs. This
+method can be used only if the device is capable of tracking its DMAs.
+Discovering device capability, starting and stopping dirty tracking, and
+syncing the dirty bitmaps from the device are done using the DMA logging uAPI.
+More info about the uAPI can be found in the comments of the
+``vfio_device_feature_dma_logging_control`` and
+``vfio_device_feature_dma_logging_report`` structures in the header file
+linux-headers/linux/vfio.h.
+
+(2) VFIO IOMMU module:
+In this method dirty tracking is done by IOMMU. However, there is currently no
+IOMMU support for dirty page tracking. For this reason, all pages are
+perpetually marked dirty, unless the device driver pins pages through external
+APIs in which case only those pinned pages are perpetually marked dirty.
+
+If the above two methods are not supported, all pages are perpetually marked
+dirty by QEMU.
+
+By default, dirty pages are tracked during pre-copy as well as stop-and-copy
+phase. So, a page marked as dirty will be copied to the destination in both
+phases. Copying dirty pages in pre-copy phase helps QEMU to predict if it can
+achieve its downtime tolerances. If QEMU during pre-copy phase keeps finding
+dirty pages continuously, then it understands that even in stop-and-copy phase,
+it is likely to find dirty pages and can predict the downtime accordingly.
+
+QEMU also provides a per device opt-out option ``pre-copy-dirty-page-tracking``
+which disables querying the dirty bitmap during pre-copy phase. If it is set to
+off, all dirty pages will be copied to the destination in stop-and-copy phase
+only.
+
+System memory dirty pages tracking when vIOMMU is enabled
+---------------------------------------------------------
+
+With vIOMMU, an IO virtual address range can get unmapped while in pre-copy
+phase of migration. In that case, the unmap ioctl returns any dirty pages in
+that range and QEMU reports corresponding guest physical pages dirty. During
+stop-and-copy phase, an IOMMU notifier is used to get a callback for mapped
+pages and then dirty pages bitmap is fetched from VFIO IOMMU modules for those
+mapped ranges. If device dirty tracking is enabled with vIOMMU, live migration
+will be blocked.
+
+Flow of state changes during Live migration
+===========================================
+
+Below is the state change flow during live migration for a VFIO device that
+supports both precopy and P2P migration. The flow for devices that don't
+support it is similar, except that the relevant states for precopy and P2P are
+skipped.
+The values in the parentheses represent the VM state, the migration state, and
+the VFIO device state, respectively.
+
+Live migration save path
+------------------------
+
+::
+
+ QEMU normal running state
+ (RUNNING, _NONE, _RUNNING)
+ |
+ migrate_init spawns migration_thread
+ Migration thread then calls each device's .save_setup()
+ (RUNNING, _SETUP, _PRE_COPY)
+ |
+ (RUNNING, _ACTIVE, _PRE_COPY)
+ If device is active, get pending_bytes by .state_pending_{estimate,exact}()
+ If total pending_bytes >= threshold_size, call .save_live_iterate()
+ Data of VFIO device for pre-copy phase is copied
+ Iterate till total pending bytes converge and are less than threshold
+ |
+ On migration completion, the vCPUs and the VFIO device are stopped
+ The VFIO device is first put in P2P quiescent state
+ (FINISH_MIGRATE, _ACTIVE, _PRE_COPY_P2P)
+ |
+ Then the VFIO device is put in _STOP_COPY state
+ (FINISH_MIGRATE, _ACTIVE, _STOP_COPY)
+ .save_live_complete_precopy() is called for each active device
+ For the VFIO device, iterate in .save_live_complete_precopy() until
+ pending data is 0
+ |
+ (POSTMIGRATE, _COMPLETED, _STOP_COPY)
+ Migraton thread schedules cleanup bottom half and exits
+ |
+ .save_cleanup() is called
+ (POSTMIGRATE, _COMPLETED, _STOP)
+
+Live migration resume path
+--------------------------
+
+::
+
+ Incoming migration calls .load_setup() for each device
+ (RESTORE_VM, _ACTIVE, _STOP)
+ |
+ For each device, .load_state() is called for that device section data
+ (RESTORE_VM, _ACTIVE, _RESUMING)
+ |
+ At the end, .load_cleanup() is called for each device and vCPUs are started
+ The VFIO device is first put in P2P quiescent state
+ (RUNNING, _ACTIVE, _RUNNING_P2P)
+ |
+ (RUNNING, _NONE, _RUNNING)
+
+Postcopy
+========
+
+Postcopy migration is currently not supported for VFIO devices.
--- /dev/null
+=======================
+Virtio device migration
+=======================
+
+Copyright 2015 IBM Corp.
+
+This work is licensed under the terms of the GNU GPL, version 2 or later. See
+the COPYING file in the top-level directory.
+
+Saving and restoring the state of virtio devices is a bit of a twisty maze,
+for several reasons:
+
+- state is distributed between several parts:
+
+ - virtio core, for common fields like features, number of queues, ...
+
+ - virtio transport (pci, ccw, ...), for the different proxy devices and
+ transport specific state (msix vectors, indicators, ...)
+
+ - virtio device (net, blk, ...), for the different device types and their
+ state (mac address, request queue, ...)
+
+- most fields are saved via the stream interface; subsequently, subsections
+ have been added to make cross-version migration possible
+
+This file attempts to document the current procedure and point out some
+caveats.
+
+Save state procedure
+====================
+
+::
+
+ virtio core virtio transport virtio device
+ ----------- ---------------- -------------
+
+ save() function registered
+ via VMState wrapper on
+ device class
+ virtio_save() <----------
+ ------> save_config()
+ - save proxy device
+ - save transport-specific
+ device fields
+ - save common device
+ fields
+ - save common virtqueue
+ fields
+ ------> save_queue()
+ - save transport-specific
+ virtqueue fields
+ ------> save_device()
+ - save device-specific
+ fields
+ - save subsections
+ - device endianness,
+ if changed from
+ default endianness
+ - 64 bit features, if
+ any high feature bit
+ is set
+ - virtio-1 virtqueue
+ fields, if VERSION_1
+ is set
+
+Load state procedure
+====================
+
+::
+
+ virtio core virtio transport virtio device
+ ----------- ---------------- -------------
+
+ load() function registered
+ via VMState wrapper on
+ device class
+ virtio_load() <----------
+ ------> load_config()
+ - load proxy device
+ - load transport-specific
+ device fields
+ - load common device
+ fields
+ - load common virtqueue
+ fields
+ ------> load_queue()
+ - load transport-specific
+ virtqueue fields
+ - notify guest
+ ------> load_device()
+ - load device-specific
+ fields
+ - load subsections
+ - device endianness
+ - 64 bit features
+ - virtio-1 virtqueue
+ fields
+ - sanitize endianness
+ - sanitize features
+ - virtqueue index sanity
+ check
+ - feature-dependent setup
+
+Implications of this setup
+==========================
+
+Devices need to be careful in their state processing during load: The
+load_device() procedure is invoked by the core before subsections have
+been loaded. Any code that depends on information transmitted in subsections
+therefore has to be invoked in the device's load() function _after_
+virtio_load() returned (like e.g. code depending on features).
+
+Any extension of the state being migrated should be done in subsections
+added to the core for compatibility reasons. If transport or device specific
+state is added, core needs to invoke a callback from the new subsection.
+++ /dev/null
-=====================
-VFIO device Migration
-=====================
-
-Migration of virtual machine involves saving the state for each device that
-the guest is running on source host and restoring this saved state on the
-destination host. This document details how saving and restoring of VFIO
-devices is done in QEMU.
-
-Migration of VFIO devices consists of two phases: the optional pre-copy phase,
-and the stop-and-copy phase. The pre-copy phase is iterative and allows to
-accommodate VFIO devices that have a large amount of data that needs to be
-transferred. The iterative pre-copy phase of migration allows for the guest to
-continue whilst the VFIO device state is transferred to the destination, this
-helps to reduce the total downtime of the VM. VFIO devices opt-in to pre-copy
-support by reporting the VFIO_MIGRATION_PRE_COPY flag in the
-VFIO_DEVICE_FEATURE_MIGRATION ioctl.
-
-When pre-copy is supported, it's possible to further reduce downtime by
-enabling "switchover-ack" migration capability.
-VFIO migration uAPI defines "initial bytes" as part of its pre-copy data stream
-and recommends that the initial bytes are sent and loaded in the destination
-before stopping the source VM. Enabling this migration capability will
-guarantee that and thus, can potentially reduce downtime even further.
-
-To support migration of multiple devices that might do P2P transactions between
-themselves, VFIO migration uAPI defines an intermediate P2P quiescent state.
-While in the P2P quiescent state, P2P DMA transactions cannot be initiated by
-the device, but the device can respond to incoming ones. Additionally, all
-outstanding P2P transactions are guaranteed to have been completed by the time
-the device enters this state.
-
-All the devices that support P2P migration are first transitioned to the P2P
-quiescent state and only then are they stopped or started. This makes migration
-safe P2P-wise, since starting and stopping the devices is not done atomically
-for all the devices together.
-
-Thus, multiple VFIO devices migration is allowed only if all the devices
-support P2P migration. Single VFIO device migration is allowed regardless of
-P2P migration support.
-
-A detailed description of the UAPI for VFIO device migration can be found in
-the comment for the ``vfio_device_mig_state`` structure in the header file
-linux-headers/linux/vfio.h.
-
-VFIO implements the device hooks for the iterative approach as follows:
-
-* A ``save_setup`` function that sets up migration on the source.
-
-* A ``load_setup`` function that sets the VFIO device on the destination in
- _RESUMING state.
-
-* A ``state_pending_estimate`` function that reports an estimate of the
- remaining pre-copy data that the vendor driver has yet to save for the VFIO
- device.
-
-* A ``state_pending_exact`` function that reads pending_bytes from the vendor
- driver, which indicates the amount of data that the vendor driver has yet to
- save for the VFIO device.
-
-* An ``is_active_iterate`` function that indicates ``save_live_iterate`` is
- active only when the VFIO device is in pre-copy states.
-
-* A ``save_live_iterate`` function that reads the VFIO device's data from the
- vendor driver during iterative pre-copy phase.
-
-* A ``switchover_ack_needed`` function that checks if the VFIO device uses
- "switchover-ack" migration capability when this capability is enabled.
-
-* A ``save_state`` function to save the device config space if it is present.
-
-* A ``save_live_complete_precopy`` function that sets the VFIO device in
- _STOP_COPY state and iteratively copies the data for the VFIO device until
- the vendor driver indicates that no data remains.
-
-* A ``load_state`` function that loads the config section and the data
- sections that are generated by the save functions above.
-
-* ``cleanup`` functions for both save and load that perform any migration
- related cleanup.
-
-
-The VFIO migration code uses a VM state change handler to change the VFIO
-device state when the VM state changes from running to not-running, and
-vice versa.
-
-Similarly, a migration state change handler is used to trigger a transition of
-the VFIO device state when certain changes of the migration state occur. For
-example, the VFIO device state is transitioned back to _RUNNING in case a
-migration failed or was canceled.
-
-System memory dirty pages tracking
-----------------------------------
-
-A ``log_global_start`` and ``log_global_stop`` memory listener callback informs
-the VFIO dirty tracking module to start and stop dirty page tracking. A
-``log_sync`` memory listener callback queries the dirty page bitmap from the
-dirty tracking module and marks system memory pages which were DMA-ed by the
-VFIO device as dirty. The dirty page bitmap is queried per container.
-
-Currently there are two ways dirty page tracking can be done:
-(1) Device dirty tracking:
-In this method the device is responsible to log and report its DMAs. This
-method can be used only if the device is capable of tracking its DMAs.
-Discovering device capability, starting and stopping dirty tracking, and
-syncing the dirty bitmaps from the device are done using the DMA logging uAPI.
-More info about the uAPI can be found in the comments of the
-``vfio_device_feature_dma_logging_control`` and
-``vfio_device_feature_dma_logging_report`` structures in the header file
-linux-headers/linux/vfio.h.
-
-(2) VFIO IOMMU module:
-In this method dirty tracking is done by IOMMU. However, there is currently no
-IOMMU support for dirty page tracking. For this reason, all pages are
-perpetually marked dirty, unless the device driver pins pages through external
-APIs in which case only those pinned pages are perpetually marked dirty.
-
-If the above two methods are not supported, all pages are perpetually marked
-dirty by QEMU.
-
-By default, dirty pages are tracked during pre-copy as well as stop-and-copy
-phase. So, a page marked as dirty will be copied to the destination in both
-phases. Copying dirty pages in pre-copy phase helps QEMU to predict if it can
-achieve its downtime tolerances. If QEMU during pre-copy phase keeps finding
-dirty pages continuously, then it understands that even in stop-and-copy phase,
-it is likely to find dirty pages and can predict the downtime accordingly.
-
-QEMU also provides a per device opt-out option ``pre-copy-dirty-page-tracking``
-which disables querying the dirty bitmap during pre-copy phase. If it is set to
-off, all dirty pages will be copied to the destination in stop-and-copy phase
-only.
-
-System memory dirty pages tracking when vIOMMU is enabled
----------------------------------------------------------
-
-With vIOMMU, an IO virtual address range can get unmapped while in pre-copy
-phase of migration. In that case, the unmap ioctl returns any dirty pages in
-that range and QEMU reports corresponding guest physical pages dirty. During
-stop-and-copy phase, an IOMMU notifier is used to get a callback for mapped
-pages and then dirty pages bitmap is fetched from VFIO IOMMU modules for those
-mapped ranges. If device dirty tracking is enabled with vIOMMU, live migration
-will be blocked.
-
-Flow of state changes during Live migration
-===========================================
-
-Below is the state change flow during live migration for a VFIO device that
-supports both precopy and P2P migration. The flow for devices that don't
-support it is similar, except that the relevant states for precopy and P2P are
-skipped.
-The values in the parentheses represent the VM state, the migration state, and
-the VFIO device state, respectively.
-
-Live migration save path
-------------------------
-
-::
-
- QEMU normal running state
- (RUNNING, _NONE, _RUNNING)
- |
- migrate_init spawns migration_thread
- Migration thread then calls each device's .save_setup()
- (RUNNING, _SETUP, _PRE_COPY)
- |
- (RUNNING, _ACTIVE, _PRE_COPY)
- If device is active, get pending_bytes by .state_pending_{estimate,exact}()
- If total pending_bytes >= threshold_size, call .save_live_iterate()
- Data of VFIO device for pre-copy phase is copied
- Iterate till total pending bytes converge and are less than threshold
- |
- On migration completion, the vCPUs and the VFIO device are stopped
- The VFIO device is first put in P2P quiescent state
- (FINISH_MIGRATE, _ACTIVE, _PRE_COPY_P2P)
- |
- Then the VFIO device is put in _STOP_COPY state
- (FINISH_MIGRATE, _ACTIVE, _STOP_COPY)
- .save_live_complete_precopy() is called for each active device
- For the VFIO device, iterate in .save_live_complete_precopy() until
- pending data is 0
- |
- (POSTMIGRATE, _COMPLETED, _STOP_COPY)
- Migraton thread schedules cleanup bottom half and exits
- |
- .save_cleanup() is called
- (POSTMIGRATE, _COMPLETED, _STOP)
-
-Live migration resume path
---------------------------
-
-::
-
- Incoming migration calls .load_setup() for each device
- (RESTORE_VM, _ACTIVE, _STOP)
- |
- For each device, .load_state() is called for that device section data
- (RESTORE_VM, _ACTIVE, _RESUMING)
- |
- At the end, .load_cleanup() is called for each device and vCPUs are started
- The VFIO device is first put in P2P quiescent state
- (RUNNING, _ACTIVE, _RUNNING_P2P)
- |
- (RUNNING, _NONE, _RUNNING)
-
-Postcopy
-========
-
-Postcopy migration is currently not supported for VFIO devices.
+++ /dev/null
-Virtio devices and migration
-============================
-
-Copyright 2015 IBM Corp.
-
-This work is licensed under the terms of the GNU GPL, version 2 or later. See
-the COPYING file in the top-level directory.
-
-Saving and restoring the state of virtio devices is a bit of a twisty maze,
-for several reasons:
-- state is distributed between several parts:
- - virtio core, for common fields like features, number of queues, ...
- - virtio transport (pci, ccw, ...), for the different proxy devices and
- transport specific state (msix vectors, indicators, ...)
- - virtio device (net, blk, ...), for the different device types and their
- state (mac address, request queue, ...)
-- most fields are saved via the stream interface; subsequently, subsections
- have been added to make cross-version migration possible
-
-This file attempts to document the current procedure and point out some
-caveats.
-
-
-Save state procedure
-====================
-
-virtio core virtio transport virtio device
------------ ---------------- -------------
-
- save() function registered
- via VMState wrapper on
- device class
-virtio_save() <----------
- ------> save_config()
- - save proxy device
- - save transport-specific
- device fields
-- save common device
- fields
-- save common virtqueue
- fields
- ------> save_queue()
- - save transport-specific
- virtqueue fields
- ------> save_device()
- - save device-specific
- fields
-- save subsections
- - device endianness,
- if changed from
- default endianness
- - 64 bit features, if
- any high feature bit
- is set
- - virtio-1 virtqueue
- fields, if VERSION_1
- is set
-
-
-Load state procedure
-====================
-
-virtio core virtio transport virtio device
------------ ---------------- -------------
-
- load() function registered
- via VMState wrapper on
- device class
-virtio_load() <----------
- ------> load_config()
- - load proxy device
- - load transport-specific
- device fields
-- load common device
- fields
-- load common virtqueue
- fields
- ------> load_queue()
- - load transport-specific
- virtqueue fields
-- notify guest
- ------> load_device()
- - load device-specific
- fields
-- load subsections
- - device endianness
- - 64 bit features
- - virtio-1 virtqueue
- fields
-- sanitize endianness
-- sanitize features
-- virtqueue index sanity
- check
- - feature-dependent setup
-
-
-Implications of this setup
-==========================
-
-Devices need to be careful in their state processing during load: The
-load_device() procedure is invoked by the core before subsections have
-been loaded. Any code that depends on information transmitted in subsections
-therefore has to be invoked in the device's load() function _after_
-virtio_load() returned (like e.g. code depending on features).
-
-Any extension of the state being migrated should be done in subsections
-added to the core for compatibility reasons. If transport or device specific
-state is added, core needs to invoke a callback from the new subsection.
Supported devices
"""""""""""""""""
-Currently, B-L475E-IOT01A machine's implementation is minimal,
-it only supports the following device:
+Currently B-L475E-IOT01A machine's only supports the following devices:
- Cortex-M4F based STM32L4x5 SoC
+- STM32L4x5 EXTI (Extended interrupts and events controller)
+- STM32L4x5 SYSCFG (System configuration controller)
Missing devices
"""""""""""""""
The B-L475E-IOT01A does *not* support the following devices:
-- Extended interrupts and events controller (EXTI)
- Reset and clock control (RCC)
- Serial ports (UART)
-- System configuration controller (SYSCFG)
- General-purpose I/Os (GPIO)
- Analog to Digital Converter (ADC)
- SPI controller
highmem
Set ``on``/``off`` to enable/disable placing devices and RAM in physical
address space above 32 bits. The default is ``on`` for machine types
- later than ``virt-2.12``.
+ later than ``virt-2.12`` when the CPU supports an address space
+ bigger than 32 bits (i.e. 64-bit CPUs, and 32-bit CPUs with the
+ Large Physical Address Extension (LPAE) feature). If you want to
+ boot a 32-bit kernel which does not have ``CONFIG_LPAE`` enabled on
+ a CPU type which implements LPAE, you will need to manually set
+ this to ``off``; otherwise some devices, such as the PCI controller,
+ will not be accessible.
compact-highmem
Set ``on``/``off`` to enable/disable the compact layout for high memory regions.
-HXCOMM Use DEFHEADING() to define headings in both help text and rST.
-HXCOMM Text between SRST and ERST is copied to the rST version and
-HXCOMM discarded from C version.
-HXCOMM DEF(command, args, callback, arg_string, help) is used to construct
-HXCOMM monitor info commands
+HXCOMM See docs/devel/docs.rst for the format of this file.
+HXCOMM
+HXCOMM This file defines the contents of an array of HMPCommand structs
+HXCOMM which specify the name, behaviour and help text for HMP commands.
+HXCOMM Text between SRST and ERST is rST format documentation.
HXCOMM HXCOMM can be used for comments, discarded from both rST and C.
HXCOMM
HXCOMM In this file, generally SRST fragments should have two extra
-HXCOMM Use DEFHEADING() to define headings in both help text and rST.
-HXCOMM Text between SRST and ERST is copied to the rST version and
-HXCOMM discarded from C version.
-HXCOMM DEF(command, args, callback, arg_string, help) is used to construct
-HXCOMM monitor commands
+HXCOMM See docs/devel/docs.rst for the format of this file.
+HXCOMM
+HXCOMM This file defines the contents of an array of HMPCommand structs
+HXCOMM which specify the name, behaviour and help text for HMP commands.
+HXCOMM Text between SRST and ERST is rST format documentation.
HXCOMM HXCOMM can be used for comments, discarded from both rST and C.
bool
select ARM_V7M
select OR_IRQ
+ select STM32L4X5_SYSCFG
+ select STM32L4X5_EXTI
config XLNX_ZYNQMP_ARM
bool
#define SRAM2_BASE_ADDRESS 0x10000000
#define SRAM2_SIZE (32 * KiB)
+#define EXTI_ADDR 0x40010400
+#define SYSCFG_ADDR 0x40010000
+
+#define NUM_EXTI_IRQ 40
+/* Match exti line connections with their CPU IRQ number */
+/* See Vector Table (Reference Manual p.396) */
+static const int exti_irq[NUM_EXTI_IRQ] = {
+ 6, /* GPIO[0] */
+ 7, /* GPIO[1] */
+ 8, /* GPIO[2] */
+ 9, /* GPIO[3] */
+ 10, /* GPIO[4] */
+ 23, 23, 23, 23, 23, /* GPIO[5..9] */
+ 40, 40, 40, 40, 40, 40, /* GPIO[10..15] */
+ 1, /* PVD */
+ 67, /* OTG_FS_WKUP, Direct */
+ 41, /* RTC_ALARM */
+ 2, /* RTC_TAMP_STAMP2/CSS_LSE */
+ 3, /* RTC wakeup timer */
+ 63, /* COMP1 */
+ 63, /* COMP2 */
+ 31, /* I2C1 wakeup, Direct */
+ 33, /* I2C2 wakeup, Direct */
+ 72, /* I2C3 wakeup, Direct */
+ 37, /* USART1 wakeup, Direct */
+ 38, /* USART2 wakeup, Direct */
+ 39, /* USART3 wakeup, Direct */
+ 52, /* UART4 wakeup, Direct */
+ 53, /* UART4 wakeup, Direct */
+ 70, /* LPUART1 wakeup, Direct */
+ 65, /* LPTIM1, Direct */
+ 66, /* LPTIM2, Direct */
+ 76, /* SWPMI1 wakeup, Direct */
+ 1, /* PVM1 wakeup */
+ 1, /* PVM2 wakeup */
+ 1, /* PVM3 wakeup */
+ 1, /* PVM4 wakeup */
+ 78 /* LCD wakeup, Direct */
+};
+
static void stm32l4x5_soc_initfn(Object *obj)
{
Stm32l4x5SocState *s = STM32L4X5_SOC(obj);
+ object_initialize_child(obj, "exti", &s->exti, TYPE_STM32L4X5_EXTI);
+ object_initialize_child(obj, "syscfg", &s->syscfg, TYPE_STM32L4X5_SYSCFG);
+
s->sysclk = qdev_init_clock_in(DEVICE(s), "sysclk", NULL, NULL, 0);
s->refclk = qdev_init_clock_in(DEVICE(s), "refclk", NULL, NULL, 0);
}
const Stm32l4x5SocClass *sc = STM32L4X5_SOC_GET_CLASS(dev_soc);
MemoryRegion *system_memory = get_system_memory();
DeviceState *armv7m;
+ SysBusDevice *busdev;
/*
* We use s->refclk internally and only define it with qdev_init_clock_in()
return;
}
+ /* System configuration controller */
+ busdev = SYS_BUS_DEVICE(&s->syscfg);
+ if (!sysbus_realize(busdev, errp)) {
+ return;
+ }
+ sysbus_mmio_map(busdev, 0, SYSCFG_ADDR);
+ /*
+ * TODO: when the GPIO device is implemented, connect it
+ * to SYCFG using `qdev_connect_gpio_out`, NUM_GPIOS and
+ * GPIO_NUM_PINS.
+ */
+
+ /* EXTI device */
+ busdev = SYS_BUS_DEVICE(&s->exti);
+ if (!sysbus_realize(busdev, errp)) {
+ return;
+ }
+ sysbus_mmio_map(busdev, 0, EXTI_ADDR);
+ for (unsigned i = 0; i < NUM_EXTI_IRQ; i++) {
+ sysbus_connect_irq(busdev, i, qdev_get_gpio_in(armv7m, exti_irq[i]));
+ }
+
+ for (unsigned i = 0; i < 16; i++) {
+ qdev_connect_gpio_out(DEVICE(&s->syscfg), i,
+ qdev_get_gpio_in(DEVICE(&s->exti), i));
+ }
+
/* APB1 BUS */
create_unimplemented_device("TIM2", 0x40000000, 0x400);
create_unimplemented_device("TIM3", 0x40000400, 0x400);
/* RESERVED: 0x40009800, 0x6800 */
/* APB2 BUS */
- create_unimplemented_device("SYSCFG", 0x40010000, 0x30);
create_unimplemented_device("VREFBUF", 0x40010030, 0x1D0);
create_unimplemented_device("COMP", 0x40010200, 0x200);
- create_unimplemented_device("EXTI", 0x40010400, 0x400);
/* RESERVED: 0x40010800, 0x1400 */
create_unimplemented_device("FIREWALL", 0x40011C00, 0x400);
/* RESERVED: 0x40012000, 0x800 */
#ifdef CONFIG_TCG
ARM_CPU_TYPE_NAME("cortex-a7"),
ARM_CPU_TYPE_NAME("cortex-a15"),
+#ifdef TARGET_AARCH64
ARM_CPU_TYPE_NAME("cortex-a35"),
ARM_CPU_TYPE_NAME("cortex-a55"),
ARM_CPU_TYPE_NAME("cortex-a72"),
ARM_CPU_TYPE_NAME("neoverse-n1"),
ARM_CPU_TYPE_NAME("neoverse-v1"),
ARM_CPU_TYPE_NAME("neoverse-n2"),
-#endif
+#endif /* TARGET_AARCH64 */
+#endif /* CONFIG_TCG */
+#ifdef TARGET_AARCH64
ARM_CPU_TYPE_NAME("cortex-a53"),
ARM_CPU_TYPE_NAME("cortex-a57"),
#if defined(CONFIG_KVM) || defined(CONFIG_HVF)
ARM_CPU_TYPE_NAME("host"),
-#endif
+#endif /* CONFIG_KVM || CONFIG_HVF */
+#endif /* TARGET_AARCH64 */
ARM_CPU_TYPE_NAME("max"),
NULL
};
#define MIN_SEABIOS_HPPA_VERSION 12 /* require at least this fw version */
-/* Power button address at &PAGE0->pad[4] */
-#define HPA_POWER_BUTTON (0x40 + 4 * sizeof(uint32_t))
+#define HPA_POWER_BUTTON (FIRMWARE_END - 0x10)
+static hwaddr soft_power_reg;
#define enable_lasi_lan() 0
static void hppa_powerdown_req(Notifier *n, void *opaque)
{
- hwaddr soft_power_reg = HPA_POWER_BUTTON;
uint32_t val;
val = ldl_be_phys(&address_space_memory, soft_power_reg);
fw_cfg_add_file(fw_cfg, "/etc/hppa/machine",
g_memdup(mc->name, len), len);
- val = cpu_to_le64(HPA_POWER_BUTTON);
+ val = cpu_to_le64(soft_power_reg);
fw_cfg_add_file(fw_cfg, "/etc/hppa/power-button-addr",
g_memdup(&val, sizeof(val)), sizeof(val));
unsigned int smp_cpus = machine->smp.cpus;
TranslateFn *translate;
MemoryRegion *cpu_region;
+ uint64_t ram_max;
/* Create CPUs. */
for (unsigned int i = 0; i < smp_cpus; i++) {
*/
if (hppa_is_pa20(&cpu[0]->env)) {
translate = translate_pa20;
+ ram_max = 0xf0000000; /* 3.75 GB (limited by 32-bit firmware) */
} else {
translate = translate_pa10;
+ ram_max = 0xf0000000; /* 3.75 GB (32-bit CPU) */
}
+ soft_power_reg = translate(NULL, HPA_POWER_BUTTON);
+
for (unsigned int i = 0; i < smp_cpus; i++) {
g_autofree char *name = g_strdup_printf("cpu%u-io-eir", i);
cpu_region);
/* Main memory region. */
- if (machine->ram_size > 3 * GiB) {
- error_report("RAM size is currently restricted to 3GB");
- exit(EXIT_FAILURE);
+ if (machine->ram_size > ram_max) {
+ info_report("Max RAM size limited to %" PRIu64 " MB", ram_max / MiB);
+ machine->ram_size = ram_max;
}
memory_region_add_subregion_overlap(addr_space, 0, machine->ram, -1);
SysBusDevice *s;
/* SCSI disk setup. */
- dev = DEVICE(pci_create_simple(pci_bus, -1, "lsi53c895a"));
- lsi53c8xx_handle_legacy_cmdline(dev);
+ if (drive_get_max_bus(IF_SCSI) >= 0) {
+ dev = DEVICE(pci_create_simple(pci_bus, -1, "lsi53c895a"));
+ lsi53c8xx_handle_legacy_cmdline(dev);
+ }
/* Graphics setup. */
if (machine->enable_graphics && vga_interface_type != VGA_NONE) {
}
/* Network setup. */
- if (enable_lasi_lan()) {
+ if (nd_table[0].used && enable_lasi_lan()) {
lasi_82596_init(addr_space, translate(NULL, LASI_LAN_HPA),
qdev_get_gpio_in(lasi_dev, LASI_IRQ_LAN_HPA));
}
pci_set_word(&pci_dev->config[PCI_SUBSYSTEM_ID], 0x1227); /* Powerbar */
/* create a second serial PCI card when running Astro */
- if (!lasi_dev) {
+ if (serial_hd(1) && !lasi_dev) {
pci_dev = pci_new(-1, "pci-serial-4x");
qdev_prop_set_chr(DEVICE(pci_dev), "chardev1", serial_hd(1));
qdev_prop_set_chr(DEVICE(pci_dev), "chardev2", serial_hd(2));
config STM32F4XX_EXTI
bool
+config STM32L4X5_EXTI
+ bool
+
+config STM32L4X5_SYSCFG
+ bool
+
config MIPS_ITU
bool
system_ss.add(when: 'CONFIG_STM32F2XX_SYSCFG', if_true: files('stm32f2xx_syscfg.c'))
system_ss.add(when: 'CONFIG_STM32F4XX_SYSCFG', if_true: files('stm32f4xx_syscfg.c'))
system_ss.add(when: 'CONFIG_STM32F4XX_EXTI', if_true: files('stm32f4xx_exti.c'))
+system_ss.add(when: 'CONFIG_STM32L4X5_EXTI', if_true: files('stm32l4x5_exti.c'))
+system_ss.add(when: 'CONFIG_STM32L4X5_SYSCFG', if_true: files('stm32l4x5_syscfg.c'))
system_ss.add(when: 'CONFIG_MPS2_FPGAIO', if_true: files('mps2-fpgaio.c'))
system_ss.add(when: 'CONFIG_MPS2_SCC', if_true: files('mps2-scc.c'))
--- /dev/null
+/*
+ * STM32L4x5 EXTI (Extended interrupts and events controller)
+ *
+ * Copyright (c) 2023 Arnaud Minier <arnaud.minier@telecom-paris.fr>
+ * Copyright (c) 2023 Samuel Tardieu <samuel.tardieu@telecom-paris.fr>
+ * Copyright (c) 2023 Inès Varhol <ines.varhol@telecom-paris.fr>
+ *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ *
+ * 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 based on the stm32f4xx_exti by Alistair Francis.
+ * Original code is licensed under the MIT License:
+ *
+ * Copyright (c) 2014 Alistair Francis <alistair@alistair23.me>
+ */
+
+/*
+ * The reference used is the STMicroElectronics RM0351 Reference manual
+ * for STM32L4x5 and STM32L4x6 advanced Arm ® -based 32-bit MCUs.
+ * https://www.st.com/en/microcontrollers-microprocessors/stm32l4x5/documentation.html
+ */
+
+#include "qemu/osdep.h"
+#include "qemu/log.h"
+#include "trace.h"
+#include "hw/irq.h"
+#include "migration/vmstate.h"
+#include "hw/misc/stm32l4x5_exti.h"
+
+#define EXTI_IMR1 0x00
+#define EXTI_EMR1 0x04
+#define EXTI_RTSR1 0x08
+#define EXTI_FTSR1 0x0C
+#define EXTI_SWIER1 0x10
+#define EXTI_PR1 0x14
+#define EXTI_IMR2 0x20
+#define EXTI_EMR2 0x24
+#define EXTI_RTSR2 0x28
+#define EXTI_FTSR2 0x2C
+#define EXTI_SWIER2 0x30
+#define EXTI_PR2 0x34
+
+#define EXTI_NUM_GPIO_EVENT_IN_LINES 16
+#define EXTI_MAX_IRQ_PER_BANK 32
+#define EXTI_IRQS_BANK0 32
+#define EXTI_IRQS_BANK1 8
+
+static const unsigned irqs_per_bank[EXTI_NUM_REGISTER] = {
+ EXTI_IRQS_BANK0,
+ EXTI_IRQS_BANK1,
+};
+
+static const uint32_t exti_romask[EXTI_NUM_REGISTER] = {
+ 0xff820000, /* 0b11111111_10000010_00000000_00000000 */
+ 0x00000087, /* 0b00000000_00000000_00000000_10000111 */
+};
+
+static unsigned regbank_index_by_irq(unsigned irq)
+{
+ return irq >= EXTI_MAX_IRQ_PER_BANK ? 1 : 0;
+}
+
+static unsigned regbank_index_by_addr(hwaddr addr)
+{
+ return addr >= EXTI_IMR2 ? 1 : 0;
+}
+
+static unsigned valid_mask(unsigned bank)
+{
+ return MAKE_64BIT_MASK(0, irqs_per_bank[bank]);
+}
+
+static unsigned configurable_mask(unsigned bank)
+{
+ return valid_mask(bank) & ~exti_romask[bank];
+}
+
+static void stm32l4x5_exti_reset_hold(Object *obj)
+{
+ Stm32l4x5ExtiState *s = STM32L4X5_EXTI(obj);
+
+ for (unsigned bank = 0; bank < EXTI_NUM_REGISTER; bank++) {
+ s->imr[bank] = exti_romask[bank];
+ s->emr[bank] = 0x00000000;
+ s->rtsr[bank] = 0x00000000;
+ s->ftsr[bank] = 0x00000000;
+ s->swier[bank] = 0x00000000;
+ s->pr[bank] = 0x00000000;
+ }
+}
+
+static void stm32l4x5_exti_set_irq(void *opaque, int irq, int level)
+{
+ Stm32l4x5ExtiState *s = opaque;
+ const unsigned bank = regbank_index_by_irq(irq);
+ const int oirq = irq;
+
+ trace_stm32l4x5_exti_set_irq(irq, level);
+
+ /* Shift the value to enable access in x2 registers. */
+ irq %= EXTI_MAX_IRQ_PER_BANK;
+
+ /* If the interrupt is masked, pr won't be raised */
+ if (!extract32(s->imr[bank], irq, 1)) {
+ return;
+ }
+
+ if (((1 << irq) & s->rtsr[bank]) && level) {
+ /* Rising Edge */
+ s->pr[bank] |= 1 << irq;
+ qemu_irq_pulse(s->irq[oirq]);
+ } else if (((1 << irq) & s->ftsr[bank]) && !level) {
+ /* Falling Edge */
+ s->pr[bank] |= 1 << irq;
+ qemu_irq_pulse(s->irq[oirq]);
+ }
+ /*
+ * In the following situations :
+ * - falling edge but rising trigger selected
+ * - rising edge but falling trigger selected
+ * - no trigger selected
+ * No action is required
+ */
+}
+
+static uint64_t stm32l4x5_exti_read(void *opaque, hwaddr addr,
+ unsigned int size)
+{
+ Stm32l4x5ExtiState *s = opaque;
+ uint32_t r = 0;
+ const unsigned bank = regbank_index_by_addr(addr);
+
+ switch (addr) {
+ case EXTI_IMR1:
+ case EXTI_IMR2:
+ r = s->imr[bank];
+ break;
+ case EXTI_EMR1:
+ case EXTI_EMR2:
+ r = s->emr[bank];
+ break;
+ case EXTI_RTSR1:
+ case EXTI_RTSR2:
+ r = s->rtsr[bank];
+ break;
+ case EXTI_FTSR1:
+ case EXTI_FTSR2:
+ r = s->ftsr[bank];
+ break;
+ case EXTI_SWIER1:
+ case EXTI_SWIER2:
+ r = s->swier[bank];
+ break;
+ case EXTI_PR1:
+ case EXTI_PR2:
+ r = s->pr[bank];
+ break;
+
+ default:
+ qemu_log_mask(LOG_GUEST_ERROR,
+ "STM32L4X5_exti_read: Bad offset 0x%" HWADDR_PRIx "\n",
+ addr);
+ break;
+ }
+
+ trace_stm32l4x5_exti_read(addr, r);
+
+ return r;
+}
+
+static void stm32l4x5_exti_write(void *opaque, hwaddr addr,
+ uint64_t val64, unsigned int size)
+{
+ Stm32l4x5ExtiState *s = opaque;
+ const unsigned bank = regbank_index_by_addr(addr);
+
+ trace_stm32l4x5_exti_write(addr, val64);
+
+ switch (addr) {
+ case EXTI_IMR1:
+ case EXTI_IMR2:
+ s->imr[bank] = val64 & valid_mask(bank);
+ return;
+ case EXTI_EMR1:
+ case EXTI_EMR2:
+ s->emr[bank] = val64 & valid_mask(bank);
+ return;
+ case EXTI_RTSR1:
+ case EXTI_RTSR2:
+ s->rtsr[bank] = val64 & configurable_mask(bank);
+ return;
+ case EXTI_FTSR1:
+ case EXTI_FTSR2:
+ s->ftsr[bank] = val64 & configurable_mask(bank);
+ return;
+ case EXTI_SWIER1:
+ case EXTI_SWIER2: {
+ const uint32_t set = val64 & configurable_mask(bank);
+ const uint32_t pend = set & ~s->swier[bank] & s->imr[bank] &
+ ~s->pr[bank];
+ s->swier[bank] = set;
+ s->pr[bank] |= pend;
+ for (unsigned i = 0; i < irqs_per_bank[bank]; i++) {
+ if (extract32(pend, i, 1)) {
+ qemu_irq_pulse(s->irq[i + 32 * bank]);
+ }
+ }
+ return;
+ }
+ case EXTI_PR1:
+ case EXTI_PR2: {
+ const uint32_t cleared = s->pr[bank] & val64 & configurable_mask(bank);
+ /* This bit is cleared by writing a 1 to it */
+ s->pr[bank] &= ~cleared;
+ /* Software triggered interrupts are cleared as well */
+ s->swier[bank] &= ~cleared;
+ return;
+ }
+ default:
+ qemu_log_mask(LOG_GUEST_ERROR,
+ "STM32L4X5_exti_write: Bad offset 0x%" HWADDR_PRIx "\n",
+ addr);
+ }
+}
+
+static const MemoryRegionOps stm32l4x5_exti_ops = {
+ .read = stm32l4x5_exti_read,
+ .write = stm32l4x5_exti_write,
+ .endianness = DEVICE_NATIVE_ENDIAN,
+ .impl.min_access_size = 4,
+ .impl.max_access_size = 4,
+ .impl.unaligned = false,
+ .valid.min_access_size = 4,
+ .valid.max_access_size = 4,
+ .valid.unaligned = false,
+};
+
+static void stm32l4x5_exti_init(Object *obj)
+{
+ Stm32l4x5ExtiState *s = STM32L4X5_EXTI(obj);
+
+ for (size_t i = 0; i < EXTI_NUM_INTERRUPT_OUT_LINES; i++) {
+ sysbus_init_irq(SYS_BUS_DEVICE(obj), &s->irq[i]);
+ }
+
+ memory_region_init_io(&s->mmio, obj, &stm32l4x5_exti_ops, s,
+ TYPE_STM32L4X5_EXTI, 0x400);
+ sysbus_init_mmio(SYS_BUS_DEVICE(obj), &s->mmio);
+
+ qdev_init_gpio_in(DEVICE(obj), stm32l4x5_exti_set_irq,
+ EXTI_NUM_GPIO_EVENT_IN_LINES);
+}
+
+static const VMStateDescription vmstate_stm32l4x5_exti = {
+ .name = TYPE_STM32L4X5_EXTI,
+ .version_id = 1,
+ .minimum_version_id = 1,
+ .fields = (VMStateField[]) {
+ VMSTATE_UINT32_ARRAY(imr, Stm32l4x5ExtiState, EXTI_NUM_REGISTER),
+ VMSTATE_UINT32_ARRAY(emr, Stm32l4x5ExtiState, EXTI_NUM_REGISTER),
+ VMSTATE_UINT32_ARRAY(rtsr, Stm32l4x5ExtiState, EXTI_NUM_REGISTER),
+ VMSTATE_UINT32_ARRAY(ftsr, Stm32l4x5ExtiState, EXTI_NUM_REGISTER),
+ VMSTATE_UINT32_ARRAY(swier, Stm32l4x5ExtiState, EXTI_NUM_REGISTER),
+ VMSTATE_UINT32_ARRAY(pr, Stm32l4x5ExtiState, EXTI_NUM_REGISTER),
+ VMSTATE_END_OF_LIST()
+ }
+};
+
+static void stm32l4x5_exti_class_init(ObjectClass *klass, void *data)
+{
+ DeviceClass *dc = DEVICE_CLASS(klass);
+ ResettableClass *rc = RESETTABLE_CLASS(klass);
+
+ dc->vmsd = &vmstate_stm32l4x5_exti;
+ rc->phases.hold = stm32l4x5_exti_reset_hold;
+}
+
+static const TypeInfo stm32l4x5_exti_types[] = {
+ {
+ .name = TYPE_STM32L4X5_EXTI,
+ .parent = TYPE_SYS_BUS_DEVICE,
+ .instance_size = sizeof(Stm32l4x5ExtiState),
+ .instance_init = stm32l4x5_exti_init,
+ .class_init = stm32l4x5_exti_class_init,
+ }
+};
+
+DEFINE_TYPES(stm32l4x5_exti_types)
--- /dev/null
+/*
+ * STM32L4x5 SYSCFG (System Configuration Controller)
+ *
+ * Copyright (c) 2023 Arnaud Minier <arnaud.minier@telecom-paris.fr>
+ * Copyright (c) 2023 Inès Varhol <ines.varhol@telecom-paris.fr>
+ *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ *
+ * 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 based on the stm32f4xx_syscfg by Alistair Francis.
+ * Original code is licensed under the MIT License:
+ *
+ * Copyright (c) 2014 Alistair Francis <alistair@alistair23.me>
+ */
+
+/*
+ * The reference used is the STMicroElectronics RM0351 Reference manual
+ * for STM32L4x5 and STM32L4x6 advanced Arm ® -based 32-bit MCUs.
+ * https://www.st.com/en/microcontrollers-microprocessors/stm32l4x5/documentation.html
+ */
+
+#include "qemu/osdep.h"
+#include "qemu/log.h"
+#include "trace.h"
+#include "hw/irq.h"
+#include "migration/vmstate.h"
+#include "hw/misc/stm32l4x5_syscfg.h"
+
+#define SYSCFG_MEMRMP 0x00
+#define SYSCFG_CFGR1 0x04
+#define SYSCFG_EXTICR1 0x08
+#define SYSCFG_EXTICR2 0x0C
+#define SYSCFG_EXTICR3 0x10
+#define SYSCFG_EXTICR4 0x14
+#define SYSCFG_SCSR 0x18
+#define SYSCFG_CFGR2 0x1C
+#define SYSCFG_SWPR 0x20
+#define SYSCFG_SKR 0x24
+#define SYSCFG_SWPR2 0x28
+
+/* 00000000_00000000_00000001_00000111 */
+#define ACTIVABLE_BITS_MEMRP 0x00000107
+
+/* 11111100_11111111_00000001_00000000 */
+#define ACTIVABLE_BITS_CFGR1 0xFCFF0100
+/* 00000000_00000000_00000000_00000001 */
+#define FIREWALL_DISABLE_CFGR1 0x00000001
+
+/* 00000000_00000000_11111111_11111111 */
+#define ACTIVABLE_BITS_EXTICR 0x0000FFFF
+
+/* 00000000_00000000_00000000_00000011 */
+/* #define ACTIVABLE_BITS_SCSR 0x00000003 */
+
+/* 00000000_00000000_00000000_00001111 */
+#define ECC_LOCK_CFGR2 0x0000000F
+/* 00000000_00000000_00000001_00000000 */
+#define SRAM2_PARITY_ERROR_FLAG_CFGR2 0x00000100
+
+/* 00000000_00000000_00000000_11111111 */
+#define ACTIVABLE_BITS_SKR 0x000000FF
+
+#define NUM_LINES_PER_EXTICR_REG 4
+
+static void stm32l4x5_syscfg_hold_reset(Object *obj)
+{
+ Stm32l4x5SyscfgState *s = STM32L4X5_SYSCFG(obj);
+
+ s->memrmp = 0x00000000;
+ s->cfgr1 = 0x7C000001;
+ s->exticr[0] = 0x00000000;
+ s->exticr[1] = 0x00000000;
+ s->exticr[2] = 0x00000000;
+ s->exticr[3] = 0x00000000;
+ s->scsr = 0x00000000;
+ s->cfgr2 = 0x00000000;
+ s->swpr = 0x00000000;
+ s->skr = 0x00000000;
+ s->swpr2 = 0x00000000;
+}
+
+static void stm32l4x5_syscfg_set_irq(void *opaque, int irq, int level)
+{
+ Stm32l4x5SyscfgState *s = opaque;
+ const uint8_t gpio = irq / GPIO_NUM_PINS;
+ const int line = irq % GPIO_NUM_PINS;
+
+ const int exticr_reg = line / NUM_LINES_PER_EXTICR_REG;
+ const int startbit = (line % NUM_LINES_PER_EXTICR_REG) * 4;
+
+ g_assert(gpio < NUM_GPIOS);
+ trace_stm32l4x5_syscfg_set_irq(gpio, line, level);
+
+ if (extract32(s->exticr[exticr_reg], startbit, 4) == gpio) {
+ trace_stm32l4x5_syscfg_forward_exti(line);
+ qemu_set_irq(s->gpio_out[line], level);
+ }
+}
+
+static uint64_t stm32l4x5_syscfg_read(void *opaque, hwaddr addr,
+ unsigned int size)
+{
+ Stm32l4x5SyscfgState *s = opaque;
+
+ trace_stm32l4x5_syscfg_read(addr);
+
+ switch (addr) {
+ case SYSCFG_MEMRMP:
+ return s->memrmp;
+ case SYSCFG_CFGR1:
+ return s->cfgr1;
+ case SYSCFG_EXTICR1...SYSCFG_EXTICR4:
+ return s->exticr[(addr - SYSCFG_EXTICR1) / 4];
+ case SYSCFG_SCSR:
+ return s->scsr;
+ case SYSCFG_CFGR2:
+ return s->cfgr2;
+ case SYSCFG_SWPR:
+ return s->swpr;
+ case SYSCFG_SKR:
+ return s->skr;
+ case SYSCFG_SWPR2:
+ return s->swpr2;
+ default:
+ qemu_log_mask(LOG_GUEST_ERROR,
+ "%s: Bad offset 0x%" HWADDR_PRIx "\n", __func__, addr);
+ return 0;
+ }
+}
+static void stm32l4x5_syscfg_write(void *opaque, hwaddr addr,
+ uint64_t value, unsigned int size)
+{
+ Stm32l4x5SyscfgState *s = opaque;
+
+ trace_stm32l4x5_syscfg_write(addr, value);
+
+ switch (addr) {
+ case SYSCFG_MEMRMP:
+ qemu_log_mask(LOG_UNIMP,
+ "%s: Changing the memory mapping isn't supported\n",
+ __func__);
+ s->memrmp = value & ACTIVABLE_BITS_MEMRP;
+ return;
+ case SYSCFG_CFGR1:
+ qemu_log_mask(LOG_UNIMP,
+ "%s: Functions in CFGRx aren't supported\n",
+ __func__);
+ /* bit 0 (firewall dis.) is cleared by software, set only by reset. */
+ s->cfgr1 = (s->cfgr1 & value & FIREWALL_DISABLE_CFGR1) |
+ (value & ACTIVABLE_BITS_CFGR1);
+ return;
+ case SYSCFG_EXTICR1...SYSCFG_EXTICR4:
+ s->exticr[(addr - SYSCFG_EXTICR1) / 4] =
+ (value & ACTIVABLE_BITS_EXTICR);
+ return;
+ case SYSCFG_SCSR:
+ qemu_log_mask(LOG_UNIMP,
+ "%s: Erasing SRAM2 isn't supported\n",
+ __func__);
+ /*
+ * only non reserved bits are :
+ * bit 0 (write-protected by a passkey), bit 1 (meant to be read)
+ * so it serves no purpose yet to add :
+ * s->scsr = value & 0x3;
+ */
+ return;
+ case SYSCFG_CFGR2:
+ qemu_log_mask(LOG_UNIMP,
+ "%s: Functions in CFGRx aren't supported\n",
+ __func__);
+ /* bit 8 (SRAM2 PEF) is cleared by software by writing a '1'.*/
+ /* bits[3:0] (ECC Lock) are set by software, cleared only by reset.*/
+ s->cfgr2 = (s->cfgr2 | (value & ECC_LOCK_CFGR2)) &
+ ~(value & SRAM2_PARITY_ERROR_FLAG_CFGR2);
+ return;
+ case SYSCFG_SWPR:
+ qemu_log_mask(LOG_UNIMP,
+ "%s: Write protecting SRAM2 isn't supported\n",
+ __func__);
+ /* These bits are set by software and cleared only by reset.*/
+ s->swpr |= value;
+ return;
+ case SYSCFG_SKR:
+ qemu_log_mask(LOG_UNIMP,
+ "%s: Erasing SRAM2 isn't supported\n",
+ __func__);
+ s->skr = value & ACTIVABLE_BITS_SKR;
+ return;
+ case SYSCFG_SWPR2:
+ qemu_log_mask(LOG_UNIMP,
+ "%s: Write protecting SRAM2 isn't supported\n",
+ __func__);
+ /* These bits are set by software and cleared only by reset.*/
+ s->swpr2 |= value;
+ return;
+ default:
+ qemu_log_mask(LOG_GUEST_ERROR,
+ "%s: Bad offset 0x%" HWADDR_PRIx "\n", __func__, addr);
+ }
+}
+
+static const MemoryRegionOps stm32l4x5_syscfg_ops = {
+ .read = stm32l4x5_syscfg_read,
+ .write = stm32l4x5_syscfg_write,
+ .endianness = DEVICE_NATIVE_ENDIAN,
+ .impl.min_access_size = 4,
+ .impl.max_access_size = 4,
+ .impl.unaligned = false,
+ .valid.min_access_size = 4,
+ .valid.max_access_size = 4,
+ .valid.unaligned = false,
+};
+
+static void stm32l4x5_syscfg_init(Object *obj)
+{
+ Stm32l4x5SyscfgState *s = STM32L4X5_SYSCFG(obj);
+
+ memory_region_init_io(&s->mmio, obj, &stm32l4x5_syscfg_ops, s,
+ TYPE_STM32L4X5_SYSCFG, 0x400);
+ sysbus_init_mmio(SYS_BUS_DEVICE(obj), &s->mmio);
+
+ qdev_init_gpio_in(DEVICE(obj), stm32l4x5_syscfg_set_irq,
+ GPIO_NUM_PINS * NUM_GPIOS);
+ qdev_init_gpio_out(DEVICE(obj), s->gpio_out, GPIO_NUM_PINS);
+}
+
+static const VMStateDescription vmstate_stm32l4x5_syscfg = {
+ .name = TYPE_STM32L4X5_SYSCFG,
+ .version_id = 1,
+ .minimum_version_id = 1,
+ .fields = (VMStateField[]) {
+ VMSTATE_UINT32(memrmp, Stm32l4x5SyscfgState),
+ VMSTATE_UINT32(cfgr1, Stm32l4x5SyscfgState),
+ VMSTATE_UINT32_ARRAY(exticr, Stm32l4x5SyscfgState,
+ SYSCFG_NUM_EXTICR),
+ VMSTATE_UINT32(scsr, Stm32l4x5SyscfgState),
+ VMSTATE_UINT32(cfgr2, Stm32l4x5SyscfgState),
+ VMSTATE_UINT32(swpr, Stm32l4x5SyscfgState),
+ VMSTATE_UINT32(skr, Stm32l4x5SyscfgState),
+ VMSTATE_UINT32(swpr2, Stm32l4x5SyscfgState),
+ VMSTATE_END_OF_LIST()
+ }
+};
+
+static void stm32l4x5_syscfg_class_init(ObjectClass *klass, void *data)
+{
+ DeviceClass *dc = DEVICE_CLASS(klass);
+ ResettableClass *rc = RESETTABLE_CLASS(klass);
+
+ dc->vmsd = &vmstate_stm32l4x5_syscfg;
+ rc->phases.hold = stm32l4x5_syscfg_hold_reset;
+}
+
+static const TypeInfo stm32l4x5_syscfg_info[] = {
+ {
+ .name = TYPE_STM32L4X5_SYSCFG,
+ .parent = TYPE_SYS_BUS_DEVICE,
+ .instance_size = sizeof(Stm32l4x5SyscfgState),
+ .instance_init = stm32l4x5_syscfg_init,
+ .class_init = stm32l4x5_syscfg_class_init,
+ }
+};
+
+DEFINE_TYPES(stm32l4x5_syscfg_info)
stm32f4xx_exti_read(uint64_t addr) "reg read: addr: 0x%" PRIx64 " "
stm32f4xx_exti_write(uint64_t addr, uint64_t data) "reg write: addr: 0x%" PRIx64 " val: 0x%" PRIx64 ""
+# stm32l4x5_syscfg.c
+stm32l4x5_syscfg_set_irq(int gpio, int line, int level) "irq from GPIO: %d, line: %d, level: %d"
+stm32l4x5_syscfg_forward_exti(int irq) "irq %d forwarded to EXTI"
+stm32l4x5_syscfg_read(uint64_t addr) "reg read: addr: 0x%" PRIx64 " "
+stm32l4x5_syscfg_write(uint64_t addr, uint64_t data) "reg write: addr: 0x%" PRIx64 " val: 0x%" PRIx64 ""
+
+# stm32l4x5_exti.c
+stm32l4x5_exti_set_irq(int irq, int level) "Set EXTI: %d to %d"
+stm32l4x5_exti_read(uint64_t addr, uint64_t data) "reg read: addr: 0x%" PRIx64 " val: 0x%" PRIx64 ""
+stm32l4x5_exti_write(uint64_t addr, uint64_t data) "reg write: addr: 0x%" PRIx64 " val: 0x%" PRIx64 ""
+
# tz-mpc.c
tz_mpc_reg_read(uint32_t offset, uint64_t data, unsigned size) "TZ MPC regs read: offset 0x%x data 0x%" PRIx64 " size %u"
tz_mpc_reg_write(uint32_t offset, uint64_t data, unsigned size) "TZ MPC regs write: offset 0x%x data 0x%" PRIx64 " size %u"
trace_elroy_write(addr, size, val);
switch ((addr >> 3) << 3) {
+ case 0x000: /* PCI_ID & PCI_COMMAND_STATUS_REG */
+ break;
case 0x080:
put_val_in_int64(&s->arb_mask, addr, size, val);
break;
case 0x200 ... 0x250 - 1: /* LMMIO, GMMIO, WLMMIO, WGMMIO, ... */
put_val_in_arrary(s->mmio_base, 0x200, addr, size, val);
break;
+ case 0x300: /* ibase */
+ case 0x308: /* imask */
+ break;
case 0x0680:
put_val_in_int64(&s->error_config, addr, size, val);
break;
case 0x0030: /* HP-UX 10.20 and 11.11 reads it. No idea. */
val = -1;
break;
+ case 0x0078: /* NetBSD reads 0x78 ? */
+ val = -1;
+ break;
case 0x0300 ... 0x03d8: /* LMMIO_DIRECT0_BASE... */
index = (addr - 0x300) / 8;
val = s->ioc_ranges[index];
case 0x10220:
case 0x10230: /* HP-UX 11.11 reads it. No idea. */
break;
- case 0x22108: /* IOC STATUS_CONTROL */
- put_val_in_int64(&s->ioc_status_ctrl, addr, size, val);
- break;
case 0x20200 ... 0x20240 - 1: /* IOC Rope0_Control ... */
put_val_in_arrary(s->ioc_rope_control, 0x20200, addr, size, val);
break;
case 0x20040: /* IOC Rope config */
+ case 0x22040:
put_val_in_int64(&s->ioc_rope_config, addr, size, val);
break;
case 0x20300:
+ case 0x22300:
put_val_in_int64(&s->tlb_ibase, addr, size, val);
break;
case 0x20308:
+ case 0x22308:
put_val_in_int64(&s->tlb_imask, addr, size, val);
break;
case 0x20310:
+ case 0x22310:
put_val_in_int64(&s->tlb_pcom, addr, size, val);
/* TODO: flush iommu */
break;
case 0x20318:
+ case 0x22318:
put_val_in_int64(&s->tlb_tcnfg, addr, size, val);
break;
case 0x20320:
+ case 0x22320:
put_val_in_int64(&s->tlb_pdir_base, addr, size, val);
break;
+ case 0x22000: /* func_id */
+ break;
+ case 0x22008: /* func_class */
+ break;
+ case 0x22050: /* rope_debug */
+ break;
+ case 0x22108: /* IOC STATUS_CONTROL */
+ put_val_in_int64(&s->ioc_status_ctrl, addr, size, val);
+ break;
/*
* empty placeholders for non-existent elroys, e.g.
* func_class, pci config & data
# armv7m_systick.c
systick_reload(void) "systick reload"
-systick_timer_tick(void) "systick reload"
+systick_timer_tick(void) "systick tick"
systick_read(uint64_t addr, uint32_t value, unsigned size) "systick read addr 0x%" PRIx64 " data 0x%" PRIx32 " size %u"
systick_write(uint64_t addr, uint32_t value, unsigned size) "systick write addr 0x%" PRIx64 " data 0x%" PRIx32 " size %u"
#include "exec/memory.h"
#include "hw/arm/armv7m.h"
+#include "hw/misc/stm32l4x5_syscfg.h"
+#include "hw/misc/stm32l4x5_exti.h"
#include "qom/object.h"
#define TYPE_STM32L4X5_SOC "stm32l4x5-soc"
ARMv7MState armv7m;
+ Stm32l4x5ExtiState exti;
+ Stm32l4x5SyscfgState syscfg;
+
MemoryRegion sram1;
MemoryRegion sram2;
MemoryRegion flash;
}
if (data_swab) {
- int j;
+ elf_word j;
for (j = 0; j < file_size; j += (1 << data_swab)) {
uint8_t *dp = data + j;
switch (data_swab) {
--- /dev/null
+/*
+ * STM32L4x5 EXTI (Extended interrupts and events controller)
+ *
+ * Copyright (c) 2023 Arnaud Minier <arnaud.minier@telecom-paris.fr>
+ * Copyright (c) 2023 Inès Varhol <ines.varhol@telecom-paris.fr>
+ *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ *
+ * 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 based on the stm32f4xx_exti by Alistair Francis.
+ * Original code is licensed under the MIT License:
+ *
+ * Copyright (c) 2014 Alistair Francis <alistair@alistair23.me>
+ */
+
+/*
+ * The reference used is the STMicroElectronics RM0351 Reference manual
+ * for STM32L4x5 and STM32L4x6 advanced Arm ® -based 32-bit MCUs.
+ * https://www.st.com/en/microcontrollers-microprocessors/stm32l4x5/documentation.html
+ */
+
+#ifndef HW_STM32L4X5_EXTI_H
+#define HW_STM32L4X5_EXTI_H
+
+#include "hw/sysbus.h"
+#include "qom/object.h"
+
+#define TYPE_STM32L4X5_EXTI "stm32l4x5-exti"
+OBJECT_DECLARE_SIMPLE_TYPE(Stm32l4x5ExtiState, STM32L4X5_EXTI)
+
+#define EXTI_NUM_INTERRUPT_OUT_LINES 40
+#define EXTI_NUM_REGISTER 2
+
+struct Stm32l4x5ExtiState {
+ SysBusDevice parent_obj;
+
+ MemoryRegion mmio;
+
+ uint32_t imr[EXTI_NUM_REGISTER];
+ uint32_t emr[EXTI_NUM_REGISTER];
+ uint32_t rtsr[EXTI_NUM_REGISTER];
+ uint32_t ftsr[EXTI_NUM_REGISTER];
+ uint32_t swier[EXTI_NUM_REGISTER];
+ uint32_t pr[EXTI_NUM_REGISTER];
+
+ qemu_irq irq[EXTI_NUM_INTERRUPT_OUT_LINES];
+};
+
+#endif
--- /dev/null
+/*
+ * STM32L4x5 SYSCFG (System Configuration Controller)
+ *
+ * Copyright (c) 2023 Arnaud Minier <arnaud.minier@telecom-paris.fr>
+ * Copyright (c) 2023 Inès Varhol <ines.varhol@telecom-paris.fr>
+ *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ *
+ * 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 based on the stm32f4xx_syscfg by Alistair Francis.
+ * Original code is licensed under the MIT License:
+ *
+ * Copyright (c) 2014 Alistair Francis <alistair@alistair23.me>
+ */
+
+/*
+ * The reference used is the STMicroElectronics RM0351 Reference manual
+ * for STM32L4x5 and STM32L4x6 advanced Arm ® -based 32-bit MCUs.
+ * https://www.st.com/en/microcontrollers-microprocessors/stm32l4x5/documentation.html
+ */
+
+#ifndef HW_STM32L4X5_SYSCFG_H
+#define HW_STM32L4X5_SYSCFG_H
+
+#include "hw/sysbus.h"
+#include "qom/object.h"
+
+#define TYPE_STM32L4X5_SYSCFG "stm32l4x5-syscfg"
+OBJECT_DECLARE_SIMPLE_TYPE(Stm32l4x5SyscfgState, STM32L4X5_SYSCFG)
+
+#define NUM_GPIOS 8
+#define GPIO_NUM_PINS 16
+#define SYSCFG_NUM_EXTICR 4
+
+struct Stm32l4x5SyscfgState {
+ SysBusDevice parent_obj;
+
+ MemoryRegion mmio;
+
+ uint32_t memrmp;
+ uint32_t cfgr1;
+ uint32_t exticr[SYSCFG_NUM_EXTICR];
+ uint32_t scsr;
+ uint32_t cfgr2;
+ uint32_t swpr;
+ uint32_t skr;
+ uint32_t swpr2;
+
+ qemu_irq gpio_out[GPIO_NUM_PINS];
+};
+
+#endif
add_global_link_arguments(cfi_flags, native: false, language: all_languages)
endif
+# Check further flags that make QEMU more robust against malicious parties
+
+hardening_flags = [
+ # Zero out registers used during a function call
+ # upon its return. This makes it harder to assemble
+ # ROP gadgets into something usable
+ '-fzero-call-used-regs=used-gpr',
+
+ # Initialize all stack variables to zero. This makes
+ # it harder to take advantage of uninitialized stack
+ # data to drive exploits
+ '-ftrivial-auto-var-init=zero',
+]
+
+qemu_common_flags += cc.get_supported_arguments(hardening_flags)
+
add_global_arguments(qemu_common_flags, native: false, language: all_languages)
add_global_link_arguments(qemu_ldflags, native: false, language: all_languages)
/*
* Having preliminary checks for uri and channel
*/
- if (uri && has_channels) {
- error_setg(errp, "'uri' and 'channels' arguments are mutually "
- "exclusive; exactly one of the two should be present in "
- "'migrate-incoming' qmp command ");
+ if (!uri == !channels) {
+ error_setg(errp, "need either 'uri' or 'channels' argument");
return;
- } else if (channels) {
+ }
+
+ if (channels) {
/* To verify that Migrate channel list has only item */
if (channels->next) {
error_setg(errp, "Channel list has more than one entries");
return;
}
addr = channels->value->addr;
- } else if (uri) {
+ }
+
+ if (uri) {
/* caller uses the old URI syntax */
if (!migrate_uri_parse(uri, &channel, errp)) {
return;
}
addr = channel->addr;
- } else {
- error_setg(errp, "neither 'uri' or 'channels' argument are "
- "specified in 'migrate-incoming' qmp command ");
- return;
}
/* transport mechanism not suitable for migration? */
}
if (ret < 0) {
+ MigrationState *s = migrate_get_current();
+
+ if (migrate_has_error(s)) {
+ WITH_QEMU_LOCK_GUARD(&s->error_mutex) {
+ error_report_err(s->error);
+ }
+ }
error_report("load of migration failed: %s", strerror(-ret));
goto fail;
}
/*
* Having preliminary checks for uri and channel
*/
- if (uri && has_channels) {
- error_setg(errp, "'uri' and 'channels' arguments are mutually "
- "exclusive; exactly one of the two should be present in "
- "'migrate' qmp command ");
+ if (!uri == !channels) {
+ error_setg(errp, "need either 'uri' or 'channels' argument");
return;
- } else if (channels) {
+ }
+
+ if (channels) {
/* To verify that Migrate channel list has only item */
if (channels->next) {
error_setg(errp, "Channel list has more than one entries");
return;
}
addr = channels->value->addr;
- } else if (uri) {
+ }
+
+ if (uri) {
/* caller uses the old URI syntax */
if (!migrate_uri_parse(uri, &channel, errp)) {
return;
}
addr = channel->addr;
- } else {
- error_setg(errp, "neither 'uri' or 'channels' argument are "
- "specified in 'migrate' qmp command ");
- return;
}
/* transport mechanism not suitable for migration? */
return msg.id;
}
-static MultiFDPages_t *multifd_pages_init(size_t size)
+static MultiFDPages_t *multifd_pages_init(uint32_t n)
{
MultiFDPages_t *pages = g_new0(MultiFDPages_t, 1);
- pages->allocated = size;
- pages->offset = g_new0(ram_addr_t, size);
+ pages->allocated = n;
+ pages->offset = g_new0(ram_addr_t, n);
return pages;
}
{
pages->num = 0;
pages->allocated = 0;
- pages->packet_num = 0;
pages->block = NULL;
g_free(pages->offset);
pages->offset = NULL;
* false.
*/
-static int multifd_send_pages(QEMUFile *f)
+static int multifd_send_pages(void)
{
int i;
static int next_channel;
return 1;
}
-int multifd_queue_page(QEMUFile *f, RAMBlock *block, ram_addr_t offset)
+int multifd_queue_page(RAMBlock *block, ram_addr_t offset)
{
MultiFDPages_t *pages = multifd_send_state->pages;
bool changed = false;
changed = true;
}
- if (multifd_send_pages(f) < 0) {
+ if (multifd_send_pages() < 0) {
return -1;
}
if (changed) {
- return multifd_queue_page(f, block, offset);
+ return multifd_queue_page(block, offset);
}
return 1;
return ret;
}
-int multifd_send_sync_main(QEMUFile *f)
+int multifd_send_sync_main(void)
{
int i;
bool flush_zero_copy;
return 0;
}
if (multifd_send_state->pages->num) {
- if (multifd_send_pages(f) < 0) {
+ if (multifd_send_pages() < 0) {
error_report("%s: multifd_send_pages fail", __func__);
return -1;
}
bool multifd_recv_all_channels_created(void);
void multifd_recv_new_channel(QIOChannel *ioc, Error **errp);
void multifd_recv_sync_main(void);
-int multifd_send_sync_main(QEMUFile *f);
-int multifd_queue_page(QEMUFile *f, RAMBlock *block, ram_addr_t offset);
+int multifd_send_sync_main(void);
+int multifd_queue_page(RAMBlock *block, ram_addr_t offset);
/* Multifd Compression flags */
#define MULTIFD_FLAG_SYNC (1 << 0)
uint32_t num;
/* number of allocated pages */
uint32_t allocated;
- /* global number of generated multifd packets */
- uint64_t packet_num;
/* offset of each page */
ram_addr_t *offset;
RAMBlock *block;
return pages;
}
-static int ram_save_multifd_page(QEMUFile *file, RAMBlock *block,
- ram_addr_t offset)
+static int ram_save_multifd_page(RAMBlock *block, ram_addr_t offset)
{
- if (multifd_queue_page(file, block, offset) < 0) {
+ if (multifd_queue_page(block, offset) < 0) {
return -1;
}
stat64_add(&mig_stats.normal_pages, 1);
if (migrate_multifd() &&
!migrate_multifd_flush_after_each_section()) {
QEMUFile *f = rs->pss[RAM_CHANNEL_PRECOPY].pss_channel;
- int ret = multifd_send_sync_main(f);
+ int ret = multifd_send_sync_main();
if (ret < 0) {
return ret;
}
* still see partially copied pages which is data corruption.
*/
if (migrate_multifd() && !migration_in_postcopy()) {
- return ram_save_multifd_page(pss->pss_channel, block, offset);
+ return ram_save_multifd_page(block, offset);
}
return ram_save_page(rs, pss);
migration_ops->ram_save_target_page = ram_save_target_page_legacy;
bql_unlock();
- ret = multifd_send_sync_main(f);
+ ret = multifd_send_sync_main();
bql_lock();
if (ret < 0) {
return ret;
if (ret >= 0
&& migration_is_setup_or_active(migrate_get_current()->state)) {
if (migrate_multifd() && migrate_multifd_flush_after_each_section()) {
- ret = multifd_send_sync_main(rs->pss[RAM_CHANNEL_PRECOPY].pss_channel);
+ ret = multifd_send_sync_main();
if (ret < 0) {
return ret;
}
}
}
- ret = multifd_send_sync_main(rs->pss[RAM_CHANNEL_PRECOPY].pss_channel);
+ ret = multifd_send_sync_main();
if (ret < 0) {
return ret;
}
return strs[rdma_control];
}
+#if !defined(htonll)
static uint64_t htonll(uint64_t v)
{
union { uint32_t lv[2]; uint64_t llv; } u;
u.lv[1] = htonl(v & 0xFFFFFFFFULL);
return u.llv;
}
+#endif
+#if !defined(ntohll)
static uint64_t ntohll(uint64_t v)
{
union { uint32_t lv[2]; uint64_t llv; } u;
u.llv = v;
return ((uint64_t)ntohl(u.lv[0]) << 32) | (uint64_t) ntohl(u.lv[1]);
}
+#endif
static void dest_block_to_network(RDMADestBlock *db)
{
+HXCOMM See docs/devel/docs.rst for the format of this file.
+HXCOMM
HXCOMM Keep the list of subcommands sorted by name.
HXCOMM Use DEFHEADING() to define headings in both help text and rST
HXCOMM Text between SRST and ERST are copied to rST version and
+HXCOMM See docs/devel/docs.rst for the format of this file.
+HXCOMM
HXCOMM Use DEFHEADING() to define headings in both help text and rST.
HXCOMM Text between SRST and ERST is copied to the rST version and
HXCOMM discarded from C version.
-Subproject commit 4c6ecda618f2066707f50c53f31419244fd7f77a
+Subproject commit e4eac85880e8677f96d8b9e94de9f2eec9c0751f
[6] = 52,
};
-/* The cpu-specific constant value of PAMax; also used by hw/arm/virt. */
+/*
+ * The cpu-specific constant value of PAMax; also used by hw/arm/virt.
+ * Note that machvirt_init calls this on a CPU that is inited but not realized!
+ */
unsigned int arm_pamax(ARMCPU *cpu)
{
if (arm_feature(&cpu->env, ARM_FEATURE_AARCH64)) {
return pamax_map[parange];
}
- /*
- * In machvirt_init, we call arm_pamax on a cpu that is not fully
- * initialized, so we can't rely on the propagation done in realize.
- */
- if (arm_feature(&cpu->env, ARM_FEATURE_LPAE) ||
- arm_feature(&cpu->env, ARM_FEATURE_V7VE)) {
- /* v7 with LPAE */
+ if (arm_feature(&cpu->env, ARM_FEATURE_LPAE)) {
+ /* v7 or v8 with LPAE */
return 40;
}
/* Anything else */
CPUHPPAState *env = &cpu->env;
cs->exception_index = EXCP_UNALIGN;
- if (env->psw & PSW_Q) {
- /* ??? Needs tweaking for hppa64. */
- env->cr[CR_IOR] = addr;
- env->cr[CR_ISR] = addr >> 32;
- }
+ hppa_set_ior_and_isr(env, addr, MMU_IDX_MMU_DISABLED(mmu_idx));
cpu_loop_exit_restore(cs, retaddr);
}
#ifndef CONFIG_USER_ONLY
void hppa_ptlbe(CPUHPPAState *env);
hwaddr hppa_cpu_get_phys_page_debug(CPUState *cs, vaddr addr);
+void hppa_set_ior_and_isr(CPUHPPAState *env, vaddr addr, bool mmu_disabled);
bool hppa_cpu_tlb_fill(CPUState *cs, vaddr address, int size,
MMUAccessType access_type, int mmu_idx,
bool probe, uintptr_t retaddr);
/* I/O address space */
addr = (int32_t)addr;
} else {
- /* PDC address space */
- addr &= MAKE_64BIT_MASK(0, 24);
+ /*
+ * PDC address space:
+ * Figures H-10 and H-11 of the parisc2.0 spec do not specify
+ * where to map into the 64-bit PDC address space.
+ * We map with an offset which equals the 32-bit address, which
+ * is what can be seen on physical machines too.
+ */
+ addr = (uint32_t)addr;
addr |= -1ull << (TARGET_PHYS_ADDR_SPACE_BITS - 4);
}
return addr;
return excp == EXCP_DTLB_MISS ? -1 : phys;
}
-G_NORETURN static void
-raise_exception_with_ior(CPUHPPAState *env, int excp, uintptr_t retaddr,
- vaddr addr, bool mmu_disabled)
+void hppa_set_ior_and_isr(CPUHPPAState *env, vaddr addr, bool mmu_disabled)
{
- CPUState *cs = env_cpu(env);
-
- cs->exception_index = excp;
-
if (env->psw & PSW_Q) {
/*
* For pa1.x, the offset and space never overlap, and so we
*/
uint64_t b;
- cpu_restore_state(cs, retaddr);
-
- b = env->gr[env->unwind_breg];
+ b = env->unwind_breg ? env->gr[env->unwind_breg] : 0;
b >>= (env->psw & PSW_W ? 62 : 30);
env->cr[CR_IOR] |= b << 62;
-
- cpu_loop_exit(cs);
}
}
}
+}
+
+G_NORETURN static void
+raise_exception_with_ior(CPUHPPAState *env, int excp, uintptr_t retaddr,
+ vaddr addr, bool mmu_disabled)
+{
+ CPUState *cs = env_cpu(env);
+
+ cs->exception_index = excp;
+ hppa_set_ior_and_isr(env, addr, mmu_disabled);
+
cpu_loop_exit_restore(cs, retaddr);
}
excp = hppa_get_physical_address(env, addr, mmu_idx, 0, &phys,
&prot, NULL);
if (excp >= 0) {
- if (env->psw & PSW_Q) {
- /* ??? Needs tweaking for hppa64. */
- env->cr[CR_IOR] = addr;
- env->cr[CR_ISR] = addr >> 32;
- }
+ hppa_set_ior_and_isr(env, addr, MMU_IDX_MMU_DISABLED(mmu_idx));
if (excp == EXCP_DTLB_MISS) {
excp = EXCP_NA_DTLB_MISS;
}
deps = ["xorriso", "mformat"] # dependent tools needed in the test setup/box.
supported_platforms = ['x86_64'] # supported test platforms.
+# default timeout of 120 secs is sometimes not enough for bits test.
+BITS_TIMEOUT = 200
def which(tool):
""" looks up the full path for @tool, returns None if not found
"""
# in slower systems the test can take as long as 3 minutes to complete.
- timeout = 200
+ timeout = BITS_TIMEOUT
def __init__(self, *args, **kwargs):
super().__init__(*args, **kwargs)
# biosbits has been configured to run all the specified test suites
# in batch mode and then automatically initiate a vm shutdown.
- # Rely on avocado's unit test timeout.
- self._vm.event_wait('SHUTDOWN')
+ # Set timeout to BITS_TIMEOUT for SHUTDOWN event from bits VM at par
+ # with the avocado test timeout.
+ self._vm.event_wait('SHUTDOWN', timeout=BITS_TIMEOUT)
self._vm.wait(timeout=None)
self.parse_log()
'device-introspect-test' : 720,
'migration-test' : 480,
'npcm7xx_pwm-test': 300,
+ 'npcm7xx_watchdog_timer-test': 120,
'qom-test' : 900,
'test-hmp' : 240,
'pxe-test': 600,
'prom-env-test': 360,
- 'boot-serial-test': 180,
+ 'boot-serial-test': 240,
'qos-test': 120,
}
['aspeed_hace-test',
'aspeed_smc-test',
'aspeed_gpio-test']
+
+qtests_stm32l4x5 = \
+ ['stm32l4x5_exti-test',
+ 'stm32l4x5_syscfg-test']
+
qtests_arm = \
(config_all_devices.has_key('CONFIG_MPS2') ? ['sse-timer-test'] : []) + \
(config_all_devices.has_key('CONFIG_CMSDK_APB_DUALTIMER') ? ['cmsdk-apb-dualtimer-test'] : []) + \
(config_all_devices.has_key('CONFIG_TPM_TIS_I2C') ? ['tpm-tis-i2c-test'] : []) + \
(config_all_devices.has_key('CONFIG_VEXPRESS') ? ['test-arm-mptimer'] : []) + \
(config_all_devices.has_key('CONFIG_MICROBIT') ? ['microbit-test'] : []) + \
+ (config_all_devices.has_key('CONFIG_STM32L4X5_SOC') ? qtests_stm32l4x5 : []) + \
['arm-cpu-features',
'boot-serial-test']
rsp = qtest_qmp(to, "{ 'execute': 'migrate-incoming', 'arguments': %p}",
args);
+
+ if (!qdict_haskey(rsp, "return")) {
+ g_autoptr(GString) s = qobject_to_json_pretty(QOBJECT(rsp), true);
+ g_test_message("%s", s->str);
+ }
+
g_assert(qdict_haskey(rsp, "return"));
qobject_unref(rsp);
return find_common_machine_version(machine_name, var1, var2);
}
+
+typedef struct {
+ char *name;
+ void (*func)(void);
+} MigrationTest;
+
+static void migration_test_destroy(gpointer data)
+{
+ MigrationTest *test = (MigrationTest *)data;
+
+ g_free(test->name);
+ g_free(test);
+}
+
+static void migration_test_wrapper(const void *data)
+{
+ MigrationTest *test = (MigrationTest *)data;
+
+ g_test_message("Running /%s%s", qtest_get_arch(), test->name);
+ test->func();
+}
+
+void migration_test_add(const char *path, void (*fn)(void))
+{
+ MigrationTest *test = g_new0(MigrationTest, 1);
+
+ test->func = fn;
+ test->name = g_strdup(path);
+
+ qtest_add_data_func_full(path, test, migration_test_wrapper,
+ migration_test_destroy);
+}
const char *var2);
char *resolve_machine_version(const char *alias, const char *var1,
const char *var2);
+void migration_test_add(const char *path, void (*fn)(void));
#endif /* MIGRATION_HELPERS_H */
module_call_init(MODULE_INIT_QOM);
if (is_x86) {
- qtest_add_func("/migration/precopy/unix/suspend/live",
- test_precopy_unix_suspend_live);
- qtest_add_func("/migration/precopy/unix/suspend/notlive",
- test_precopy_unix_suspend_notlive);
+ migration_test_add("/migration/precopy/unix/suspend/live",
+ test_precopy_unix_suspend_live);
+ migration_test_add("/migration/precopy/unix/suspend/notlive",
+ test_precopy_unix_suspend_notlive);
}
if (has_uffd) {
- qtest_add_func("/migration/postcopy/plain", test_postcopy);
- qtest_add_func("/migration/postcopy/recovery/plain",
- test_postcopy_recovery);
- qtest_add_func("/migration/postcopy/preempt/plain", test_postcopy_preempt);
- qtest_add_func("/migration/postcopy/preempt/recovery/plain",
- test_postcopy_preempt_recovery);
+ migration_test_add("/migration/postcopy/plain", test_postcopy);
+ migration_test_add("/migration/postcopy/recovery/plain",
+ test_postcopy_recovery);
+ migration_test_add("/migration/postcopy/preempt/plain",
+ test_postcopy_preempt);
+ migration_test_add("/migration/postcopy/preempt/recovery/plain",
+ test_postcopy_preempt_recovery);
if (getenv("QEMU_TEST_FLAKY_TESTS")) {
- qtest_add_func("/migration/postcopy/compress/plain",
- test_postcopy_compress);
- qtest_add_func("/migration/postcopy/recovery/compress/plain",
- test_postcopy_recovery_compress);
+ migration_test_add("/migration/postcopy/compress/plain",
+ test_postcopy_compress);
+ migration_test_add("/migration/postcopy/recovery/compress/plain",
+ test_postcopy_recovery_compress);
}
#ifndef _WIN32
- qtest_add_func("/migration/postcopy/recovery/double-failures",
- test_postcopy_recovery_double_fail);
+ migration_test_add("/migration/postcopy/recovery/double-failures",
+ test_postcopy_recovery_double_fail);
#endif /* _WIN32 */
if (is_x86) {
- qtest_add_func("/migration/postcopy/suspend",
- test_postcopy_suspend);
+ migration_test_add("/migration/postcopy/suspend",
+ test_postcopy_suspend);
}
}
- qtest_add_func("/migration/bad_dest", test_baddest);
+ migration_test_add("/migration/bad_dest", test_baddest);
#ifndef _WIN32
- qtest_add_func("/migration/analyze-script", test_analyze_script);
+ if (!g_str_equal(arch, "s390x")) {
+ migration_test_add("/migration/analyze-script", test_analyze_script);
+ }
#endif
- qtest_add_func("/migration/precopy/unix/plain", test_precopy_unix_plain);
- qtest_add_func("/migration/precopy/unix/xbzrle", test_precopy_unix_xbzrle);
+ migration_test_add("/migration/precopy/unix/plain",
+ test_precopy_unix_plain);
+ migration_test_add("/migration/precopy/unix/xbzrle",
+ test_precopy_unix_xbzrle);
/*
* Compression fails from time to time.
* Put test here but don't enable it until everything is fixed.
*/
if (getenv("QEMU_TEST_FLAKY_TESTS")) {
- qtest_add_func("/migration/precopy/unix/compress/wait",
- test_precopy_unix_compress);
- qtest_add_func("/migration/precopy/unix/compress/nowait",
- test_precopy_unix_compress_nowait);
+ migration_test_add("/migration/precopy/unix/compress/wait",
+ test_precopy_unix_compress);
+ migration_test_add("/migration/precopy/unix/compress/nowait",
+ test_precopy_unix_compress_nowait);
}
- qtest_add_func("/migration/precopy/file",
- test_precopy_file);
- qtest_add_func("/migration/precopy/file/offset",
- test_precopy_file_offset);
- qtest_add_func("/migration/precopy/file/offset/bad",
- test_precopy_file_offset_bad);
+ migration_test_add("/migration/precopy/file",
+ test_precopy_file);
+ migration_test_add("/migration/precopy/file/offset",
+ test_precopy_file_offset);
+ migration_test_add("/migration/precopy/file/offset/bad",
+ test_precopy_file_offset_bad);
/*
* Our CI system has problems with shared memory.
* Don't run this test until we find a workaround.
*/
if (getenv("QEMU_TEST_FLAKY_TESTS")) {
- qtest_add_func("/migration/mode/reboot", test_mode_reboot);
+ migration_test_add("/migration/mode/reboot", test_mode_reboot);
}
#ifdef CONFIG_GNUTLS
- qtest_add_func("/migration/precopy/unix/tls/psk",
- test_precopy_unix_tls_psk);
+ migration_test_add("/migration/precopy/unix/tls/psk",
+ test_precopy_unix_tls_psk);
if (has_uffd) {
/*
* channels are tested under precopy. Here what we want to test is the
* general postcopy path that has TLS channel enabled.
*/
- qtest_add_func("/migration/postcopy/tls/psk", test_postcopy_tls_psk);
- qtest_add_func("/migration/postcopy/recovery/tls/psk",
- test_postcopy_recovery_tls_psk);
- qtest_add_func("/migration/postcopy/preempt/tls/psk",
- test_postcopy_preempt_tls_psk);
- qtest_add_func("/migration/postcopy/preempt/recovery/tls/psk",
- test_postcopy_preempt_all);
+ migration_test_add("/migration/postcopy/tls/psk",
+ test_postcopy_tls_psk);
+ migration_test_add("/migration/postcopy/recovery/tls/psk",
+ test_postcopy_recovery_tls_psk);
+ migration_test_add("/migration/postcopy/preempt/tls/psk",
+ test_postcopy_preempt_tls_psk);
+ migration_test_add("/migration/postcopy/preempt/recovery/tls/psk",
+ test_postcopy_preempt_all);
}
#ifdef CONFIG_TASN1
- qtest_add_func("/migration/precopy/unix/tls/x509/default-host",
- test_precopy_unix_tls_x509_default_host);
- qtest_add_func("/migration/precopy/unix/tls/x509/override-host",
- test_precopy_unix_tls_x509_override_host);
+ migration_test_add("/migration/precopy/unix/tls/x509/default-host",
+ test_precopy_unix_tls_x509_default_host);
+ migration_test_add("/migration/precopy/unix/tls/x509/override-host",
+ test_precopy_unix_tls_x509_override_host);
#endif /* CONFIG_TASN1 */
#endif /* CONFIG_GNUTLS */
- qtest_add_func("/migration/precopy/tcp/plain", test_precopy_tcp_plain);
+ migration_test_add("/migration/precopy/tcp/plain", test_precopy_tcp_plain);
- qtest_add_func("/migration/precopy/tcp/plain/switchover-ack",
- test_precopy_tcp_switchover_ack);
+ migration_test_add("/migration/precopy/tcp/plain/switchover-ack",
+ test_precopy_tcp_switchover_ack);
#ifdef CONFIG_GNUTLS
- qtest_add_func("/migration/precopy/tcp/tls/psk/match",
- test_precopy_tcp_tls_psk_match);
- qtest_add_func("/migration/precopy/tcp/tls/psk/mismatch",
- test_precopy_tcp_tls_psk_mismatch);
+ migration_test_add("/migration/precopy/tcp/tls/psk/match",
+ test_precopy_tcp_tls_psk_match);
+ migration_test_add("/migration/precopy/tcp/tls/psk/mismatch",
+ test_precopy_tcp_tls_psk_mismatch);
#ifdef CONFIG_TASN1
- qtest_add_func("/migration/precopy/tcp/tls/x509/default-host",
- test_precopy_tcp_tls_x509_default_host);
- qtest_add_func("/migration/precopy/tcp/tls/x509/override-host",
- test_precopy_tcp_tls_x509_override_host);
- qtest_add_func("/migration/precopy/tcp/tls/x509/mismatch-host",
- test_precopy_tcp_tls_x509_mismatch_host);
- qtest_add_func("/migration/precopy/tcp/tls/x509/friendly-client",
- test_precopy_tcp_tls_x509_friendly_client);
- qtest_add_func("/migration/precopy/tcp/tls/x509/hostile-client",
- test_precopy_tcp_tls_x509_hostile_client);
- qtest_add_func("/migration/precopy/tcp/tls/x509/allow-anon-client",
- test_precopy_tcp_tls_x509_allow_anon_client);
- qtest_add_func("/migration/precopy/tcp/tls/x509/reject-anon-client",
- test_precopy_tcp_tls_x509_reject_anon_client);
+ migration_test_add("/migration/precopy/tcp/tls/x509/default-host",
+ test_precopy_tcp_tls_x509_default_host);
+ migration_test_add("/migration/precopy/tcp/tls/x509/override-host",
+ test_precopy_tcp_tls_x509_override_host);
+ migration_test_add("/migration/precopy/tcp/tls/x509/mismatch-host",
+ test_precopy_tcp_tls_x509_mismatch_host);
+ migration_test_add("/migration/precopy/tcp/tls/x509/friendly-client",
+ test_precopy_tcp_tls_x509_friendly_client);
+ migration_test_add("/migration/precopy/tcp/tls/x509/hostile-client",
+ test_precopy_tcp_tls_x509_hostile_client);
+ migration_test_add("/migration/precopy/tcp/tls/x509/allow-anon-client",
+ test_precopy_tcp_tls_x509_allow_anon_client);
+ migration_test_add("/migration/precopy/tcp/tls/x509/reject-anon-client",
+ test_precopy_tcp_tls_x509_reject_anon_client);
#endif /* CONFIG_TASN1 */
#endif /* CONFIG_GNUTLS */
- /* qtest_add_func("/migration/ignore_shared", test_ignore_shared); */
+ /* migration_test_add("/migration/ignore_shared", test_ignore_shared); */
#ifndef _WIN32
- qtest_add_func("/migration/fd_proto", test_migrate_fd_proto);
+ migration_test_add("/migration/fd_proto", test_migrate_fd_proto);
#endif
- qtest_add_func("/migration/validate_uuid", test_validate_uuid);
- qtest_add_func("/migration/validate_uuid_error", test_validate_uuid_error);
- qtest_add_func("/migration/validate_uuid_src_not_set",
- test_validate_uuid_src_not_set);
- qtest_add_func("/migration/validate_uuid_dst_not_set",
- test_validate_uuid_dst_not_set);
+ migration_test_add("/migration/validate_uuid", test_validate_uuid);
+ migration_test_add("/migration/validate_uuid_error",
+ test_validate_uuid_error);
+ migration_test_add("/migration/validate_uuid_src_not_set",
+ test_validate_uuid_src_not_set);
+ migration_test_add("/migration/validate_uuid_dst_not_set",
+ test_validate_uuid_dst_not_set);
/*
* See explanation why this test is slow on function definition
*/
if (g_test_slow()) {
- qtest_add_func("/migration/auto_converge", test_migrate_auto_converge);
+ migration_test_add("/migration/auto_converge",
+ test_migrate_auto_converge);
if (g_str_equal(arch, "x86_64") &&
has_kvm && kvm_dirty_ring_supported()) {
- qtest_add_func("/migration/dirty_limit", test_migrate_dirty_limit);
+ migration_test_add("/migration/dirty_limit",
+ test_migrate_dirty_limit);
}
}
- qtest_add_func("/migration/multifd/tcp/plain/none",
- test_multifd_tcp_none);
- /*
- * This test is flaky and sometimes fails in CI and otherwise:
- * don't run unless user opts in via environment variable.
- */
- if (getenv("QEMU_TEST_FLAKY_TESTS")) {
- qtest_add_func("/migration/multifd/tcp/plain/cancel",
+ migration_test_add("/migration/multifd/tcp/plain/none",
+ test_multifd_tcp_none);
+ migration_test_add("/migration/multifd/tcp/plain/cancel",
test_multifd_tcp_cancel);
- }
- qtest_add_func("/migration/multifd/tcp/plain/zlib",
- test_multifd_tcp_zlib);
+ migration_test_add("/migration/multifd/tcp/plain/zlib",
+ test_multifd_tcp_zlib);
#ifdef CONFIG_ZSTD
- qtest_add_func("/migration/multifd/tcp/plain/zstd",
- test_multifd_tcp_zstd);
+ migration_test_add("/migration/multifd/tcp/plain/zstd",
+ test_multifd_tcp_zstd);
#endif
#ifdef CONFIG_GNUTLS
- qtest_add_func("/migration/multifd/tcp/tls/psk/match",
- test_multifd_tcp_tls_psk_match);
- qtest_add_func("/migration/multifd/tcp/tls/psk/mismatch",
- test_multifd_tcp_tls_psk_mismatch);
+ migration_test_add("/migration/multifd/tcp/tls/psk/match",
+ test_multifd_tcp_tls_psk_match);
+ migration_test_add("/migration/multifd/tcp/tls/psk/mismatch",
+ test_multifd_tcp_tls_psk_mismatch);
#ifdef CONFIG_TASN1
- qtest_add_func("/migration/multifd/tcp/tls/x509/default-host",
- test_multifd_tcp_tls_x509_default_host);
- qtest_add_func("/migration/multifd/tcp/tls/x509/override-host",
- test_multifd_tcp_tls_x509_override_host);
- qtest_add_func("/migration/multifd/tcp/tls/x509/mismatch-host",
- test_multifd_tcp_tls_x509_mismatch_host);
- qtest_add_func("/migration/multifd/tcp/tls/x509/allow-anon-client",
- test_multifd_tcp_tls_x509_allow_anon_client);
- qtest_add_func("/migration/multifd/tcp/tls/x509/reject-anon-client",
- test_multifd_tcp_tls_x509_reject_anon_client);
+ migration_test_add("/migration/multifd/tcp/tls/x509/default-host",
+ test_multifd_tcp_tls_x509_default_host);
+ migration_test_add("/migration/multifd/tcp/tls/x509/override-host",
+ test_multifd_tcp_tls_x509_override_host);
+ migration_test_add("/migration/multifd/tcp/tls/x509/mismatch-host",
+ test_multifd_tcp_tls_x509_mismatch_host);
+ migration_test_add("/migration/multifd/tcp/tls/x509/allow-anon-client",
+ test_multifd_tcp_tls_x509_allow_anon_client);
+ migration_test_add("/migration/multifd/tcp/tls/x509/reject-anon-client",
+ test_multifd_tcp_tls_x509_reject_anon_client);
#endif /* CONFIG_TASN1 */
#endif /* CONFIG_GNUTLS */
if (g_str_equal(arch, "x86_64") && has_kvm && kvm_dirty_ring_supported()) {
- qtest_add_func("/migration/dirty_ring",
- test_precopy_unix_dirty_ring);
- qtest_add_func("/migration/vcpu_dirty_limit",
- test_vcpu_dirty_limit);
+ migration_test_add("/migration/dirty_ring",
+ test_precopy_unix_dirty_ring);
+ migration_test_add("/migration/vcpu_dirty_limit",
+ test_vcpu_dirty_limit);
}
ret = g_test_run();
static void test_prescaler(gconstpointer watchdog)
{
const Watchdog *wd = watchdog;
+ int inc = g_test_quick() ? 3 : 1;
- for (int wtclk = 0; wtclk < 4; ++wtclk) {
- for (int wtis = 0; wtis < 4; ++wtis) {
+ for (int wtclk = 0; wtclk < 4; wtclk += inc) {
+ for (int wtis = 0; wtis < 4; wtis += inc) {
QTestState *qts = qtest_init("-machine quanta-gsj");
qtest_irq_intercept_in(qts, "/machine/soc/a9mpcore/gic");
--- /dev/null
+/*
+ * QTest testcase for STM32L4x5_EXTI
+ *
+ * Copyright (c) 2023 Arnaud Minier <arnaud.minier@telecom-paris.fr>
+ * Copyright (c) 2023 Inès Varhol <ines.varhol@telecom-paris.fr>
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#include "qemu/osdep.h"
+#include "libqtest-single.h"
+
+#define EXTI_BASE_ADDR 0x40010400
+#define EXTI_IMR1 0x00
+#define EXTI_EMR1 0x04
+#define EXTI_RTSR1 0x08
+#define EXTI_FTSR1 0x0C
+#define EXTI_SWIER1 0x10
+#define EXTI_PR1 0x14
+#define EXTI_IMR2 0x20
+#define EXTI_EMR2 0x24
+#define EXTI_RTSR2 0x28
+#define EXTI_FTSR2 0x2C
+#define EXTI_SWIER2 0x30
+#define EXTI_PR2 0x34
+
+#define NVIC_ISER 0xE000E100
+#define NVIC_ISPR 0xE000E200
+#define NVIC_ICPR 0xE000E280
+
+#define EXTI0_IRQ 6
+#define EXTI1_IRQ 7
+#define EXTI35_IRQ 1
+
+static void enable_nvic_irq(unsigned int n)
+{
+ writel(NVIC_ISER, 1 << n);
+}
+
+static void unpend_nvic_irq(unsigned int n)
+{
+ writel(NVIC_ICPR, 1 << n);
+}
+
+static bool check_nvic_pending(unsigned int n)
+{
+ return readl(NVIC_ISPR) & (1 << n);
+}
+
+static void exti_writel(unsigned int offset, uint32_t value)
+{
+ writel(EXTI_BASE_ADDR + offset, value);
+}
+
+static uint32_t exti_readl(unsigned int offset)
+{
+ return readl(EXTI_BASE_ADDR + offset);
+}
+
+static void exti_set_irq(int num, int level)
+{
+ qtest_set_irq_in(global_qtest, "/machine/soc/exti", NULL,
+ num, level);
+}
+
+static void test_reg_write_read(void)
+{
+ /* Test that non-reserved bits in xMR and xTSR can be set and cleared */
+
+ exti_writel(EXTI_IMR1, 0xFFFFFFFF);
+ g_assert_cmpuint(exti_readl(EXTI_IMR1), ==, 0xFFFFFFFF);
+ exti_writel(EXTI_IMR1, 0x00000000);
+ g_assert_cmpuint(exti_readl(EXTI_IMR1), ==, 0x00000000);
+
+ exti_writel(EXTI_EMR1, 0xFFFFFFFF);
+ g_assert_cmpuint(exti_readl(EXTI_EMR1), ==, 0xFFFFFFFF);
+ exti_writel(EXTI_EMR1, 0x00000000);
+ g_assert_cmpuint(exti_readl(EXTI_EMR1), ==, 0x00000000);
+
+ exti_writel(EXTI_RTSR1, 0xFFFFFFFF);
+ g_assert_cmpuint(exti_readl(EXTI_RTSR1), ==, 0x007DFFFF);
+ exti_writel(EXTI_RTSR1, 0x00000000);
+ g_assert_cmpuint(exti_readl(EXTI_RTSR1), ==, 0x00000000);
+
+ exti_writel(EXTI_FTSR1, 0xFFFFFFFF);
+ g_assert_cmpuint(exti_readl(EXTI_FTSR1), ==, 0x007DFFFF);
+ exti_writel(EXTI_FTSR1, 0x00000000);
+ g_assert_cmpuint(exti_readl(EXTI_FTSR1), ==, 0x00000000);
+
+ exti_writel(EXTI_IMR2, 0xFFFFFFFF);
+ g_assert_cmpuint(exti_readl(EXTI_IMR2), ==, 0x000000FF);
+ exti_writel(EXTI_IMR2, 0x00000000);
+ g_assert_cmpuint(exti_readl(EXTI_IMR2), ==, 0x00000000);
+
+ exti_writel(EXTI_EMR2, 0xFFFFFFFF);
+ g_assert_cmpuint(exti_readl(EXTI_EMR2), ==, 0x000000FF);
+ exti_writel(EXTI_EMR2, 0x00000000);
+ g_assert_cmpuint(exti_readl(EXTI_EMR2), ==, 0x00000000);
+
+ exti_writel(EXTI_RTSR2, 0xFFFFFFFF);
+ g_assert_cmpuint(exti_readl(EXTI_RTSR2), ==, 0x00000078);
+ exti_writel(EXTI_RTSR2, 0x00000000);
+ g_assert_cmpuint(exti_readl(EXTI_RTSR2), ==, 0x00000000);
+
+ exti_writel(EXTI_FTSR2, 0xFFFFFFFF);
+ g_assert_cmpuint(exti_readl(EXTI_FTSR2), ==, 0x00000078);
+ exti_writel(EXTI_FTSR2, 0x00000000);
+ g_assert_cmpuint(exti_readl(EXTI_FTSR2), ==, 0x00000000);
+}
+
+static void test_direct_lines_write(void)
+{
+ /* Test that direct lines reserved bits are not written to */
+
+ exti_writel(EXTI_RTSR1, 0xFF820000);
+ g_assert_cmpuint(exti_readl(EXTI_RTSR1), ==, 0x00000000);
+
+ exti_writel(EXTI_FTSR1, 0xFF820000);
+ g_assert_cmpuint(exti_readl(EXTI_FTSR1), ==, 0x00000000);
+
+ exti_writel(EXTI_SWIER1, 0xFF820000);
+ g_assert_cmpuint(exti_readl(EXTI_SWIER1), ==, 0x00000000);
+
+ exti_writel(EXTI_PR1, 0xFF820000);
+ g_assert_cmpuint(exti_readl(EXTI_PR1), ==, 0x00000000);
+
+ exti_writel(EXTI_RTSR2, 0x00000087);
+ g_assert_cmpuint(exti_readl(EXTI_RTSR2), ==, 0x00000000);
+
+ exti_writel(EXTI_FTSR2, 0x00000087);
+ g_assert_cmpuint(exti_readl(EXTI_FTSR2), ==, 0x00000000);
+
+ exti_writel(EXTI_SWIER2, 0x00000087);
+ g_assert_cmpuint(exti_readl(EXTI_SWIER2), ==, 0x00000000);
+
+ exti_writel(EXTI_PR2, 0x00000087);
+ g_assert_cmpuint(exti_readl(EXTI_PR2), ==, 0x00000000);
+}
+
+static void test_reserved_bits_write(void)
+{
+ /* Test that reserved bits stay are not written to */
+
+ exti_writel(EXTI_IMR2, 0xFFFFFF00);
+ g_assert_cmpuint(exti_readl(EXTI_IMR2), ==, 0x00000000);
+
+ exti_writel(EXTI_EMR2, 0xFFFFFF00);
+ g_assert_cmpuint(exti_readl(EXTI_EMR2), ==, 0x00000000);
+
+ exti_writel(EXTI_RTSR2, 0xFFFFFF00);
+ g_assert_cmpuint(exti_readl(EXTI_RTSR2), ==, 0x00000000);
+
+ exti_writel(EXTI_FTSR2, 0xFFFFFF00);
+ g_assert_cmpuint(exti_readl(EXTI_FTSR2), ==, 0x00000000);
+
+ exti_writel(EXTI_SWIER2, 0xFFFFFF00);
+ g_assert_cmpuint(exti_readl(EXTI_SWIER2), ==, 0x00000000);
+
+ exti_writel(EXTI_PR2, 0xFFFFFF00);
+ g_assert_cmpuint(exti_readl(EXTI_PR2), ==, 0x00000000);
+}
+
+static void test_software_interrupt(void)
+{
+ /*
+ * Test that we can launch a software irq by :
+ * - enabling its line in IMR
+ * - and then setting a bit from '0' to '1' in SWIER
+ *
+ * And that the interruption stays pending in NVIC
+ * even after clearing the pending bit in PR.
+ */
+
+ /*
+ * Testing interrupt line EXTI0
+ * Bit 0 in EXTI_*1 registers (EXTI0) corresponds to GPIO Px_0
+ */
+
+ enable_nvic_irq(EXTI0_IRQ);
+ /* Check that there are no interrupts already pending in PR */
+ g_assert_cmpuint(exti_readl(EXTI_PR1), ==, 0x00000000);
+ /* Check that this specific interrupt isn't pending in NVIC */
+ g_assert_false(check_nvic_pending(EXTI0_IRQ));
+
+ /* Enable interrupt line EXTI0 */
+ exti_writel(EXTI_IMR1, 0x00000001);
+ /* Set the right SWIER bit from '0' to '1' */
+ exti_writel(EXTI_SWIER1, 0x00000000);
+ exti_writel(EXTI_SWIER1, 0x00000001);
+
+ /* Check that the write in SWIER was effective */
+ g_assert_cmpuint(exti_readl(EXTI_SWIER1), ==, 0x00000001);
+ /* Check that the corresponding pending bit in PR is set */
+ g_assert_cmpuint(exti_readl(EXTI_PR1), ==, 0x00000001);
+ /* Check that the corresponding interrupt is pending in the NVIC */
+ g_assert_true(check_nvic_pending(EXTI0_IRQ));
+
+ /* Clear the pending bit in PR */
+ exti_writel(EXTI_PR1, 0x00000001);
+
+ /* Check that the write in PR was effective */
+ g_assert_cmpuint(exti_readl(EXTI_PR1), ==, 0x00000000);
+ /* Check that the corresponding bit in SWIER was cleared */
+ g_assert_cmpuint(exti_readl(EXTI_SWIER1), ==, 0x00000000);
+ /* Check that the interrupt is still pending in the NVIC */
+ g_assert_true(check_nvic_pending(EXTI0_IRQ));
+
+ /*
+ * Testing interrupt line EXTI35
+ * Bit 3 in EXTI_*2 registers (EXTI35) corresponds to PVM 1 Wakeup
+ */
+
+ enable_nvic_irq(EXTI35_IRQ);
+ /* Check that there are no interrupts already pending */
+ g_assert_cmpuint(exti_readl(EXTI_PR2), ==, 0x00000000);
+ g_assert_false(check_nvic_pending(EXTI35_IRQ));
+
+ /* Enable interrupt line EXTI0 */
+ exti_writel(EXTI_IMR2, 0x00000008);
+ /* Set the right SWIER bit from '0' to '1' */
+ exti_writel(EXTI_SWIER2, 0x00000000);
+ exti_writel(EXTI_SWIER2, 0x00000008);
+
+ /* Check that the write in SWIER was effective */
+ g_assert_cmpuint(exti_readl(EXTI_SWIER2), ==, 0x00000008);
+ /* Check that the corresponding pending bit in PR is set */
+ g_assert_cmpuint(exti_readl(EXTI_PR2), ==, 0x00000008);
+ /* Check that the corresponding interrupt is pending in the NVIC */
+ g_assert_true(check_nvic_pending(EXTI35_IRQ));
+
+ /* Clear the pending bit in PR */
+ exti_writel(EXTI_PR2, 0x00000008);
+
+ /* Check that the write in PR was effective */
+ g_assert_cmpuint(exti_readl(EXTI_PR2), ==, 0x00000000);
+ /* Check that the corresponding bit in SWIER was cleared */
+ g_assert_cmpuint(exti_readl(EXTI_SWIER2), ==, 0x00000000);
+ /* Check that the interrupt is still pending in the NVIC */
+ g_assert_true(check_nvic_pending(EXTI35_IRQ));
+
+ /* Clean NVIC */
+ unpend_nvic_irq(EXTI0_IRQ);
+ g_assert_false(check_nvic_pending(EXTI0_IRQ));
+ unpend_nvic_irq(EXTI35_IRQ);
+ g_assert_false(check_nvic_pending(EXTI35_IRQ));
+}
+
+static void test_edge_selector(void)
+{
+ enable_nvic_irq(EXTI0_IRQ);
+
+ /* Configure EXTI line 0 irq on rising edge */
+ exti_set_irq(0, 1);
+ exti_writel(EXTI_IMR1, 0x00000001);
+ exti_writel(EXTI_RTSR1, 0x00000001);
+ exti_writel(EXTI_FTSR1, 0x00000000);
+
+ /* Test that an irq is raised on rising edge only */
+ exti_set_irq(0, 0);
+ g_assert_cmpuint(exti_readl(EXTI_PR1), ==, 0x00000000);
+ g_assert_false(check_nvic_pending(EXTI0_IRQ));
+
+ exti_set_irq(0, 1);
+ g_assert_cmpuint(exti_readl(EXTI_PR1), ==, 0x00000001);
+ g_assert_true(check_nvic_pending(EXTI0_IRQ));
+
+ /* Clean the test */
+ exti_writel(EXTI_PR1, 0x00000001);
+ g_assert_cmpuint(exti_readl(EXTI_PR1), ==, 0x00000000);
+ unpend_nvic_irq(EXTI0_IRQ);
+ g_assert_false(check_nvic_pending(EXTI0_IRQ));
+
+ /* Configure EXTI line 0 irq on falling edge */
+ exti_set_irq(0, 0);
+ exti_writel(EXTI_IMR1, 0x00000001);
+ exti_writel(EXTI_RTSR1, 0x00000000);
+ exti_writel(EXTI_FTSR1, 0x00000001);
+
+ /* Test that an irq is raised on falling edge only */
+ exti_set_irq(0, 1);
+ g_assert_cmpuint(exti_readl(EXTI_PR1), ==, 0x00000000);
+ g_assert_false(check_nvic_pending(EXTI0_IRQ));
+
+ exti_set_irq(0, 0);
+ g_assert_cmpuint(exti_readl(EXTI_PR1), ==, 0x00000001);
+ g_assert_true(check_nvic_pending(EXTI0_IRQ));
+
+ /* Clean the test */
+ exti_writel(EXTI_PR1, 0x00000001);
+ g_assert_cmpuint(exti_readl(EXTI_PR1), ==, 0x00000000);
+ unpend_nvic_irq(EXTI0_IRQ);
+ g_assert_false(check_nvic_pending(EXTI0_IRQ));
+
+ /* Configure EXTI line 0 irq on falling and rising edge */
+ exti_writel(EXTI_IMR1, 0x00000001);
+ exti_writel(EXTI_RTSR1, 0x00000001);
+ exti_writel(EXTI_FTSR1, 0x00000001);
+
+ /* Test that an irq is raised on rising edge */
+ exti_set_irq(0, 1);
+ g_assert_cmpuint(exti_readl(EXTI_PR1), ==, 0x00000001);
+ g_assert_true(check_nvic_pending(EXTI0_IRQ));
+
+ /* Clean the test */
+ exti_writel(EXTI_PR1, 0x00000001);
+ g_assert_cmpuint(exti_readl(EXTI_PR1), ==, 0x00000000);
+ unpend_nvic_irq(EXTI0_IRQ);
+ g_assert_false(check_nvic_pending(EXTI0_IRQ));
+
+ /* Test that an irq is raised on falling edge */
+ exti_set_irq(0, 0);
+ g_assert_cmpuint(exti_readl(EXTI_PR1), ==, 0x00000001);
+ g_assert_true(check_nvic_pending(EXTI0_IRQ));
+
+ /* Clean the test */
+ exti_writel(EXTI_PR1, 0x00000001);
+ g_assert_cmpuint(exti_readl(EXTI_PR1), ==, 0x00000000);
+ unpend_nvic_irq(EXTI0_IRQ);
+ g_assert_false(check_nvic_pending(EXTI0_IRQ));
+
+ /* Configure EXTI line 0 irq without selecting an edge trigger */
+ exti_writel(EXTI_IMR1, 0x00000001);
+ exti_writel(EXTI_RTSR1, 0x00000000);
+ exti_writel(EXTI_FTSR1, 0x00000000);
+
+ /* Test that no irq is raised */
+ exti_set_irq(0, 1);
+ g_assert_cmpuint(exti_readl(EXTI_PR1), ==, 0x00000000);
+ g_assert_false(check_nvic_pending(EXTI0_IRQ));
+
+ exti_set_irq(0, 0);
+ g_assert_cmpuint(exti_readl(EXTI_PR1), ==, 0x00000000);
+ g_assert_false(check_nvic_pending(EXTI0_IRQ));
+}
+
+static void test_no_software_interrupt(void)
+{
+ /*
+ * Test that software irq doesn't happen when :
+ * - corresponding bit in IMR isn't set
+ * - SWIER is set to 1 before IMR is set to 1
+ */
+
+ /*
+ * Testing interrupt line EXTI0
+ * Bit 0 in EXTI_*1 registers (EXTI0) corresponds to GPIO Px_0
+ */
+
+ enable_nvic_irq(EXTI0_IRQ);
+ /* Check that there are no interrupts already pending in PR */
+ g_assert_cmpuint(exti_readl(EXTI_PR1), ==, 0x00000000);
+ /* Check that this specific interrupt isn't pending in NVIC */
+ g_assert_false(check_nvic_pending(EXTI0_IRQ));
+
+ /* Mask interrupt line EXTI0 */
+ exti_writel(EXTI_IMR1, 0x00000000);
+ /* Set the corresponding SWIER bit from '0' to '1' */
+ exti_writel(EXTI_SWIER1, 0x00000000);
+ exti_writel(EXTI_SWIER1, 0x00000001);
+
+ /* Check that the write in SWIER was effective */
+ g_assert_cmpuint(exti_readl(EXTI_SWIER1), ==, 0x00000001);
+ /* Check that the pending bit in PR wasn't set */
+ g_assert_cmpuint(exti_readl(EXTI_PR1), ==, 0x00000000);
+ /* Check that the interrupt isn't pending in NVIC */
+ g_assert_false(check_nvic_pending(EXTI0_IRQ));
+
+ /* Enable interrupt line EXTI0 */
+ exti_writel(EXTI_IMR1, 0x00000001);
+
+ /* Check that the pending bit in PR wasn't set */
+ g_assert_cmpuint(exti_readl(EXTI_PR1), ==, 0x00000000);
+ /* Check that the interrupt isn't pending in NVIC */
+ g_assert_false(check_nvic_pending(EXTI0_IRQ));
+
+ /*
+ * Testing interrupt line EXTI35
+ * Bit 3 in EXTI_*2 registers (EXTI35) corresponds to PVM 1 Wakeup
+ */
+
+ enable_nvic_irq(EXTI35_IRQ);
+ /* Check that there are no interrupts already pending in PR */
+ g_assert_cmpuint(exti_readl(EXTI_PR2), ==, 0x00000000);
+ /* Check that this specific interrupt isn't pending in NVIC */
+ g_assert_false(check_nvic_pending(EXTI35_IRQ));
+
+ /* Mask interrupt line EXTI35 */
+ exti_writel(EXTI_IMR2, 0x00000000);
+ /* Set the corresponding SWIER bit from '0' to '1' */
+ exti_writel(EXTI_SWIER2, 0x00000000);
+ exti_writel(EXTI_SWIER2, 0x00000008);
+
+ /* Check that the write in SWIER was effective */
+ g_assert_cmpuint(exti_readl(EXTI_SWIER2), ==, 0x00000008);
+ /* Check that the pending bit in PR wasn't set */
+ g_assert_cmpuint(exti_readl(EXTI_PR2), ==, 0x00000000);
+ /* Check that the interrupt isn't pending in NVIC */
+ g_assert_false(check_nvic_pending(EXTI35_IRQ));
+
+ /* Enable interrupt line EXTI35 */
+ exti_writel(EXTI_IMR2, 0x00000008);
+
+ /* Check that the pending bit in PR wasn't set */
+ g_assert_cmpuint(exti_readl(EXTI_PR2), ==, 0x00000000);
+ /* Check that the interrupt isn't pending in NVIC */
+ g_assert_false(check_nvic_pending(EXTI35_IRQ));
+}
+
+static void test_masked_interrupt(void)
+{
+ /*
+ * Test that irq doesn't happen when :
+ * - corresponding bit in IMR isn't set
+ * - SWIER is set to 1 before IMR is set to 1
+ */
+
+ /*
+ * Testing interrupt line EXTI1
+ * with rising edge from GPIOx pin 1
+ */
+
+ enable_nvic_irq(EXTI1_IRQ);
+ /* Check that there are no interrupts already pending in PR */
+ g_assert_cmpuint(exti_readl(EXTI_PR1), ==, 0x00000000);
+ /* Check that this specific interrupt isn't pending in NVIC */
+ g_assert_false(check_nvic_pending(EXTI1_IRQ));
+
+ /* Mask interrupt line EXTI1 */
+ exti_writel(EXTI_IMR1, 0x00000000);
+
+ /* Configure interrupt on rising edge */
+ exti_writel(EXTI_RTSR1, 0x00000002);
+
+ /* Simulate rising edge from GPIO line 1 */
+ exti_set_irq(1, 1);
+
+ /* Check that the pending bit in PR wasn't set */
+ g_assert_cmpuint(exti_readl(EXTI_PR1), ==, 0x00000000);
+ /* Check that the interrupt isn't pending in NVIC */
+ g_assert_false(check_nvic_pending(EXTI1_IRQ));
+
+ /* Enable interrupt line EXTI1 */
+ exti_writel(EXTI_IMR1, 0x00000002);
+
+ /* Check that the pending bit in PR wasn't set */
+ g_assert_cmpuint(exti_readl(EXTI_PR1), ==, 0x00000000);
+ /* Check that the interrupt isn't pending in NVIC */
+ g_assert_false(check_nvic_pending(EXTI1_IRQ));
+}
+
+static void test_interrupt(void)
+{
+ /*
+ * Test that we can launch an irq by :
+ * - enabling its line in IMR
+ * - configuring interrupt on rising edge
+ * - and then setting the input line from '0' to '1'
+ *
+ * And that the interruption stays pending in NVIC
+ * even after clearing the pending bit in PR.
+ */
+
+ /*
+ * Testing interrupt line EXTI1
+ * with rising edge from GPIOx pin 1
+ */
+
+ enable_nvic_irq(EXTI1_IRQ);
+ /* Check that there are no interrupts already pending in PR */
+ g_assert_cmpuint(exti_readl(EXTI_PR1), ==, 0x00000000);
+ /* Check that this specific interrupt isn't pending in NVIC */
+ g_assert_false(check_nvic_pending(EXTI1_IRQ));
+
+ /* Enable interrupt line EXTI1 */
+ exti_writel(EXTI_IMR1, 0x00000002);
+
+ /* Configure interrupt on rising edge */
+ exti_writel(EXTI_RTSR1, 0x00000002);
+
+ /* Simulate rising edge from GPIO line 1 */
+ exti_set_irq(1, 1);
+
+ /* Check that the pending bit in PR was set */
+ g_assert_cmpuint(exti_readl(EXTI_PR1), ==, 0x00000002);
+ /* Check that the interrupt is pending in NVIC */
+ g_assert_true(check_nvic_pending(EXTI1_IRQ));
+
+ /* Clear the pending bit in PR */
+ exti_writel(EXTI_PR1, 0x00000002);
+
+ /* Check that the write in PR was effective */
+ g_assert_cmpuint(exti_readl(EXTI_PR1), ==, 0x00000000);
+ /* Check that the interrupt is still pending in the NVIC */
+ g_assert_true(check_nvic_pending(EXTI1_IRQ));
+
+ /* Clean NVIC */
+ unpend_nvic_irq(EXTI1_IRQ);
+ g_assert_false(check_nvic_pending(EXTI1_IRQ));
+}
+
+int main(int argc, char **argv)
+{
+ int ret;
+
+ g_test_init(&argc, &argv, NULL);
+ g_test_set_nonfatal_assertions();
+ qtest_add_func("stm32l4x5/exti/direct_lines", test_direct_lines_write);
+ qtest_add_func("stm32l4x5/exti/reserved_bits", test_reserved_bits_write);
+ qtest_add_func("stm32l4x5/exti/reg_write_read", test_reg_write_read);
+ qtest_add_func("stm32l4x5/exti/no_software_interrupt",
+ test_no_software_interrupt);
+ qtest_add_func("stm32l4x5/exti/software_interrupt",
+ test_software_interrupt);
+ qtest_add_func("stm32l4x5/exti/masked_interrupt", test_masked_interrupt);
+ qtest_add_func("stm32l4x5/exti/interrupt", test_interrupt);
+ qtest_add_func("stm32l4x5/exti/test_edge_selector", test_edge_selector);
+
+ qtest_start("-machine b-l475e-iot01a");
+ ret = g_test_run();
+ qtest_end();
+
+ return ret;
+}
--- /dev/null
+/*
+ * QTest testcase for STM32L4x5_SYSCFG
+ *
+ * Copyright (c) 2023 Arnaud Minier <arnaud.minier@telecom-paris.fr>
+ * Copyright (c) 2023 Inès Varhol <ines.varhol@telecom-paris.fr>
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#include "qemu/osdep.h"
+#include "libqtest-single.h"
+
+#define SYSCFG_BASE_ADDR 0x40010000
+#define SYSCFG_MEMRMP 0x00
+#define SYSCFG_CFGR1 0x04
+#define SYSCFG_EXTICR1 0x08
+#define SYSCFG_EXTICR2 0x0C
+#define SYSCFG_EXTICR3 0x10
+#define SYSCFG_EXTICR4 0x14
+#define SYSCFG_SCSR 0x18
+#define SYSCFG_CFGR2 0x1C
+#define SYSCFG_SWPR 0x20
+#define SYSCFG_SKR 0x24
+#define SYSCFG_SWPR2 0x28
+#define INVALID_ADDR 0x2C
+
+static void syscfg_writel(unsigned int offset, uint32_t value)
+{
+ writel(SYSCFG_BASE_ADDR + offset, value);
+}
+
+static uint32_t syscfg_readl(unsigned int offset)
+{
+ return readl(SYSCFG_BASE_ADDR + offset);
+}
+
+static void syscfg_set_irq(int num, int level)
+{
+ qtest_set_irq_in(global_qtest, "/machine/soc/syscfg",
+ NULL, num, level);
+}
+
+static void system_reset(void)
+{
+ QDict *response;
+ response = qtest_qmp(global_qtest, "{'execute': 'system_reset'}");
+ g_assert(qdict_haskey(response, "return"));
+ qobject_unref(response);
+}
+
+static void test_reset(void)
+{
+ /*
+ * Test that registers are initialized at the correct values
+ */
+ g_assert_cmpuint(syscfg_readl(SYSCFG_MEMRMP), ==, 0x00000000);
+
+ g_assert_cmpuint(syscfg_readl(SYSCFG_CFGR1), ==, 0x7C000001);
+
+ g_assert_cmpuint(syscfg_readl(SYSCFG_EXTICR1), ==, 0x00000000);
+
+ g_assert_cmpuint(syscfg_readl(SYSCFG_EXTICR2), ==, 0x00000000);
+
+ g_assert_cmpuint(syscfg_readl(SYSCFG_EXTICR3), ==, 0x00000000);
+
+ g_assert_cmpuint(syscfg_readl(SYSCFG_EXTICR4), ==, 0x00000000);
+
+ g_assert_cmpuint(syscfg_readl(SYSCFG_SCSR), ==, 0x00000000);
+
+ g_assert_cmpuint(syscfg_readl(SYSCFG_CFGR2), ==, 0x00000000);
+
+ g_assert_cmpuint(syscfg_readl(SYSCFG_SWPR), ==, 0x00000000);
+
+ g_assert_cmpuint(syscfg_readl(SYSCFG_SKR), ==, 0x00000000);
+
+ g_assert_cmpuint(syscfg_readl(SYSCFG_SWPR2), ==, 0x00000000);
+}
+
+static void test_reserved_bits(void)
+{
+ /*
+ * Test that reserved bits stay at reset value
+ * (which is 0 for all of them) by writing '1'
+ * in all reserved bits (keeping reset value for
+ * other bits) and checking that the
+ * register is still at reset value
+ */
+ syscfg_writel(SYSCFG_MEMRMP, 0xFFFFFEF8);
+ g_assert_cmpuint(syscfg_readl(SYSCFG_MEMRMP), ==, 0x00000000);
+
+ syscfg_writel(SYSCFG_CFGR1, 0x7F00FEFF);
+ g_assert_cmpuint(syscfg_readl(SYSCFG_CFGR1), ==, 0x7C000001);
+
+ syscfg_writel(SYSCFG_EXTICR1, 0xFFFF0000);
+ g_assert_cmpuint(syscfg_readl(SYSCFG_EXTICR1), ==, 0x00000000);
+
+ syscfg_writel(SYSCFG_EXTICR2, 0xFFFF0000);
+ g_assert_cmpuint(syscfg_readl(SYSCFG_EXTICR2), ==, 0x00000000);
+
+ syscfg_writel(SYSCFG_EXTICR3, 0xFFFF0000);
+ g_assert_cmpuint(syscfg_readl(SYSCFG_EXTICR3), ==, 0x00000000);
+
+ syscfg_writel(SYSCFG_EXTICR4, 0xFFFF0000);
+ g_assert_cmpuint(syscfg_readl(SYSCFG_EXTICR4), ==, 0x00000000);
+
+ syscfg_writel(SYSCFG_SKR, 0xFFFFFF00);
+ g_assert_cmpuint(syscfg_readl(SYSCFG_SKR), ==, 0x00000000);
+}
+
+static void test_set_and_clear(void)
+{
+ /*
+ * Test that regular bits can be set and cleared
+ */
+ syscfg_writel(SYSCFG_MEMRMP, 0x00000107);
+ g_assert_cmpuint(syscfg_readl(SYSCFG_MEMRMP), ==, 0x00000107);
+ syscfg_writel(SYSCFG_MEMRMP, 0x00000000);
+ g_assert_cmpuint(syscfg_readl(SYSCFG_MEMRMP), ==, 0x00000000);
+
+ /* cfgr1 bit 0 is clear only so we keep it set */
+ syscfg_writel(SYSCFG_CFGR1, 0xFCFF0101);
+ g_assert_cmpuint(syscfg_readl(SYSCFG_CFGR1), ==, 0xFCFF0101);
+ syscfg_writel(SYSCFG_CFGR1, 0x00000001);
+ g_assert_cmpuint(syscfg_readl(SYSCFG_CFGR1), ==, 0x00000001);
+
+ syscfg_writel(SYSCFG_EXTICR1, 0x0000FFFF);
+ g_assert_cmpuint(syscfg_readl(SYSCFG_EXTICR1), ==, 0x0000FFFF);
+ syscfg_writel(SYSCFG_EXTICR1, 0x00000000);
+ g_assert_cmpuint(syscfg_readl(SYSCFG_EXTICR1), ==, 0x00000000);
+
+ syscfg_writel(SYSCFG_EXTICR2, 0x0000FFFF);
+ g_assert_cmpuint(syscfg_readl(SYSCFG_EXTICR2), ==, 0x0000FFFF);
+ syscfg_writel(SYSCFG_EXTICR2, 0x00000000);
+ g_assert_cmpuint(syscfg_readl(SYSCFG_EXTICR2), ==, 0x00000000);
+
+ syscfg_writel(SYSCFG_EXTICR3, 0x0000FFFF);
+ g_assert_cmpuint(syscfg_readl(SYSCFG_EXTICR3), ==, 0x0000FFFF);
+ syscfg_writel(SYSCFG_EXTICR3, 0x00000000);
+ g_assert_cmpuint(syscfg_readl(SYSCFG_EXTICR3), ==, 0x00000000);
+
+ syscfg_writel(SYSCFG_EXTICR4, 0x0000FFFF);
+ g_assert_cmpuint(syscfg_readl(SYSCFG_EXTICR4), ==, 0x0000FFFF);
+ syscfg_writel(SYSCFG_EXTICR4, 0x00000000);
+ g_assert_cmpuint(syscfg_readl(SYSCFG_EXTICR4), ==, 0x00000000);
+
+ syscfg_writel(SYSCFG_SKR, 0x000000FF);
+ g_assert_cmpuint(syscfg_readl(SYSCFG_SKR), ==, 0x000000FF);
+ syscfg_writel(SYSCFG_SKR, 0x00000000);
+ g_assert_cmpuint(syscfg_readl(SYSCFG_SKR), ==, 0x00000000);
+}
+
+static void test_clear_by_writing_1(void)
+{
+ /*
+ * Test that writing '1' doesn't set the bit
+ */
+ syscfg_writel(SYSCFG_CFGR2, 0x00000100);
+ g_assert_cmpuint(syscfg_readl(SYSCFG_CFGR2), ==, 0x00000000);
+}
+
+static void test_set_only_bits(void)
+{
+ /*
+ * Test that set only bits stay can't be cleared
+ */
+ syscfg_writel(SYSCFG_CFGR2, 0x0000000F);
+ syscfg_writel(SYSCFG_CFGR2, 0x00000000);
+ g_assert_cmpuint(syscfg_readl(SYSCFG_CFGR2), ==, 0x0000000F);
+
+ syscfg_writel(SYSCFG_SWPR, 0xFFFFFFFF);
+ syscfg_writel(SYSCFG_SWPR, 0x00000000);
+ g_assert_cmpuint(syscfg_readl(SYSCFG_SWPR), ==, 0xFFFFFFFF);
+
+ syscfg_writel(SYSCFG_SWPR2, 0xFFFFFFFF);
+ syscfg_writel(SYSCFG_SWPR2, 0x00000000);
+ g_assert_cmpuint(syscfg_readl(SYSCFG_SWPR2), ==, 0xFFFFFFFF);
+
+ system_reset();
+}
+
+static void test_clear_only_bits(void)
+{
+ /*
+ * Test that clear only bits stay can't be set
+ */
+ syscfg_writel(SYSCFG_CFGR1, 0x00000000);
+ syscfg_writel(SYSCFG_CFGR1, 0x00000001);
+ g_assert_cmpuint(syscfg_readl(SYSCFG_CFGR1), ==, 0x00000000);
+
+ system_reset();
+}
+
+static void test_interrupt(void)
+{
+ /*
+ * Test that GPIO rising lines result in an irq
+ * with the right configuration
+ */
+ qtest_irq_intercept_in(global_qtest, "/machine/soc/exti");
+
+ /* GPIOA is the default source for EXTI lines 0 to 15 */
+
+ syscfg_set_irq(0, 1);
+
+ g_assert_true(get_irq(0));
+
+
+ syscfg_set_irq(15, 1);
+
+ g_assert_true(get_irq(15));
+
+ /* Configure GPIOB[1] as the source input for EXTI1 */
+ syscfg_writel(SYSCFG_EXTICR1, 0x00000010);
+
+ syscfg_set_irq(17, 1);
+
+ g_assert_true(get_irq(1));
+
+ /* Clean the test */
+ syscfg_writel(SYSCFG_EXTICR1, 0x00000000);
+ syscfg_set_irq(0, 0);
+ syscfg_set_irq(15, 0);
+ syscfg_set_irq(17, 0);
+}
+
+static void test_irq_pin_multiplexer(void)
+{
+ /*
+ * Test that syscfg irq sets the right exti irq
+ */
+
+ qtest_irq_intercept_in(global_qtest, "/machine/soc/exti");
+
+ syscfg_set_irq(0, 1);
+
+ /* Check that irq 0 was set and irq 15 wasn't */
+ g_assert_true(get_irq(0));
+ g_assert_false(get_irq(15));
+
+ /* Clean the test */
+ syscfg_set_irq(0, 0);
+
+ syscfg_set_irq(15, 1);
+
+ /* Check that irq 15 was set and irq 0 wasn't */
+ g_assert_true(get_irq(15));
+ g_assert_false(get_irq(0));
+
+ /* Clean the test */
+ syscfg_set_irq(15, 0);
+}
+
+static void test_irq_gpio_multiplexer(void)
+{
+ /*
+ * Test that an irq is generated only by the right GPIO
+ */
+
+ qtest_irq_intercept_in(global_qtest, "/machine/soc/exti");
+
+ /* GPIOA is the default source for EXTI lines 0 to 15 */
+
+ /* Check that setting rising pin GPIOA[0] generates an irq */
+ syscfg_set_irq(0, 1);
+
+ g_assert_true(get_irq(0));
+
+ /* Clean the test */
+ syscfg_set_irq(0, 0);
+
+ /* Check that setting rising pin GPIOB[0] doesn't generate an irq */
+ syscfg_set_irq(16, 1);
+
+ g_assert_false(get_irq(0));
+
+ /* Clean the test */
+ syscfg_set_irq(16, 0);
+
+ /* Configure GPIOB[0] as the source input for EXTI0 */
+ syscfg_writel(SYSCFG_EXTICR1, 0x00000001);
+
+ /* Check that setting rising pin GPIOA[0] doesn't generate an irq */
+ syscfg_set_irq(0, 1);
+
+ g_assert_false(get_irq(0));
+
+ /* Clean the test */
+ syscfg_set_irq(0, 0);
+
+ /* Check that setting rising pin GPIOB[0] generates an irq */
+ syscfg_set_irq(16, 1);
+
+ g_assert_true(get_irq(0));
+
+ /* Clean the test */
+ syscfg_set_irq(16, 0);
+ syscfg_writel(SYSCFG_EXTICR1, 0x00000000);
+}
+
+int main(int argc, char **argv)
+{
+ int ret;
+
+ g_test_init(&argc, &argv, NULL);
+ g_test_set_nonfatal_assertions();
+
+ qtest_add_func("stm32l4x5/syscfg/test_reset", test_reset);
+ qtest_add_func("stm32l4x5/syscfg/test_reserved_bits",
+ test_reserved_bits);
+ qtest_add_func("stm32l4x5/syscfg/test_set_and_clear",
+ test_set_and_clear);
+ qtest_add_func("stm32l4x5/syscfg/test_clear_by_writing_1",
+ test_clear_by_writing_1);
+ qtest_add_func("stm32l4x5/syscfg/test_set_only_bits",
+ test_set_only_bits);
+ qtest_add_func("stm32l4x5/syscfg/test_clear_only_bits",
+ test_clear_only_bits);
+ qtest_add_func("stm32l4x5/syscfg/test_interrupt",
+ test_interrupt);
+ qtest_add_func("stm32l4x5/syscfg/test_irq_pin_multiplexer",
+ test_irq_pin_multiplexer);
+ qtest_add_func("stm32l4x5/syscfg/test_irq_gpio_multiplexer",
+ test_irq_gpio_multiplexer);
+
+ qtest_start("-machine b-l475e-iot01a");
+ ret = g_test_run();
+ qtest_end();
+
+ return ret;
+}
projects / mirror_qemu.git / commitdiff