| /qemu/docs/system/ |
| H A D | device-emulation.rst | 6 QEMU supports the emulation of a large number of devices from
7 peripherals such network cards and USB devices to integrated systems
10 used to describes devices within QEMU.
20 system is expecting to see. All devices can be specified with the
22 options ``--device help`` will list all devices it is aware of. Using
32 Most devices will exist on a BUS of some sort. Depending on the
35 can be inferred, for example PCI devices are generally automatically
41 Some devices, for example a PCI SCSI host controller, will add an
42 additional buses to the system that other devices can be attached to.
43 A hypothetical chain of devices might look like:
[all …]
|
| H A D | virtio-net-failover.rst | 6 is used to create a net_failover pair of devices.
8 The general idea is that we have a pair of devices, a (vfio-)pci and a
12 module will pair net devices with the same MAC address.
14 The two devices are called primary and standby device. The fast hardware based
21 Currently only PCIe devices are allowed as primary devices, this restriction
23 devices are allowed as primary device. The user needs to ensure that primary
24 and standby devices are not plugged into the same PCIe slot.
51 is only for pairing the devices within QEMU. The guest kernel module
52 net_failover will match devices with identical MAC addresses.
65 devices are present in the configuration, migration will go into this state.
[all …]
|
| H A D | bootindex.rst | 5 which order it should look for a bootable OS on which devices.
8 property on the individual block or net devices you specify
12 firmware will consider devices for booting the guest OS. If the
14 boot priority. There is no particular order in which devices with no
51 Some firmware has limitations on which devices can be considered for
56 8 total devices, any number of which may be disks or virtio-net devices.
59 boot from to a boot method. It doesn't happen for devices the firmware
64 has three bootable devices target1, target3, target5 connected to it,
77 from the expected devices.
|
| /qemu/docs/ |
| H A D | qdev-device-use.txt | 5 In qdev, each device has a parent bus. Some devices provide one or
10 where this address can be configured, devices provide a bus-specific
28 === Block Devices ===
34 of which can have up to two devices, and each device is a guest part,
41 The old ways to define block devices define host and guest part
70 * serial goes into DEV-OPTS, for devices supporting serial numbers.
71 For other devices, it goes nowhere.
95 As for all PCI devices, you can add bus=PCI-BUS,addr=DEVFN to
111 "Default Devices".
122 As for all PCI devices, you can add bus=PCI-BUS,addr=DEVFN to
[all …]
|
| H A D | bypass-iommu.txt | 7 devices in the system can only support go through vIOMMU or not, which
9 coexist of devices go through vIOMMU and devices not. This is useful to
10 passthrough devices with no-iommu mode and devices go through vIOMMU in
14 determine whether the devices attached on the PCI host bridge will bypass
16 virtual iommu in the system, it is implemented to allow some devices to
18 the attached devices will go through vIOMMU by default.
66 There might be potential security risk when devices bypass iommu, because
67 devices might send malicious dma request to virtual machine if there is no
76 space for devices bypass iommu.
79 RID mapping for devices which do not bypass iommu.
[all …]
|
| H A D | pcie.txt | 7 devices in PCI Express based machines and explains the reasoning behind
34 PCI Express devices should be plugged only into PCI Express Root Ports and
39 Place only the following kinds of devices directly on the Root Complex:
40 (1) PCI Devices (e.g. network card, graphics card, IDE controller),
41 not controllers. Place only legacy PCI devices on
45 Although the PCI Express spec does not forbid PCI Express devices as
47 devices with the Root Complex. Guest OSes are suspected to behave
48 strangely when PCI Express devices are integrated
81 A PCI Express Root bus supports up to 32 devices. Since each
86 Prefer grouping PCI Express Root Ports into multi-function devices
[all …]
|
| H A D | nvdimm.txt | 28 normal RAM devices and vNVDIMM devices, e.g. $N should be >= 2 here.
31 of normal RAM devices and vNVDIMM devices, e.g. $MAX_SIZE should be
58 Multiple vNVDIMM devices can be created if multiple pairs of "-object"
91 QEMU v2.7.0 and later implement the label support for vNVDIMM devices.
92 To enable label on vNVDIMM devices, users can simply add
114 devices. Similarly to the RAM hotplug, the vNVDIMM hotplug is
128 N >= number of RAM devices +
129 number of statically plugged vNVDIMM devices +
130 number of hotplugged vNVDIMM devices
133 M >= size of RAM devices +
[all …]
|
| H A D | multiseat.txt | 5 host devices
42 to these input devices.
45 for the input devices, using this ...
52 ... instead of xhci and usb hid devices.
61 to its own window so you can see both display devices side-by-side.
65 second seat, similar to input devices:
99 Good. Now lets tell the system that the pci bridge and all devices
117 the devices attached to the seat.
128 qemu command line above. The only difference between the two devices
|
| /qemu/docs/devel/ |
| H A D | kconfig.rst | 16 Each QEMU target enables a subset of the boards, devices and buses that
27 include all the required dependencies and all the devices that the
31 of boards or devices. For example, by default most targets will include
32 all emulated PCI devices that QEMU supports, but the build process is
156 **devices**
166 Devices are the most complex of the five. They can have a variety
168 all the devices that can be accessed from QEMU.
170 Devices *depend on* the bus that they lie on, for example a PCI
172 have no ``depends on`` directive. Devices also *select* the buses
174 ``select SCSI``. Finally, devices are usually ``default y`` if and
[all …]
|
| /qemu/docs/system/devices/ |
| H A D | usb.rst | 5 plug virtual USB devices or real host USB devices (only works with
7 connect virtual USB hubs as necessary to connect multiple USB devices.
23 XHCI supports USB 1.1, USB 2.0 and USB 3.0 devices, so this is the
26 need to use the bus= parameter when adding USB devices.
32 The QEMU EHCI Adapter supports USB 2.0 devices. It can be used either
34 devices. The companion controller setup is more convenient to use
36 1.1 devices. See next section for details.
39 controllers for USB 1.1 devices too. Each controller creates its own
42 the EHCI controller. Devices must be attached to the correct
55 When adding USB devices using the ``-device`` switch you can specify the
[all …]
|
| /qemu/include/hw/mem/ |
| H A D | memory-device.h | 33 * All memory devices need to implement TYPE_MEMORY_DEVICE as an interface.
41 * configurations. Such devices can logically get (un)plugged, however,
42 * empty memory devices are mostly ignored by the memory device code.
44 * Conceptually, memory devices only span one memory region. If multiple
47 * devices.
68 * all memory devices mapped into guest physical address space.
90 * This is helpful for devices that dynamically manage the amount of
92 * most devices, this corresponds to the size of the memory region.
117 * Optional for memory devices that require only a single memslot,
118 * required for all other memory devices: Return the number of memslots
[all …]
|
| /qemu/docs/system/s390x/ |
| H A D | vfio-ap.rst | 11 These AP devices provide cryptographic functions to all CPUs assigned to a
165 linux system is started, the AP bus will detect the AP devices assigned to the
169 ... [devices]
188 ... [devices]
216 Binding AP devices to device drivers
322 mediated matrix device must first be created for the ``/sys/devices/vfio_ap/matrix``
325 creating mediated matrix devices is created::
327 /sys/devices
333 ............... [devices]
347 the UUID is created in the ``devices`` subdirectory::
[all …]
|
| H A D | css.rst | 5 functionless) channel paths, and channel devices (virtio-ccw, 3270, and
6 devices passed via vfio-ccw). It supports multiple subchannel sets (MSS) and
9 All channel devices support the ``devno`` property, which takes a parameter
12 The default channel subsystem image id (``<cssid>``) is ``0xfe``. Devices in
14 enable MCSS-E. Note that devices with a different cssid will not be visible
19 Devices with a ssid that is not ``0`` will not be visible if the guest OS
42 In a Linux guest (without default devices and no other devices specified
|
| /qemu/block/ |
| H A D | snapshot.c | 485 bdrv_all_get_snapshot_devices(bool has_devices, strList *devices, in bdrv_all_get_snapshot_devices() argument
491 if (!devices) { in bdrv_all_get_snapshot_devices()
496 while (devices) { in bdrv_all_get_snapshot_devices()
497 BlockDriverState *bs = bdrv_find_node(devices->value); in bdrv_all_get_snapshot_devices()
499 error_setg(errp, "No block device node '%s'", devices->value); in bdrv_all_get_snapshot_devices()
503 devices = devices->next; in bdrv_all_get_snapshot_devices()
534 bool bdrv_all_can_snapshot(bool has_devices, strList *devices, in bdrv_all_can_snapshot() argument
543 if (bdrv_all_get_snapshot_devices(has_devices, devices, &bdrvs, errp) < 0) { in bdrv_all_can_snapshot()
552 if (devices || bdrv_all_snapshots_includes_bs(bs)) { in bdrv_all_can_snapshot()
568 bool has_devices, strList *devices, in bdrv_all_delete_snapshot() argument
[all …]
|
| /qemu/docs/devel/migration/ |
| H A D | vfio.rst | 8 devices is done in QEMU.
10 Migration of VFIO devices consists of two phases: the optional pre-copy phase,
12 accommodate VFIO devices that have a large amount of data that needs to be
15 helps to reduce the total downtime of the VM. VFIO devices opt-in to pre-copy
26 To support migration of multiple devices that might do P2P transactions between
33 All the devices that support P2P migration are first transitioned to the P2P
35 safe P2P-wise, since starting and stopping the devices is not done atomically
36 for all the devices together.
38 Thus, multiple VFIO devices migration is allowed only if all the devices
168 supports both precopy and P2P migration. The flow for devices that don't
[all …]
|
| H A D | main.rst | 15 the same devices that the one it was saved (this last requirement can
73 save/restore state devices. This infrastructure is shared with the
87 For most devices, the state is saved in a single call to the migration
88 infrastructure; these are *non-iterative* devices. The data for these
89 devices is sent at the end of precopy migration, when the CPUs are paused.
90 There are also *iterative* devices, which contain a very large amount of
140 - Buses and devices should be able to explicitly specify addresses when
142 when hot adding USB devices it's important to specify the ports
182 For devices that are ``qdev`` based, we can register the device in the class
479 Some devices, such as RAM or certain platform devices,
[all …]
|
| /qemu/hw/mem/ |
| H A D | memory-device.c | 62 if (dev->realized) { /* only realized memory devices matter */ in memory_device_build_list()
82 * Memslots that are reserved by memory devices (required but still reported
137 * Consider our soft-limit across all memory devices. We don't really in memory_device_memslot_decision_limit()
158 /* We cannot have any other memory devices? So give all to this device. */ in memory_device_memslot_decision_limit()
165 * still available for memory devices. in memory_device_memslot_decision_limit()
207 " in use of total space for memory devices 0x" RAM_ADDR_FMT, in memory_device_check_addable()
229 " all 'maxmem' might be usable for memory devices.", in memory_device_get_free_addr()
242 "], usable range for memory devices [0x%" PRIx64 ":0x%" in memory_device_get_free_addr()
298 GSList *devices = NULL, *item; in qmp_memory_device_list() local
302 &devices); in qmp_memory_device_list()
[all …]
|
| /qemu/include/migration/ |
| H A D | snapshot.h | 27 * @devices: explicit device list to snapshot
34 bool has_devices, strList *devices,
42 * @devices: explicit device list to snapshot
49 bool has_devices, strList *devices,
56 * @devices: explicit device list to snapshot
62 bool has_devices, strList *devices,
|
| /qemu/tests/qtest/ |
| H A D | display-vga-test.c | 31 static const char *devices[] = { in main() local
41 for (int i = 0; i < ARRAY_SIZE(devices); i++) { in main()
42 if (qtest_has_device(devices[i])) { in main()
43 char *testpath = g_strdup_printf("/display/pci/%s", devices[i]); in main()
44 qtest_add_data_func(testpath, devices[i], test_vga); in main()
|
| H A D | readconfig-test.c | 231 static void test_docs_q35(const char *input_file, struct device *devices) in test_docs_q35() argument
240 /* Check that all the devices are available in the QEMU binary */ in test_docs_q35()
241 for (i = 0; devices[i].name; i++) { in test_docs_q35()
242 if (!qtest_has_device(devices[i].type)) { in test_docs_q35()
243 g_test_skip("one of the required devices is not available"); in test_docs_q35()
285 /* Check that all the devices have been created */ in test_docs_q35()
286 for (i = 0; devices[i].name; i++) { in test_docs_q35()
287 test_object_available(qobj, devices[i].name, devices[i].type); in test_docs_q35()
308 struct device devices[] = { in test_docs_q35_emulated() local
331 test_docs_q35("docs/config/q35-emulated.cfg", devices); in test_docs_q35_emulated()
[all …]
|
| /qemu/docs/system/i386/ |
| H A D | xenpvh.rst | 8 paravirtualized devices.
10 QEMU can be used to provide PV virtio devices on an emulated PCIe controller.
13 Supported devices
16 The x86 Xen PVH QEMU machine provide the following devices:
20 - virtio-pci devices
22 The idea is to only connect virtio-pci devices but in theory any compatible
|
| H A D | microvm.rst | 13 Supported devices
16 The microvm machine type supports the following devices:
27 - Up to eight virtio-mmio devices (configured by the user)
35 - PCI-only devices.
53 - microvm.auto-kernel-cmdline=bool (Set off to disable adding virtio-mmio devices to the kernel cmd…
71 legacy and non-legacy devices. In this example, a VM is created
86 footprint further by disabling some legacy devices. If you're using
114 devices, some x86 mechanisms for rebooting or shutting down the
|
| /qemu/docs/specs/ |
| H A D | pci-ids.rst | 6 virtual devices. The vendor IDs are 1af4 (formerly Qumranet ID) and 1b36.
9 for your devices.
14 The 1000 -> 10ff device ID range is used as follows for virtio-pci devices.
36 ID range for modern virtio devices. The PCI device
49 Used as PCI Subsystem ID for existing hardware devices emulated
61 PCI devices (other than virtio):
104 All these devices are documented in :doc:`index`.
|
| /qemu/tests/functional/ |
| H A D | test_s390x_ccw_virtio.py | 3 # Functional test that boots an s390x Linux guest with ccw and PCI devices
4 # attached and checks whether the devices are recognized by Linux
99 exec_command_and_wait_for_pattern(self, 'ls /sys/bus/ccw/devices/',
101 exec_command_and_wait_for_pattern(self, 'ls /sys/bus/pci/devices/',
110 'cat /sys/bus/ccw/devices/0.2.0000/virtio?/features',
113 'cat /sys/bus/ccw/devices/0.3.1234/virtio?/features',
128 # verify that we indeed have virtio-net devices (without having the
131 'cat /sys/bus/ccw/devices/0.1.1111/cutype',
134 r'cat /sys/bus/pci/devices/0005\:00\:00.0/subsystem_vendor',
137 r'cat /sys/bus/pci/devices/0005\:00\:00.0/subsystem_device',
[all …]
|
| /qemu/docs/system/arm/ |
| H A D | b-l475e-iot01a.rst | 12 Supported devices
15 Currently B-L475E-IOT01A machines support the following devices:
25 Missing devices
28 The B-L475E-IOT01A does *not* support the following devices:
34 See the complete list of unimplemented peripheral devices
|