docs/devel/multi-process.rst

1 Multi-process QEMU
6   This is the design document for multi-process QEMU. It does not
40 A multi-process QEMU
43 A multi-process QEMU involves separating QEMU services into separate
51 A QEMU control process would remain, but in multi-process mode, will
55 A first step in creating a multi-process QEMU is to separate IO services
57 emulation. i.e., the control process would also be the CPU emulation
58 process. In a later phase, CPU emulation could be separated from the
59 control process.
71 guest CPU instructions. The devices emulated in the separate process are
93 code, the device object code must run in a different process. There are
95 separately from the main QEMU process. These are examined below.
105 application is a daemon process that can be contacted via a known UNIX
114 process, the application can also be sent other file descriptors over
135 driver, instead of needing them to be sent to the QEMU process first.
142 bypassing the need to send the interrupt back to the QEMU process first.
209 The remote emulation process will run the QEMU object hierarchy without
215 The processes will communicate with the QEMU process over UNIX domain
226 would indicate process *disk-proc* uses a qcow2 emulated disk named
231 (e.g., disk, network, etc.) in a single process, so that all backends of
237 The first argument to the remote emulation process will be a Unix domain
244 remote process QMP monitor
249 process:
260 Each remote device emulated in a remote process on the host is
263 to the remote process. An *id* sub-option is required, and it should
264 be the same id as used in the remote process.
270 can be used to add a device emulated in a remote process
279 communication with emulation process
286 the remote process. It is also used to pass on device-agnostic commands
305 device emulation code within the QEMU process. These objects will live
322 - Parses the "socket" sub option and connects to the remote process
325 separate process
344 tree within the QEMU process.
360 they will forward the operation to the device emulation process.
369 need to be propagated to the emulation process.
385 socket to receive interrupt indications from the emulation process. An
395 remote device's *vmstate*; that will be handled by the remote process
402 process proxy by sending messages to the remote process.
408 the initial messages sent to the emulation process is a guest memory
410 that the emulation process can ``mmap()`` to directly access guest
419 When the emulated system includes an IOMMU, the remote process proxy in
421 process. It will handle those requests with an
423 unmaps, the remote process proxy will also register as a listener on the
426 to the memory region that will forward unmaps to the emulation process
433 process. It will also have "rid" option to the command, just as the
434 *-device* command line option does. The remote process may either be one
435 started at QEMU startup, or be one added by the "add-process" QMP
436 command described above. In either case, the remote process proxy will
438 process.
443 The remote process proxy will also register for live migration
445 the proxy will send the remote process a secondary socket file
446 descriptor to save the remote process's device *vmstate* over. The
450 to the new remote process through which it receives the *vmstate* in
453 device emulation in remote process
460 handle requests from the QEMU process, and route machine-level requests
461 (such as interrupts or IOMMU mappings) back to the QEMU process.
466 The process initialization sequence will follow the same sequence
468 device emulation objects. The JSON descriptions sent by the QEMU process
490 QEMU process. For a PCI device, a PCI bus will need to be created with
503 In order to use ``address_space_rw()`` in the emulation process to
505 same in the QEMU process and the device emulation process. In order to
507 to the emulation process.
523 an emulation process would be to setup the root PCI bus driver (via
525 process, and have the device proxy object reflect it up the PCI tree
533 into the VM. A simple emulation process implementation would be to send
543 virtual address. The emulation process memory region objects setup above
553 emulation process will need similar functionality.
557 The emulation process will maintain a cache of recent IOMMU translations
573 When a remote process receives a live migration indication from QEMU, it
577 the process's device state back to QEMU. This method will be reversed on
585 process can add considerable latency to IO operations. The optimizations
587 emulation process to communicate directly with the kernel KVM driver.
588 The KVM file descriptors created would be passed to the emulation process
601 that the emulation process can use to receive MMIO notifications. QEMU
603 descriptor to the emulation process via an initialization message.
739 how long KVM will wait for the emulation process to respond to a MMIO
780 ``mmap()``\ ed by the emulation process to share the emulation's view of
817 process reply before re-starting the guest. Loads that do not have
835 application does, where the QEMU process sets up *eventfds* that cause
837 These irq file descriptors are sent to the emulation process at
903 separate a process to handle CPU instruction emulation from the main
939 allows rules to be written on what operations a process with a given
942 different types, both from the main QEMU process, and from the emulation
946 types separate from the main QEMU process and non-disk emulation
949 emulation processes can have a type separate from the main QEMU process
950 and non-network emulation process, and only that type can access the
957 the process or file. The process is granted access to the file if the
958 process's set is a superset of the file's set. This enforcement can be
962 each device emulation process could be provisioned with a separate