IBM 10 SP1 EAL4 Manuale Utente
5.5.2.2.7 Run-Time Abstraction Services
System p hardware platforms provide a set of firmware Run-Time Abstraction Services (RTAS) calls. In
LPAR, these calls perform additional validation checking and resource virtualization for the partitioned
environment. For example, although there is only one physical non-volatile RAM chip, and one physical
battery-powered Time-of-Day chip, RTAS makes it appear to each partition as though it has its own non-
volatile RAM area, and its own uniquely settable Time-of-Day clock. Because RTAS calls run inside a
partition with the operating system, even they are not allowed to access anything outside the partition without
a call to the hypervisor.
LPAR, these calls perform additional validation checking and resource virtualization for the partitioned
environment. For example, although there is only one physical non-volatile RAM chip, and one physical
battery-powered Time-of-Day chip, RTAS makes it appear to each partition as though it has its own non-
volatile RAM area, and its own uniquely settable Time-of-Day clock. Because RTAS calls run inside a
partition with the operating system, even they are not allowed to access anything outside the partition without
a call to the hypervisor.
5.5.2.2.8 Preventing denial of service
LPARs run on top of an advanced symmetrical multiprocessor architecture, and some resources are also
implicitly shared by the partitions. The hypervisor is designed to keep partitions from using shared resources
in a way that would deny or restrict access to those resources by other partitions. A key example is the
hypervisor itself, which is implemented as a library of services shared by the partitions. These services are
called within the context of the operating system running in each partition. Each service call is dispatched on
the specific processor from which the call was made, so hypervisor calls execute only on processors owned by
the calling partition. Therefore, regardless of the type and frequency of hypervisor calls made by a partitioned
operating system, they can have no effect on hypervisor usage or access in other partitions.
In a similar fashion, the hypervisor and hardware mechanisms protect shared hardware resources. No
operation within a partition can take exclusive control of a shared hardware resource, or use a shared resource
in a way that inhibits other partitions' access.
implicitly shared by the partitions. The hypervisor is designed to keep partitions from using shared resources
in a way that would deny or restrict access to those resources by other partitions. A key example is the
hypervisor itself, which is implemented as a library of services shared by the partitions. These services are
called within the context of the operating system running in each partition. Each service call is dispatched on
the specific processor from which the call was made, so hypervisor calls execute only on processors owned by
the calling partition. Therefore, regardless of the type and frequency of hypervisor calls made by a partitioned
operating system, they can have no effect on hypervisor usage or access in other partitions.
In a similar fashion, the hypervisor and hardware mechanisms protect shared hardware resources. No
operation within a partition can take exclusive control of a shared hardware resource, or use a shared resource
in a way that inhibits other partitions' access.
5.5.2.3 System p native mode
This section describes memory addressing and memory management of System p in native mode. Note that
SLES runs on System p in LPAR mode.
SLES runs on System p in LPAR mode.
98
Figure 5-38: DMA addressing