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.3Hardware 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.2Character 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

Page 166
Image 166
IBM 10 SP1 EAL4 manual Character device driver, Hardware virtualization and simulation