| /qemu/qga/ |
| H A D | qapi-schema.json | 36 'guest-file-open',
37 'guest-fsfreeze-freeze',
38 'guest-fsfreeze-freeze-list',
39 'guest-fsfreeze-status',
40 'guest-fsfreeze-thaw',
41 'guest-get-time',
42 'guest-set-vcpus',
43 'guest-sync',
44 'guest-sync-delimited' ],
50 # @guest-sync-delimited:
[all …]
|
| /qemu/docs/system/i386/ |
| H A D | amd-memory-encryption.rst | 8 (code and data) secured such that only the guest itself has access to the
18 encrypted guest. These SEV commands can be issued via KVM_MEMORY_ENCRYPT_OP
22 support to additionally protect the guest register state. In order to allow a
23 hypervisor to perform functions on behalf of a guest, there is architectural
24 support for notifying a guest's operating system when certain types of VMEXITs
25 are about to occur. This allows the guest to selectively share information with
31 Boot images (such as bios) must be encrypted before a guest can be booted. The
38 For a SEV-ES guest, the ``LAUNCH_UPDATE_VMSA`` command is also used to encrypt the
39 guest register state, or VM save area (VMSA), for all of the guest vCPUs.
42 the firmware. To create this context, guest owner must provide a guest policy,
[all …]
|
| H A D | xen.rst | 1 Xen HVM guest support
24 Additionally, virtual APIC support can be advertised to the guest through the
33 advertised to a Xen guest. If Hyper-V is also enabled, the Xen identification
44 Setting this property enables the Xen guest support. If Xen version 4.5 or
47 vector support to the guest.
59 Xen grant tables are the means by which a Xen guest grants access to its
62 table can reference 512 pages of guest memory. The default number of frames
63 is 64, allowing for 32768 pages of guest memory to be accessed by PV backends
70 The Xen PCI platform device is enabled automatically for a Xen guest. This
71 allows a guest to unplug all emulated devices, in order to use paravirtual
[all …]
|
| H A D | sgx.rst | 18 SGX feature is exposed to guest via SGX CPUID. Looking at SGX CPUID, we can
19 report the same CPUID info to guest as on host for most of SGX CPUID. With
20 reporting the same CPUID guest is able to use full capacity of SGX, and KVM
23 The guest's EPC base and size are determined by QEMU, and KVM needs QEMU to
24 notify such info to it before it can initialize SGX for guest.
39 guest, e.g. QEMU will happily allow you to create 64 1M EPC sections. Be aware
59 To simplify the implementation, EPC is always located above 4g in the guest
68 can be supported in the sense if guest software stack can support recreating
69 enclaves when it suffers sudden lose of EPC; and if guest enclaves can detect
71 with #PF.SGX, guest software can gracefully detect it and recreate enclaves;
[all …]
|
| H A D | kvm-pv.rst | 28 paravirtualized ``KVM`` features to the guest.
34 Expose a ``KVM`` specific paravirtualized clocksource to the guest. Supported
38 The guest doesn't need to perform delays on PIO operations. Supported since
50 Enable stolen (when guest vCPU is not running) time accounting. Supported
67 Enable host-side polling on HLT control from the guest. Supported since Linux
84 Tell the guest that guest visible TSC value can be fully trusted for kvmclock
92 Note, by default, ``KVM`` allows the guest to use all currently supported
93 paravirtualized features even when they were not announced in guest visible
|
| H A D | tdx.rst | 6 with a new kind of virtual machine guest called a Trust Domain (TD). A TD runs
22 TD Guest OS. TDVF needs to be copied to guest private memory and measured before
50 determines the set of extended features available for use by the guest TD.
69 property of "tdx-guest" object. Note, it's users' responsibility to provide a
73 supported by it, via properties of "tdx-guest" object.
103 To launch a TD, the necessary command line options are tdx-guest object and
111 -object tdx-guest,id=tdx0 \\
112 -machine ...,confidential-guest-support=tdx0 \\
120 This is set by default for TDX guest if kernel-irqchip is left on its default
125 - No SMM support: SMM support requires manipulating the guest register states
[all …]
|
| /qemu/qapi/ |
| H A D | run-state.json | 16 # @finish-migrate: guest is paused to finish the migration process
18 # @inmigrate: guest is paused waiting for an incoming migration. Note
24 # @internal-error: An internal error that prevents further guest
30 # @paused: guest has been paused via the 'stop' command
32 # @postmigrate: guest is paused following a successful 'migrate'
34 # @prelaunch: QEMU was started with -S and guest has not started
36 # @restore-vm: guest is paused to restore VM state
38 # @running: guest is actively running
40 # @save-vm: guest is paused to save the VM state
42 # @shutdown: guest is shut down (and -no-shutdown is in use)
[all …]
|
| H A D | misc-i386.json | 10 # be used if another mechanism to synchronize guest time is in effect,
11 # for example QEMU guest agent's guest-set-time command.
31 # @uninit: The guest is uninitialized.
33 # @launch-update: The guest is currently being launched; plaintext
36 # @launch-secret: The guest is currently being launched; ciphertext
39 # @running: The guest is fully launched or migrated in.
41 # @send-update: The guest is currently being migrated out to another
44 # @receive-update: The guest is currently being migrated from another
56 # An enumeration indicating the type of SEV guest being run.
58 # @sev: The guest is a legacy SEV or SEV-ES guest.
[all …]
|
| H A D | dump.json | 8 # = Dump guest memory
14 # An enumeration of guest-memory-dump's format.
49 # @dump-guest-memory:
51 # Dump guest's memory to vmcore. It is a synchronous operation that
52 # can take very long depending on the amount of guest memory.
54 # @paging: if true, do paging to get guest's memory mapping. This
58 # gigabytes of RAM. This can happen for a large guest, or a
59 # malicious guest pretending to be large.
63 # 1. The guest may be in a catastrophic state or can have
65 # 2. The guest can be in real-mode even if paging is enabled. For
[all …]
|
| H A D | qdev.json | 88 # Remove a device from a guest
96 # from the guest. Hot removal is an operation that requires guest
97 # cooperation. This command merely requests that the guest begin
101 # guest-side error in the hot removal process is detected, the
125 # the guest. At this point, it's safe to reuse the specified device
126 # ID. Device removal can be initiated by the guest or by HMP/QMP
148 # Emitted when a device hot unplug fails due to a guest reported
170 # Synchronize device configuration from host to guest part. First,
171 # copy the configuration from the host part (backend) to the guest
172 # part (frontend). Then notify guest software that device
[all …]
|
| /qemu/docs/interop/ |
| H A D | virtio-balloon-stats.rst | 4 The virtio balloon driver supports guest memory statistics reporting. These
10 guest-stats-polling-interval property. This value can be:
21 polling the guest's balloon driver for new stats in the specified time
24 To retrieve those stats, clients have to query the guest-stats property,
27 * A key named 'stats', containing all available stats. If the guest
44 a buggy guest can't influence its value. The value is 0 if the guest
52 - As noted above, if a guest doesn't support a particular stat its value
53 will always be -1. However, it's also possible that a guest temporarily
57 - Polling can be enabled even if the guest doesn't have stats support
58 or the balloon driver wasn't loaded in the guest. If this is the case
[all …]
|
| /qemu/hw/ppc/ |
| H A D | spapr_nested.c | 76 SpaprMachineStateNestedGuest *guest; in spapr_get_pate_nested_papr() local
78 guest = spapr_get_nested_guest(spapr, lpid); in spapr_get_pate_nested_papr()
79 if (!guest) { in spapr_get_pate_nested_papr()
83 entry->dw0 = guest->parttbl[0]; in spapr_get_pate_nested_papr()
84 entry->dw1 = guest->parttbl[1]; in spapr_get_pate_nested_papr()
562 static bool spapr_nested_vcpu_check(SpaprMachineStateNestedGuest *guest, in spapr_nested_vcpu_check() argument
575 if (!(vcpuid < guest->nr_vcpus)) { in spapr_nested_vcpu_check()
579 vcpu = &guest->vcpus[vcpuid]; in spapr_nested_vcpu_check()
597 SpaprMachineStateNestedGuest *guest, in get_vcpu_state_ptr() argument
600 assert(spapr_nested_vcpu_check(guest, vcpuid, false)); in get_vcpu_state_ptr()
[all …]
|
| /qemu/docs/system/ |
| H A D | confidential-guest-support.rst | 5 guest's memory and other state, meaning that a compromised hypervisor
14 this from other aspects of guest security (such as security against
20 To run a confidential guest you need to add two command line parameters:
22 1. Use ``-object`` to create a "confidential guest support" object. The
25 2. Set the ``confidential-guest-support`` machine parameter to the ID of
32 -machine ...,confidential-guest-support=sev0 \
33 -object sev-guest,id=sev0,cbitpos=47,reduced-phys-bits=1
38 Currently supported confidential guest mechanisms are:
|
| H A D | cpu-models-x86.rst.inc | 6 protecting guest OS against various CPU hardware flaws, and optionally
16 the guest. Note that KVM may filter out some host CPU model features
19 stable CPU is exposed to the guest across hosts. This is the
26 Intel and AMD. These allow the guest VMs to have a degree of
31 features, to alter what is presented to the guest by default.
147 can be used for guest CPUs.
156 be used for guest CPUs.
166 can be used for guest CPUs.
169 Recommended to allow guest OS to use 1GB size pages.
186 can be used for guest CPUs.
[all …]
|
| H A D | security.rst | 23 use cases rely on hardware virtualization extensions to execute guest code
50 QEMU to provide guest isolation or any security guarantees.
61 Guest isolation is the confinement of guest code to the virtual machine. When
62 guest code gains control of execution on the host this is called escaping the
67 QEMU presents an attack surface to the guest in the form of emulated devices.
68 The guest must not be able to gain control of QEMU. Bugs in emulated devices
70 guest has escaped the virtual machine and is able to act in the context of the
74 malicious guest must not gain control of other guests or access their data.
83 each process only has access to resources belonging to the guest.
86 to the guest. This way the guest does not gain anything by escaping into the
[all …]
|
| H A D | guest-loader.rst | 7 The guest loader is similar to the ``generic-loader`` although it is
12 The guest loader does two things:
24 …-device guest-loader,addr=0x42000000,kernel=Image,bootargs="root=/dev/sda2 ro console=hvc0 earlypr…
25 -device guest-loader,addr=0x47000000,initrd=rootfs.cpio
28 parameter and passed its boot arguments via -append. The Dom0 guest
40 The full syntax of the guest-loader is::
42 -device guest-loader,addr=<addr>[,kernel=<file>,[bootargs=<args>]][,initrd=<file>]
|
| /qemu/docs/specs/ |
| H A D | pvpanic.rst | 4 pvpanic device is a simulated device, through which a guest panic
9 and/or polling for guest-panicked RunState, to learn when the pvpanic
27 a guest panic has happened and should be processed by the host
29 a guest panic has happened and will be handled by the guest;
31 the execution of the guest.
33 a regular guest shutdown has happened and should be processed by the host
51 To determine whether guest panic notification is supported.
61 To send a guest panic event.
|
| H A D | ppc-spapr-hcalls.rst | 11 The subset in LoPAR is selected based on the requirements of Linux as a guest.
15 running in the guest and QEMU.
24 generally provided by the firmware inside the guest to the operating system. It
30 "firmware" blob in the guest is a small stub of a few instructions which
49 When the guest runs in "real mode" (in powerpc terminology this means with MMU
50 disabled, i.e. guest effective address equals to guest physical address), it
54 non-cacheable accesses to any guest physical addresses that the
55 guest can use in order to access IO devices while in real mode.
57 This is typically used by the firmware running in the guest.
63 This hypercall allows the guest to request a "memory op" to be applied
|
| H A D | ppc-spapr-hotplug.rst | 19 resource to the guest, and provide an interface for the guest to manage
26 the name/index/power-domain/type of each DRC allocated to a guest at
33 for hot plugged resources described under :ref:`guest-host-interface`.
126 particular DRC are configured/managed by the guest via a number of RTAS calls
128 the guest->host interface.
172 made accessible to a guest. Supported sensor values:
174 ``0``: ``isolate``, device is made inaccessible by guest OS.
176 ``1``: ``unisolate``, device is made available to guest OS.
200 guest OS.
206 not currently allocated to the guest OS. Unused in QEMU.
[all …]
|
| /qemu/docs/ |
| H A D | memory-hotplug.txt | 14 memory the guest can grow. This is done at startup time by means of
21 - "megs" is the startup RAM. It is the RAM the guest will boot with
23 - "maxmem" is the maximum RAM size the guest can have
29 Creates a guest with 1GB of memory and three hotpluggable memory slots.
30 The hotpluggable memory slots are empty when the guest is booted, so all
31 memory the guest will see after boot is 1GB. The maximum memory the
32 guest can reach is 4GB. This means that three additional gigabytes can be
41 For example, the following commands add another 1GB to the guest
56 into the guest from the previous section with the following commands:
61 It's also possible to start a guest with memory cold-plugged into the
[all …]
|
| /qemu/docs/system/s390x/ |
| H A D | 3270.rst | 11 single 3270 device available to a guest. Note that this supports basic
14 To provide a 3270 device to a guest, create a ``x-terminal3270`` linked to
15 a ``tn3270`` chardev. The guest will see a 3270 channel device. In order
21 * Make sure that 3270 support is enabled in the guest's Linux kernel. You need
30 * Start the guest. In the guest, use ``chccwdev -e 0.0.000a`` to enable
37 * In the guest, locate the 3270 device node under ``/dev/3270/`` (say,
42 This should get you an additional tty for logging into the guest.
46 the guest's kernel command line. The kernel then should use the 3270 as
|
| H A D | vfio-ap.rst | 75 A KVM guest is started by executing the Start Interpretive Execution (SIE)
77 state information for a KVM guest and is supplied as input to the SIE
80 the adapters, usage domains and control domains assigned to the KVM guest:
83 to the KVM guest. Each bit in the mask, from left to right, corresponds to
85 use by the KVM guest.
88 assigned to the KVM guest. Each bit in the mask, from left to right,
90 corresponding queue is valid for use by the KVM guest.
93 assigned to the KVM guest. The ADM bit mask controls which domains can be
95 guest. Each bit in the mask, from left to right, corresponds to a domain from
106 assigned to a guest, the APQNs (1,5), (1,6), (2,5) and (2,6) will be valid for
[all …]
|
| H A D | vfio-ccw.rst | 5 make certain I/O subchannels and their devices available to a guest. The
57 be presented in the guest (here, ``fe.0.1234``, which will end up visible
58 in the guest as ``0.0.1234``::
63 * Start the guest. The device (here, ``0.0.1234``) should now be usable::
65 [root@guest ~]# lscss -d 0.0.1234
69 [root@guest ~]# chccwdev -e 0.0.1234
72 [root@guest ~]# dmesg -t
|
| /qemu/docs/devel/ |
| H A D | secure-coding-practices.rst | 40 Inputs from the guest or external sources (e.g. network, files) cannot be
42 that could crash the program, expose host memory to the guest, or otherwise be
46 accesses and data read from guest memory must be validated. A typical example
47 is a device that contains multiple units that are selectable by the guest via
73 The guest may access device registers in unusual orders or at unexpected
74 moments. Device emulation code must not assume that the guest follows the
75 typical "theory of operation" presented in driver writer manuals. The guest
81 well-behaved guest might wait for a completion interrupt before accessing
83 guest overwrites registers or submits further requests before an ongoing
101 Guests with multiple vCPUs may modify guest RAM while device emulation code is
[all …]
|
| /qemu/tests/qemu-iotests/ |
| H A D | 087.out | 10 …: TIMESTAMP, "microseconds": TIMESTAMP}, "event": "SHUTDOWN", "data": {"guest": false, "reason":…
21 …: TIMESTAMP, "microseconds": TIMESTAMP}, "event": "SHUTDOWN", "data": {"guest": false, "reason":…
31 …: TIMESTAMP, "microseconds": TIMESTAMP}, "event": "SHUTDOWN", "data": {"guest": false, "reason":…
43 …: TIMESTAMP, "microseconds": TIMESTAMP}, "event": "SHUTDOWN", "data": {"guest": false, "reason":…
55 …: TIMESTAMP, "microseconds": TIMESTAMP}, "event": "SHUTDOWN", "data": {"guest": false, "reason":…
66 …: TIMESTAMP, "microseconds": TIMESTAMP}, "event": "SHUTDOWN", "data": {"guest": false, "reason":…
|