Home
last modified time | relevance | path

Searched refs:guest (Results 1 – 25 of 94) sorted by relevance

1234

/xen/tools/examples/
A Dxlexample.hvm2 # Example HVM guest configuration
6 # HVM guest. For a more complete guide see xl.cfg(5)
8 # This configures an HVM rather than PV guest
16 # The default behavior is to generate a new UUID each time the guest is started.
20 # enlightenment interfaces. Turning this on can improve Windows guest
29 # (this assumes guest kernel support for ballooning)
43 disk = [ '/dev/vg/guest-volume,raw,xvda,rw' ]
A Dxlexample.pvhlinux2 # Example PVH Linux guest configuration
6 # PVH Linux guest. For a more complete guide see xl.cfg(5)
8 # This configures a PVH rather than PV guest
16 # The default behavior is to generate a new UUID each time the guest is started.
42 disk = [ '/dev/zvol/tank/guest-volume,raw,xvda,rw' ]
A Dxlexample.pvlinux2 # Example PV Linux guest configuration
6 # Paravirtualised Linux guest. For a more complete guide see xl.cfg(5)
13 # The default behavior is to generate a new UUID each time the guest is started.
30 # (this assumes guest kernel support for ballooning)
44 disk = [ '/dev/vg/guest-volume,raw,xvda,rw' ]
/xen/docs/man/
A Dxen-pv-channel.7.pod22 to signal/query an in-guest agent
23 (example use: oVirt's guest agent)
47 Install a guest as normal (no channel configuration necessary)
53 prepare the guest to communicate over the channel, and also prepare
54 the guest to be cloned safely (sometimes known as "sysprepping")
59 Shutdown the guest
93 name expected by the in-guest agent. In xl syntax this would be:
136 The in-guest agent completes the handshake with the dom0 agent
147 The in-guest agent receives the configuration and applies it.
186 N: org.xenproject.guest.clipboard.0.1
[all …]
A Dxl.cfg.5.pod.in22 any guest type, while others relate only to specific guest types
177 of the guest will run on CPU 2 of the host and vCPU 1 of the guest will
442 is guest specific).
447 is guest specific).
516 Whether to boot this guest as a PV guest within a PVH container.
1213 video BIOS to the guest memory, and executes the VBIOS in the guest
1683 Exposing the host e820 to the guest gives the guest kernel the
1951 Alternate-p2m allows a guest to manage multiple p2m guest physical
1970 of Xen) within a Xen guest or to support a guest Operating System
2231 to be exposed to the guest Operating System in an HVM guest.
[all …]
A Dxen-vbd-interface.7.pandoc1 Xen guest interface
4 A Xen guest can be provided with block devices. These are always
15 Xen VBD. The HVM guest is entitled to assume that the IDE or SCSI
21 For PV guests every device is made available to the guest only as a
23 guest's device naming scheme.
26 in the guest (nor what major/minor device number it should have in
27 the guest, if the guest has such a concept).
36 which case the guest is expected to treat it as they would a native
41 guest should expect storage management to be done by the host and
101 Notes on Linux as a guest
[all …]
A Dxl.conf.5.pod162 If this option is enabled then when a guest is created there will be an
163 guarantee that there is memory available for the guest.
172 If the reservation cannot be meet the guest creation fails immediately
173 instead of taking seconds/minutes (depending on the size of the guest)
174 while the guest is populated.
182 No claim is made. Memory population during guest creation will be
188 calculating whether there is enough memory free to launch a guest.
189 This guarantees immediate feedback whether the guest can be launched due
203 C<vm.cpumask> applies to all guest types, C<vm.hvm.cpumask> applies to
206 The hard affinity of guest's vcpus are logical-AND'ed with respective
/xen/docs/
A Dglossary.rst18 The terms :term:`domain` and :term:`guest` are commonly used
21 A guest is a single, end user, virtual machine.
23 In some cases, e.g. during live migration, one guest will be comprised of
31 guest
32 The term 'guest' has two different meanings, depending on context, and
35 When discussing a Xen system as a whole, a 'guest' refer to a virtual
41 In the code, "guest context" and "guest state" is considered in terms of
52 is responsible for multiplexing guest I/O.
/xen/docs/guest-guide/x86/
A Dhypercall-abi.rst6 Hypercalls are system calls to Xen. Two modes of guest operation are
14 The registers used for hypercalls depends on the operating mode of the guest.
34 32 and 64bit PV guests have an ABI fixed by their guest type. The ABI for an
35 HVM guest depends on whether the vCPU is operating in a 64bit segment or not
43 potentially clobbers each of its parameter registers; a guest may not rely on
46 guest.
74 Hypercall Page. This allows a guest to make a hypercall without needing to
87 Multiple hypercall pages may be created by the guest, if it wishes.
97 hardware vendor. This is intended to simplify guest kernel interfaces by
109 Any guest can locate the Xen CPUID leaves and read the *hypercall transfer
[all …]
/xen/xen/lib/x86/
A Dpolicy.c6 const struct cpu_policy *guest, in x86_cpu_policies_are_compatible() argument
18 if ( guest->cpuid->basic.max_leaf > host->cpuid->basic.max_leaf ) in x86_cpu_policies_are_compatible()
21 if ( guest->cpuid->extd.max_leaf > host->cpuid->extd.max_leaf ) in x86_cpu_policies_are_compatible()
26 if ( ~host->msr->platform_info.raw & guest->msr->platform_info.raw ) in x86_cpu_policies_are_compatible()
/xen/docs/designs/
A Dnon-cooperative-migration.md5 The normal model of migration in Xen is driven by the guest because it was
6 originally implemented for PV guests, where the guest must be aware it is
9 least the privileged software running in the guest (i.e. the guest kernel)
13 running in the guest, and is thus suitable for cloud scenarios.
19 x86 HVM guests can already be migrated on Xen without guest co-operation
61 * `frontend-id`: the domid of the guest domain
64 The guest domain only has write permission to the frontend area and
98 service domain, so the co-operation of the guest is required to
137 to be preserved for an HVM guest.
141 an HVM guest where the P2M is not directly manipulated via the guest. The
[all …]
/xen/docs/misc/
A Dx86-xenpv-bootloader.pandoc5 One method for booting an x86 Xen PV guest is to use a PV bootloader,
11 the guest, and therefore wishes to chainload something from the guest
14 The purpose of this document is to define the paths within the guest
15 filesystem where a stage 1 bootloader should look for the in-guest PV
27 The second stage bootloader should be installed into the guest
48 present in a guest to be used by the appropriate stage 1 (e.g. for
A Dxenpaging.txt5 guest memory and its filesystems!
9 xenpaging writes memory pages of a given guest to a file and moves the
26 started manually for each guest.
28 Once the guest is running, run xenpaging with the guest_id and the path
34 footprint of the guest. This value (in KiB) must be written manually to
40 footprint of the guest at 512MB.
A Dxenstore-paths.pandoc95 * n -- Path is neither readable nor writeable for guest domains.
158 One node for each virtual CPU up to the guest's configured
187 guest and hence it may create the suspend event channel path.
191 an interdomain bind, and then, when it wishes to ask the guest to
198 `XEN_DOMCTL_subscribe` to be alerted to guest state changes, and
215 will not relocate guest memory.
278 read-only to the guest. However it may writable if the
460 ~/control path is read-only to a guest, a guest should not expect a
481 Indicates to the guest that this platform supports the
549 in the value supplied by the guest in this case).
[all …]
A Dxenstore-ring.txt2 shared between the xenstore server and the guest. The ring contains
42 When the guest domain is created, there is no outstanding Input or Output
52 guest and server are free to inspect the contents of the ring at any
59 i.e. bits will never be cleared. The guest is not permitted to write to
60 the server feature bitmap. The server features are offered to the guest;
61 it is up to the guest whether to use them or not. The guest should ignore
84 The ring reconnection feature allows the guest to ask the server to
95 Assuming the server has advertised the feature, the guest can initiate
98 The guest must now ignore all fields except the Connection state and
112 From the point of view of the guest, the connection has been reset on a
[all …]
A Dvtpm-platforms.txt17 vTPM Manager and vTPMs. The vtpmmgr, vtpm, and guest domains are created using
50 The guest configuration files (guest1.cfg, guest2.cfg):
94 vtpmmgr domain. The two guest domains may be instantiated using pv-grub or
124 which requires the presence of a vTPM. To bind the configuration of the guest
125 to the vTPM, the guest may use full-disk encryption which can be unlocked using
127 guest.
130 5, it must not be possible to attach to a guest's vTPM without booting a fresh
131 guest image. This requires pairing every vTPM's launch with the launch of a
132 guest, as described above, and using the --vtpm-label= argument to pv-grub so
133 that it refuses to launch a guest if it could not write to the vTPM. To permit
[all …]
A Dvtd.txt21 10) lspci - select the PCI BDF you want to assign to guest OS
44 15) start hvm guest and use "lspci" to see the passthru device and
82 13) start hvm guest and use "lspci" to see the passthru device and
98 available if the guest enables it.
101 available, regardless of whether the guest uses INTx or MSI. If the
102 guest uses INTx IRQ, Xen will inject a translated INTx IRQ to guest's
104 interrupt sharing of the system. If the guest OS enables MSI or MSI-X,
173 …2. Detach the device from the guest by the physical BDF. Then HVM guest will receive a virtual PCI…
177 … device to the guest by the physical BDF and desired virtual slot(optional). Following command wou…
244 devices (Virtual Function) and assign them to the HVM guest.
[all …]
/xen/docs/features/
A Dlivepatch.pandoc69 6) Bugs which allow a guest to prevent the application of a livepatch:
70 A guest should not be able to prevent the application of a live
71 patch. If an unprivileged guest can somehow prevent the application
81 1) Is guest->host privilege escalation possible?
85 There is a caveat -- an incorrect live patch can introduce a guest->host
88 2) Is guest user->guest kernel escalation possible?
90 No, although an incorrect live patch can introduce a guest user->guest
96 domains so it is not possible for an unprivileged guest to access the
103 There are no known ways that an unprivileged guest can prevent a live
/xen/tools/debugger/gdbsx/
A DREADME5 Welcome to gdbsx. gdbsx is a gdbserver program to debug guest kernels and
7 of 32 or 64bit PV or HVM elf guest binaries. It can also be run standalone,
8 without remote gdb, to dump context of any/all VCPUs of any guest.
17 - dom0> gdbsx -c 1 64 : displays VCPU contexts for 64bit guest with domid 1
21 connects to a 64bit guest with domid 2 and waits for gdb connection
23 bash> gdb ./vmlinux (exact matching vmlinux of guest kernel)
34 on dom0 to pause the guest. this will break into gdb right away.
36 - if ctrl-c or core-dumped, make sure to do xm unpause if guest still paused.
50 - For now, it is not possible to run gdbsx on a guest and gdb inside
51 the same guest at the same time.
/xen/tools/libxl/
A Dcheck-xl-disk-parse62 one 0 /dev/vg/guest-volume,,hda
63 one 0 /dev/vg/guest-volume,raw,hda,rw
65 one 0 format=raw vdev=hda access=rw target=/dev/vg/guest-volume
66 one 0 raw:/dev/vg/guest-volume,hda,w
95 one 0 backendtype=phy,vdev=xvdb,access=w,target=/dev/vg/guest-volume
/xen/docs/misc/arm/
A Dpassthrough.txt1 Passthrough a device described in the Device Tree to a guest
13 1:1 to the guest (i.e VIRQ == IRQ). For MMIO, you will have to find a hole
14 in the guest memory layout (see xen/include/public/arch-arm.h, note that
58 3) Compile the partial guest device with dtc (Device Tree Compiler).
59 For our purpose, the compiled file will be called guest-midway.dtb and
62 3) Add the following options in the guest configuration file:
64 device_tree = "/root/guest-midway.dtb"
89 the guest:
98 ranges together with the corresponding guest address to map them to.
116 full GIC node that will be added by Xen for the guest. /gic can be
[all …]
/xen/
A DCHANGELOG.md13 - Performance improvements to guest assisted TLB flushes, either when using
28 - The CPUID data seen by a guest on boot is now moved in the migration
29 stream. A guest migrating between non-identical hardware will now no
32 the guest at boot are compatible with anywhere it might migrate.
/xen/docs/figs/
A Dnetwork-bridge.fig71 4 0 0 50 -1 0 20 0.0000 4 270 705 7200 7200 guest\001
112 4 0 0 50 -1 0 20 0.0000 4 300 1785 7155 3420 guest domain\001
A Dnetwork-basic.fig31 4 0 0 50 -1 0 16 0.0000 4 255 1485 4050 4860 guest's traffic\001
69 4 0 0 50 -1 0 20 0.0000 4 300 1785 7155 3420 guest domain\001
/xen/tools/debugger/kdd/
A Dkdd.c297 return kdd_access_physical(s->guest, addr, len, buf, 0); in kdd_read_physical()
303 return kdd_access_physical(s->guest, addr, len, buf, 1); in kdd_write_physical()
315 if (kdd_get_ctrl(s->guest, cpuid, &ctrl, s->os.w64) != 0 in v2p()
316 || kdd_rdmsr(s->guest, cpuid, 0xc0000080, &efer) != 0) in v2p()
812 kdd_halt(s->guest); in kdd_break()
829 s->txp.stc.stop.ncpus = kdd_count_cpus(s->guest); in kdd_break()
855 kdd_guest_identify(s->guest)); in kdd_handle_ack()
1055 ok = (kdd_rdmsr(s->guest, s->cpuid, msr, &val) == 0); in kdd_handle_read_msr()
1069 ok = (kdd_wrmsr(s->guest, s->cpuid, msr, val) == 0); in kdd_handle_write_msr()
1154 kdd_run(s->guest); in kdd_handle_pkt()
[all …]

Completed in 30 milliseconds

1234