docs/devel/multi-process.rst

51 A QEMU control process would remain, but in multi-process mode, will
85 parent object (such as "pci-device" for a PCI device) and QEMU will
195 emulation applications will need to include the QEMU block objects.
209 The remote emulation process will run the QEMU object hierarchy without
210 modification. The device emulation objects will be also be based on the
215 The processes will communicate with the QEMU process over UNIX domain
218 processes will provide are specified on its command line, as they would
237 The first argument to the remote emulation process will be a Unix domain
304 The proxy object model will use device proxy objects to replace the
305 device emulation code within the QEMU process. These objects will live
307 replace. i.e., the proxy object for an LSI SCSI controller will be a
308 sub-class of the "pci-device" class, and will have the same PCI bus
330 The ``class_init()`` method of a proxy object will, in general behave
342 Other tasks will be device-specific. For example, PCI device objects
343 will initialize the PCI config space in order to make a valid PCI device
352 functions that QEMU will invoke when the guest accesses the device's
354 device, the VM will exit HW virtualization mode and return to QEMU,
355 which will then lookup and execute the corresponding callback function.
360 they will forward the operation to the device emulation process.
384 A proxy for a device that generates interrupts will need to create a
393 The proxy will register to save and restore any *vmstate* it needs over
395 remote device's *vmstate*; that will be handled by the remote process
401 Generic device operations, such as DMA, will be performed by the remote
420 QEMU will need to create a socket for IOMMU requests from the emulation
421 process. It will handle those requests with an
423 unmaps, the remote process proxy will also register as a listener on the
425 within the DMA address space, an IOMMU notifier for unmaps will be added
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
436 command described above. In either case, the remote process proxy will
443 The remote process proxy will also register for live migration
445 the proxy will send the remote process a secondary socket file
447 incoming byte stream length and data will be saved as the proxy's
449 will be extracted, and a secondary socket file descriptor will be sent
456 The parts of QEMU that the emulation program will need include the
459 backends. It will also need code to setup the machine environment,
466 The process initialization sequence will follow the same sequence
467 followed by QEMU. It will first initialize the backend objects, then
469 will drive which objects need to be created.
480 RAM memory region creation will follow how ``pc_memory_init()`` creates
483 will be supplied by the guest memory table from above. Those RAM regions
489 IO initialization will be driven by the JSON descriptions sent from the
490 QEMU process. For a PCI device, a PCI bus will need to be created with
491 ``pci_root_bus_new()``, and a PCI memory region will need to be created
499 The device emulation objects will use ``memory_region_init_io()`` to
544 will be used to translate the DMA address to a local virtual address the
553 emulation process will need similar functionality.
557 The emulation process will maintain a cache of recent IOMMU translations
559 invoked, the IOTLB cache will be searched for an entry that will map the
560 DMA address to a guest PA. On a cache miss, a message will be sent back
566 The IOMMU emulation will also need to act on unmap requests from QEMU.
574 will set up a channel using the received file descriptor with
575 ``qio_channel_socket_new_fd()``. This channel will be used to create a
577 the process's device state back to QEMU. This method will be reversed on
578 restore - the channel will be passed to ``qemu_loadvm_state()`` to
611 device will respond to. It includes the base and length of the range, as
616 a PCI device can have multiple BARs), so the structure will also include
673 that a load to a device will not complete until all previous stores to
683 The emulation program will ask the KVM driver to allocate memory for the
684 shadow image, and will then use ``mmap()`` to directly access it. The
701 The *KVM\_DEV\_TYPE\_USER* operations vector will be registered by a
710 ``ioctl()`` on its per-VM file descriptor. It will allocate and
718 device type. *KVM\_DEV\_TYPE\_USER* ones will need several commands:
720 *KVM\_DEV\_USER\_SLAVE\_FD* creates the slave file descriptor that will
726 address range that the slave descriptor will receive MMIO notifications
732 *KVM\_DEV\_USER\_PA\_RANGE* will use ``kvm_io_bus_register_dev()`` to
738 *KVM\_DEV\_USER\_TIMEOUT* will configure a timeout value that specifies
739 how long KVM will wait for the emulation process to respond to a MMIO
744 This routine is called when the VM instance is destroyed. It will need
751 The slave descriptor will have its own file operations vector, which
761 space in the pending to add new MMIO operations, they will be woken
784 shadow image. It will send the KVM driver a shadow control map, which
786 sending the load request to the emulation program. It will also specify
791 An emulation program will use the ``poll()`` call with a *POLLIN* flag
792 to determine if there are MMIO requests waiting to be read. It will
799 memory, changes with no side-effects will be reflected in the shadow,
807 VM. KVM will use the MMIO's guest physical address to search for a
810 corresponding callback will be invoked.
827 space in the queue. Stores will increment the number of posted stores in
864 pin is connected to. The proxy object in QEMU will use
866 changes to the route. This handler will broadly follow the VFIO
882 This case will also follow the VFIO example. For each MSI/X interrupt,