Lines Matching refs:guest
122 Let's now take a look at how AP instructions executed on a guest are interpreted
128 control domains assigned to the KVM guest:
131 to the KVM guest. Each bit in the mask, from left to right, corresponds to
133 use by the KVM guest.
136 assigned to the KVM guest. Each bit in the mask, from left to right,
138 corresponding queue is valid for use by the KVM guest.
141 assigned to the KVM guest. The ADM bit mask controls which domains can be
143 guest. Each bit in the mask, from left to right, corresponds to a domain from
153 adapters 1 and 2 and usage domains 5 and 6 are assigned to a guest, the APQNs
154 (1,5), (1,6), (2,5) and (2,6) will be valid for the guest.
158 at most one guest or to the linux host::
202 domains, and control domains comprising the matrix for a KVM guest.
205 by a KVM guest's SIE state description to grant the guest access to a matrix
249 The process for reserving an AP queue for use by a KVM guest is:
254 all vfio_ap mediated devices used to configure an AP matrix for a guest.
271 used by a guest
273 to be exclusively used by a guest.
371 fields respectively of the KVM guest's CRYCB. This may differ from the
389 * Store the reference to the KVM structure for the guest using the mdev
393 domains available to a guest. A guest may not be provided access to APQNs
399 This will be allowed only if a running guest is not using the mdev.
408 KVM structure used to configure the KVM guest is provided via this callback.
409 The KVM structure, is used to configure the guest's access to the AP matrix
414 matrix mdev device and deconfigures the guest's AP matrix.
420 Configure the guest's AP resources
422 Configuring the AP resources for a KVM guest will be performed when the
424 function is called when userspace connects to KVM. The guest's AP resources are
434 The linux device model precludes passing a device through to a KVM guest that
437 driver will not be assigned to a KVM guest's matrix. The AP architecture,
438 however, does not provide a means to filter individual APQNs from the guest's
442 configuration to a guest:
451 plugged into the guest (i.e., the bit corresponding to its APID will not be
452 set in the APM of the guest's APCB).
459 facility. These features/facilities are made available to a KVM guest via the
462 1. ap: Indicates whether the AP instructions are installed on the guest. This
466 2. apft: Indicates the APFT facility is available on the guest. This facility
467 can be made available to the guest only if it is available on the host (i.e.,
470 3. apqci: Indicates the AP QCI facility is available on the guest. This facility
471 can be made available to the guest only if it is available on the host (i.e.,
475 guest. This facility can be made available to the guest only if it is
484 A guest can be precluded from using AP features/facilities by turning them off
489 Note: If the APFT facility is turned off (apft=off) for the guest, the guest
490 will not see any AP devices. The zcrypt device drivers on the guest that
493 a given AP device. If the APFT facility is not installed on the guest, then no
495 guest because only type 10 and newer devices can be configured for guest use.
916 When the guest is shut down, the vfio_ap mediated devices may be removed.
934 that the remove will fail if a guest using the vfio_ap mdev is still running.
937 remove it if no guest will use it during the remaining lifetime of the linux
944 guest by assigning it to the vfio_ap mediated device being used by the guest if
960 guest by unassigning it from the vfio_ap mediated device being used by the
961 guest.
963 Over-provisioning of AP queues for a KVM guest:
968 available, it will be automatically hot-plugged into the KVM guest using
975 Live guest migration is not supported for guests using AP devices without
976 intervention by a system administrator. Before a KVM guest can be migrated,
979 the mdev is in use by a KVM guest. If the guest is being emulated by QEMU,
980 its mdev can be hot unplugged from the guest in one of two ways:
982 1. If the KVM guest was started with libvirt, you can hot unplug the mdev via
988 the guest named 'my-guest':
990 virsh detach-device my-guest ~/config/my-guest-hostdev.xml
992 The contents of my-guest-hostdev.xml:
1003 virsh qemu-monitor-command <guest-name> --hmp "device-del <device-id>"
1006 qemu command line with 'id=hostdev0' from the guest named 'my-guest':
1010 virsh qemu-monitor-command my-guest --hmp "device_del hostdev0"
1013 to the guest and using the following qemu monitor command:
1018 on the qemu command line with 'id=hostdev0' when the guest was started:
1022 After live migration of the KVM guest completes, an AP configuration can be
1023 restored to the KVM guest by hot plugging a vfio_ap mediated device on the target
1024 system into the guest in one of two ways:
1026 1. If the KVM guest was started with libvirt, you can hot plug a matrix mediated
1027 device into the guest via the following virsh commands:
1032 the guest named 'my-guest':
1034 virsh attach-device my-guest ~/config/my-guest-hostdev.xml
1036 The contents of my-guest-hostdev.xml:
1047 virsh qemu-monitor-command <guest-name> --hmp \
1051 62177883-f1bb-47f0-914d-32a22e3a8804 into the guest named 'my-guest' with
1054 virsh qemu-monitor-command my-guest --hmp \
1060 to the guest and using the following qemu monitor command:
1065 62177883-f1bb-47f0-914d-32a22e3a8804 into the guest with the device-id