/qemu/docs/system/ppc/ |
H A D | pseries.rst | 7 is also known as sPAPR, System p guests, or simply Power Linux guests (although 119 hypervisor and non-Linux guests in mind, you should use the virtio counterparts 121 since they will most probably give you better performance with Linux guests in a 175 KVM-PR uses the so-called **PR**\ oblem state of the PPC CPUs to run the guests, 183 Because all privileged instructions are trapped, guests that use a lot of 186 able to emulate a lot of guests CPUs. This module can even be used to run other 187 PowerPC guests like an emulated PowerMac. 196 In order to run KVM-PR guests with POWER9 processors, someone will need to start 208 to start pSeries guests. As the pSeries guest doesn't have access to the 211 pSeries guests as well, making nested virtualization possible with KVM-HV. [all …]
|
H A D | amigang.rst | 22 * PCI VGA compatible card (guests may need other card instead) 80 * PCI VGA compatible card (guests may need other card instead)
|
/qemu/hw/uefi/ |
H A D | LIMITATIONS.md | 6 * works only for 64-bit guests 7 - UINTN is mapped to uint64_t, for 32-bit guests that would be uint32_t
|
/qemu/docs/system/i386/ |
H A D | hyperv.rst | 14 KVM on x86 implements Hyper-V Enlightenments for Windows guests. These features 15 make Windows and Hyper-V guests think they're running on top of a Hyper-V 127 to the specification, guests shouldn't use this information and it is unknown 143 The enlightenment is nested specific, it targets Hyper-V on KVM guests. When 150 (Reference TSC page) to its own guests. 160 The enlightenment is nested specific, it targets Hyper-V on KVM guests. When 190 is required by Windows and Hyper-V guests to properly mitigate SMT related CPU 198 of host setup. To keep guests secure, this can only be used in conjunction with 229 The enlightenment is nested specific, it targets Hyper-V on KVM guests. When 249 The enlightenment is nested specific, it targets Hyper-V on KVM guests. When [all …]
|
H A D | xen.rst | 8 KVM has support for hosting Xen guests, intercepting Xen hypercalls and event 9 channel (Xen PV interrupt) delivery. This allows guests which expect to be 54 to be in the upper 64 bits of the MSI message. For guests with large numbers 64 through simultaneous grants. For guests with large numbers of PV devices and 86 model for emulated Xen guests, meaning that just the default NIC provided 105 VirtIO devices can also be used; Linux guests may need to be dissuaded from 108 Booting Xen PV guests
|
H A D | xenpvh.rst | 4 Xen supports a spectrum of types of guests that vary in how they depend
|
/qemu/docs/system/ |
H A D | confidential-guest-support.rst | 6 can compromise any of its guests. A number of platforms have added 7 mechanisms in hardware and/or firmware which give guests at least some 15 attacks from other guests, or from network sources).
|
H A D | security.rst | 69 could allow malicious guests to gain code execution in QEMU. At this point the 73 Guests often interact with other guests and share resources with them. A 74 malicious guest must not gain control of other guests or access their data. 75 Disk image files and network traffic must be protected from other guests unless 96 necessary for QEMU but are not exposed to guests. A guest that escapes into
|
H A D | cpu-models-x86.rst.inc | 224 By disabling TSX, KVM-based guests can avoid paying the price of 333 This should be provided to guests, even if amd-ssbd is also provided, 348 exposed to guests whenever available in the host. ``virt-ssbd`` should 377 compatibility checks before launching guests, the default is guaranteed 389 ``qemu64`` is used for x86_64 guests and ``qemu32`` is used for i686 390 guests, when no ``-cpu`` argument is given to QEMU, or no ``<cpu>`` is 398 featureset, which prevents guests having optimal performance.
|
/qemu/docs/specs/ |
H A D | pci-serial.rst | 9 guests work out-of-the box with all cards. There is a Windows inf file 10 (``docs/qemupciserial.inf``) to set up the cards in Windows guests.
|
H A D | acpi_erst.rst | 31 hosts/guests with root filesystems on NFS/iSCSI where networking 37 guests. With QEMU supporting ACPI ERST, it becomes a viable pstore 42 capture kernel panic information in a wide range of guests: from 43 resource-constrained microvms to very large guests, and in particular,
|
H A D | ppc-spapr-uv-hcalls.rst | 7 can provide access to. pSeries guests on such systems can communicate with 10 inaccessible to normal processes/guests running on the host.
|
H A D | riscv-iommu.rst | 51 -M virt,aia=aplic-imsic,aia-guests=5 \ 58 -M virt,aia=aplic-imsic,aia-guests=5 \
|
H A D | pci-testdev.rst | 38 can be used to test whether guests handle PCI BARs of a specific
|
/qemu/qapi/ |
H A D | misc-i386.json | 70 # Information specific to legacy SEV/SEV-ES guests. 85 # Information specific to SEV-SNP guests. 166 # measurement for SEV-SNP guests is only available within the guest. 240 # 'sev-guest' confidential virtualization object. SEV-SNP guests do 279 # report for SEV-SNP guests is only available within the guest.
|
/qemu/tests/keys/ |
H A D | README | 3 Some guests require the key to exist prior to provisioning the guest; also,
|
/qemu/docs/config/ |
H A D | q35-virtio-graphical.cfg | 14 # tailored towards optimal performance with modern guests, 197 # a USB tablet so that graphical guests can be controlled 199 # guests get a PS/2 one added automatically.
|
H A D | mach-virt-graphical.cfg | 15 # tailored towards optimal performance with modern guests, 73 # guests, and a read/write variable store that is owned 247 # guests can be controlled appropriately.
|
H A D | mach-virt-serial.cfg | 16 # tailored towards optimal performance with modern guests, 79 # guests, and a read/write variable store that is owned
|
/qemu/docs/system/arm/ |
H A D | virt.rst | 46 - running guests using the KVM accelerator on aarch64 hardware 251 - For guests using the Linux kernel boot protocol (this means any 253 of the DTB is passed in a register (``r2`` for 32-bit guests, 254 or ``x0`` for 64-bit guests) 256 - For guests booting as "bare-metal" (any other kind of boot),
|
/qemu/docs/system/s390x/ |
H A D | vfio-ap.rst | 15 describes how those cards may be made available to KVM guests using the 124 This is valid because both guests have a unique set of APQNs: 140 This is also valid because both guests have a unique set of APQNs: 156 This is an invalid configuration because both guests have access to 500 fields of the guests's CRYCB respectively. These APQNs identify the AP queues 615 Note that on Linux guests, the AP devices will be created in the 652 Let's now provide an example to illustrate how KVM guests may be given 654 three guests such that executing the lszcrypt command on the guests would 719 2. Secure the AP queues to be used by the three guests so that the host can not 763 three guests and to provide an interface to the vfio_ap driver for [all …]
|
/qemu/tests/uefi-test-tools/UefiTestToolsPkg/ |
H A D | UefiTestToolsPkg.dec | 3 # guests.
|
/qemu/docs/system/devices/ |
H A D | vhost-user-rng.rst | 31 use to communicate as well as share the guests memory over a memfd.
|
H A D | virtio-gpu.rst | 102 and ``cross-domain`` for Linux guests. For Android guests, the experimental
|
/qemu/hw/ppc/ |
H A D | spapr_nested.c | 68 return spapr->nested.guests ? in spapr_get_nested_guest() 69 g_hash_table_lookup(spapr->nested.guests, in spapr_get_nested_guest() 1337 if (!spapr->nested.guests) { in h_guest_create() 1338 spapr->nested.guests = g_hash_table_new_full(NULL, in h_guest_create() 1344 nguests = g_hash_table_size(spapr->nested.guests); in h_guest_create() 1352 if (!(g_hash_table_lookup(spapr->nested.guests, in h_guest_create() 1368 g_hash_table_insert(spapr->nested.guests, GINT_TO_POINTER(guestid), guest); in h_guest_create() 1391 g_hash_table_destroy(spapr->nested.guests); in h_guest_delete() 1395 guest = g_hash_table_lookup(spapr->nested.guests, GINT_TO_POINTER(guestid)); in h_guest_delete() 1400 g_hash_table_remove(spapr->nested.guests, GINT_TO_POINTER(guestid)); in h_guest_delete()
|