Conditional interceptions refer to functions that are executed for the guest unless a specified condition
is encountered that causes control to be returned to the host by the process that called the interception.
Following are some of the controls that can cause interception when the related function is handled
for the guest:
Supervisor Call (SVC) instruction: It is to be specified whether all guest SVC instructions cause
an instruction interception or only those for which the effective I field matches a code.
Load Control (LCTL) instruction: The state description bits for this instruction are numbered to
correspond to control-register numbers. When a bit is one and a guest LCTC instruction
designates the corresponding control register in the range of registers to be loaded, instructions-
execution is suppressed, and instruction interception is recognized.
Interception Controls: A bit value of one results in interception when the associated function is
encountered in the guest. The interception code field stores the code that indicates the reason for
the interception. The contents of this field are changed only at interception.

5.9.1.3 Hardware virtualization and simulation

The Control Program (CP) maintains all virtual machines by using the SIE instruction supported by the
underlying abstract machine.
Access to resources that must be shared among virtual machines is virtualized by the CP. The CP must
ensure the following:
Each accessing virtual machine is provided with a consistent view to the virtualized resource, such as
the timer.
Each accessing virtual machine must be limited to their configured resources. Access to other
resources must be prohibited (such as I/O).
Each access to such a virtualized resource causes the SIE instruction to terminate on the requesting processor
and to return control back to the CP. Based on CP’s internal state information about the virtual machine, the
access request is mediated by CP. Upon completion of the request, the return information is forwarded to the
requesting virtual machine by the CP according to the rules applicable for z/Architecture systems.
5.9.2 Character device driver
A character device driver is one that transfers data directly to and from a user process without the
sophisticated buffering strategies and disk caches. The file_operations structure is defined in
linux/fs.h, and holds pointers to functions defined by the driver that performs various operations on the
device. Each field of the structure corresponds to the address of some function defined by the driver to handle
a requested operation.
Programs operate on character devices by opening their file system entries. Each file system entry contains a
major and a minor number, by which the kernel identifies the device. The Virtual File System sets up the file
object for the device, and points the file operations vector to def_chr_fops table. def_chr_fops
contains only one method, chrdev_open(), which rewrites the f_op field of the file object with the
address stored in the chrdevs table element that corresponds to the major number, and minor number if the
major is shared among multiple device drivers, of the character device file.
Ultimately the file object’s f_op field points to the appropriate file_operations defined for that
particular character device. The file_operations structure provides pointers to generic operations that
can be performed on a file. Each device driver defines the file operations that are valid for the type of device
that the driver manages.
154