DOCSLIB.ORG

Openvms – 30 Years of Reliable and Secure Computing

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Openvms – 30 Years of Reliable and Secure Computing OpenVMS – 30 Yea rs of Relia ble a nd S ecure Computing Andy Golds tein OpenVMS Eng ineering © 2007 Hewlett-Packard Development Company, L.P. The informa tion contained herein is s ubject to cha nge without notice 30 Years of Evolution VMS in 1977 ● Dig ital’s 32 bit s upermini ● Terminals & times haring ● Fortran: eng ineering , s imulation ● 1.5M lines of code in bas e s ys tem 10/03/07 30 Years of Evolution VMS Now ● $3K works tations to $25M multi-s ite clus ters ● VAX, Alpha and, Itanium cpu ● Factory floor, interbank EFT, bus ines s trans actions , traffic control, databas e, internet s erver ● > 25M lines of code ● More reliable than ever ● Mos t V1 apps s till work 10/03/07 Major Evolutions in VMS ● DECwindows ● Clus ters ● S ymmetric Multiproces s ing ● Alpha Port ● Memory Manag ement Redes ig n ● Itanium Port 10/03/07 Overview of VMS Org anization ● Proces s : addres s s pace + thread(s ) of execution ● Demand pag ed, virtual memory ● Partitioned addres s s pace: ● P0: application code & data ● P1: s tacks and proces s -s pecific OS context ● P2: 64 bit extended proces s s pace ● S 0: OS code & g lobal data ● S 2: 64 bit extended s ys tem s pace 10/03/07 Overview of VMS Org anization ● Proces s acces s modes ● Us er ● S upervis or - DCL ● Exec - hig her OS layers ● Kernel ● S tack per acces s mode 10/03/07 Overview of VMS Org anization ● Interrupt (fork) context ● Kernel mode, hardware IPL ● S ys tem s pace only ● Limited s tack ● “Lig htweig ht thread” model ● AS T: as ynchronous procedure call ● Proces s equivalent of interrupt context 10/03/07 I/O S ubs ys tem ● $QIO s ervice in proces s context ● Loadable device drivers ● Driver pre-proces s ing in us er context ● Driver fork level ● I/O interrupt driver fork ● Proces s context completion AS T ● ACP - ancillary control proces s 10/03/07 DECwindows VMS becomes a works tation ● Graphics device drivers ● Port of X-11 and OS F Motif ● S es s ion manag er menu items : ● DCL s hell s cript ● Exis ting character cell apps : ● Partition into character cell UI and callable application log ic ● Add new windows UI 10/03/07 Clus ters VMS Becomes a Dis tributed Operating S ys tem VMS VMS VMS Node Node Node Storage Storage Ctrl Ctrl 10/03/07 Clus ters : The Lock Manag er ● Abs tract named res ources ● Lock modes to repres ent typical data acces s : ● EX ● PW ● PR ● CW ● CR ● NL 10/03/07 RMS and the Lock Manag er RMS Features ● Record-oriented I/O packag e ● S equential, direct, indexed ● Coherent s hared write acces s with record locking ● Proces s local buffers with coherent cache manag ement Private locking implementation replaced with clus ter lock manag er 10/03/07 Before Clus ters : File ACP S erver proces s intercepts complex file operations ● Open file context in s ys tem pool ● File metadata cache in proces s context ● S ing le thread operation provided implicit s ynchronization 10/03/07 Clus ters : the File XQP ● Clus ter implementation choices ● S ing le s erver with failover ● Multiple coordinated ACPs ● S erver proces s converted to run in client proces s context ● Cache moved to s ys tem pool ● S imple threading packag e layered on AS T mechanis m ● Explicit s ynchronization with lock manag er 10/03/07 S ymmetric Multiproces s ing Orig inal kernel s ynchronization des ig ned for uniproces s or: ● IPL 24-31: clock, cpu errors ● IPL 16-23: I/O interrupts ● IPL 8-11: device driver threads ● IPL 8: scheduling, memory management, kernel-level messages, etc. ● IPL 4: I/O completion processing ● IPL 3: process rescheduling ● IPL 2: AST delivery ● IPL 0: process execution 10/03/07 S ymmetric Multiproces s ing Implicit IPL s ynchronization replaced with explicit s pinlocks ● Each IPL becomes a s pinlock ● IPL 8 broken into functional areas ● Memory Manag ement ● S cheduling ● Clus ter communications ● File s ys tem ● etc. ● Continuing to refine locking 10/03/07 S MP Convers ion Brute force effort ● Entire kernel ins pected for s ynchronization ● Aided by exis ting macros (DS BINT, ENBINT, S ETIPL) ● Counters converted to interlocked ins tructions ● S pinlock rank des ig n detects des ig n deadlocks ● Debug and production locking macros 10/03/07 Port to Alpha VMS and VAX were made for each other ● Privileg ed architecture (memory manag ement, acces s modes , IPLs , etc.) ● Variable leng th CIS C ins tructions , 32 bit architecture ● Mos t of VMS kernel in macro 10/03/07 Port to Alpha Alpha is ● 64 bit architecture ● Fixed leng th RIS C ins truction But… ● VAX-like privileg ed architecture ● Compatible datatypes 10/03/07 Port to Alpha Rewrite: ● CPU s upport ● Boot code ● S ome drivers ● Low level memory manag ement ● Exception handling ● Math RTL 10/03/07 Port to Alpha Compile everything els e: ● Blis s & C ● Macro! ● 32 bit vs 64 bit ● Compilable macro ● Atomicity is s ues ● Executable imag es !! Res ult: “It’s really VMS . It even has the s ame bug s .” - early Alpha us er 10/03/07 64 Bit Virtual Memory • Orig inal pag e table des ig n Page OFF S 0 S pace Data Pag e Page OFF Da ta 10/03/07 64 Bit Virtual Memory • Extended virtual addres s ing L1 L2 L3 OFF L1PT L2PT L1 L3PT L2 Data Pag e L3 OFF Data 10/03/07 64 Bit Virtual Memory • Pag e table reference K L1 L2 L3 L1PT L2PT K L 1 L3PT L2 L3 10/03/07 Port to Itanium • Another 64-bit architecture, but... • Different reg is ter conventions • Intel calling s tandard • Different privileg ed architecture −No PALcode −Different console / boot procedure −Different interrupt architecture −Different synchronization primitives 10/03/07 Port to Itanium • Fortunately... • 4 acces s modes • Compatible memory protection features • Memory atomicity no wors e than Alpha 10/03/07 Port to Itanium • Rewrite −CPU support −Boot code • New −Interrupt & exception delivery in software −Emulation of interlocked instructions (queues, etc.) −EFI partition on system disk • Redes ig n −Calling standard and condition handling −Object and executable file format 10/03/07 Port to Itanium • Recompile • 95% of bas e OS code recompiled without chang e • Binary trans lator als o available 10/03/07 Part 2 Building a S ecure Operating S ys tem – the VMS Approach 10/03/07 What is S ecurity? Us ers ' data handled according to a s ecurity policy • Policy mus t meet us ers ' needs • Policy mus t always be correctly handled s o... • Conceptually, s ecurity is very s imple • In practice, s ecurity is fractal (Butler Lamps on) 10/03/07 General Concepts • Reference monitor −Textbook model −Two examples • S ys tem layering – the textbook and reality −Textbook model −The reality of VMS • Typical privileg ed s ubs ys tem 10/03/07 Copyright © 2007 HP corporate pres entation. All rights res erved. 31 Reference Monitor The textbook model Reference Us er Monitor Data Authorization Audit Databas e Trail 10/03/07 Copyright © 2007 HP corporate pres entation. All rights res erved. 32 Reference Monitor • All object acces s es are controlled by the reference monitor • The authorization databas e determines the acces s control policy • Object acces s es may be recorded in the audit log • The reference monitor, authorization databas e, and audit log are tamperproof therefore... • The reference monitor implementation mus t be correct 10/03/07 Copyright © 2007 HP corporate pres entation. All rights res erved. 33 Reference Monitor Two Examples • An acces s to a file −The file represents the data object −The rights database and the file's ACL contain the authorization information −The access may be audited • The $S ETSWM s ervice −A single bit of process state represents the data object −The authorization database is the PSWAPM privilege −Audit capability exists 10/03/07 Copyright © 2007 HP corporate pres entation. All rights res erved. 34 S ys tem Layering The Textbook Model Kernel (trusted) User Mode (untrusted) 10/03/07 Copyright © 2007 HP corporate pres entation. All rights res erved. 35 S ys tem Layering Development Tools Command Language Interpreter •Text editors •Macro •Compilers Privileged Images •Linker •Images installed with privilege RMS and System Services •Protected shareable images •Protected subsystems $OPEN •Privileged server processes $GET •Informational utilities System Services $IMGACT $PUT $CRETVA $ASSIGN $CLOSE $ADJWSL Run Time Library $CRMPSC Memory I/O $QIO Management Subsystem (General) •Math library $CANCEL •Device •String handling Drivers •Screen management •Pagefault System-wide •I/O Support •Misc LIB functions •Swapper Protected Routines Data Structures •Page Tables •I/O Database •Scheduler Data Process and Time Management •Scheduler Run Time Library •Process Control (Language-specific) $WAKE •CRTL $CREPRC •FORTRAN Assorted Utilities •PASCAL $SETIMR •COPY •BASIC •HELP •DIRECTORY •SORT 10/03/07 Copyright © 2007 HP corporate pres entation. All rights res erved. 36 Typical Privileg ed S ubs ys tem Privileg ed VMS Us er S ubs ys tem S ervices Us er Private Data Data 10/03/07 Copyright © 2007 HP corporate pres entation. All rights res erved. 37 Principles • Who is performing the operation? −A privileged subsystem performs some operations on its own behalf, with its rights and privileges −It performs other operations on behalf of the user. The subsystem must take care not to take any actions the user could not have done by themselves.
Load more

Recommended publications
  • Demystifying the Real-Time Linux Scheduling Latency
    Demystifying the Real-Time Linux Scheduling Latency Daniel Bristot de Oliveira Red Hat, Italy [email protected] Daniel Casini Scuola Superiore Sant’Anna, Italy [email protected] Rômulo Silva de Oliveira Universidade Federal de Santa Catarina, Brazil [email protected] Tommaso Cucinotta Scuola Superiore Sant’Anna, Italy [email protected] Abstract Linux has become a viable operating system for many real-time workloads. However, the black-box approach adopted by cyclictest, the tool used to evaluate the main real-time metric of the kernel, the scheduling latency, along with the absence of a theoretically-sound description of the in-kernel behavior, sheds some doubts about Linux meriting the real-time adjective. Aiming at clarifying the PREEMPT_RT Linux scheduling latency, this paper leverages the Thread Synchronization Model of Linux to derive a set of properties and rules defining the Linux kernel behavior from a scheduling perspective. These rules are then leveraged to derive a sound bound to the scheduling latency, considering all the sources of delays occurring in all possible sequences of synchronization events in the kernel. This paper also presents a tracing method, efficient in time and memory overheads, to observe the kernel events needed to define the variables used in the analysis. This results in an easy-to-use tool for deriving reliable scheduling latency bounds that can be used in practice. Finally, an experimental analysis compares the cyclictest and the proposed tool, showing that the proposed method can find sound bounds faster with acceptable overheads. 2012 ACM Subject Classification Computer systems organization → Real-time operating systems Keywords and phrases Real-time operating systems, Linux kernel, PREEMPT_RT, Scheduling latency Digital Object Identifier 10.4230/LIPIcs.ECRTS.2020.9 Supplementary Material ECRTS 2020 Artifact Evaluation approved artifact available at https://doi.org/10.4230/DARTS.6.1.3.
    [Show full text]
  • Context Switch in Linux – OS Course Memory Layout – General Picture
    ContextContext switchswitch inin LinuxLinux ©Gabriel Kliot, Technion 1 Context switch in Linux – OS course Memory layout – general picture Stack Stack Stack Process X user memory Process Y user memory Process Z user memory Stack Stack Stack tss->esp0 TSS of CPU i task_struct task_struct task_struct Process X kernel Process Y kernel Process Z kernel stack stack and task_struct stack and task_struct and task_struct Kernel memory ©Gabriel Kliot, Technion 2 Context switch in Linux – OS course #1 – kernel stack after any system call, before context switch prev ss User Stack esp eflags cs … User Code eip TSS … orig_eax … tss->esp0 es Schedule() function frame esp ds eax Saved on the kernel stack during ebp a transition to task_struct kernel mode by a edi jump to interrupt and by SAVE_ALL esi macro edx thread.esp0 ecx ebx ©Gabriel Kliot, Technion 3 Context switch in Linux – OS course #2 – stack of prev before switch_to macro in schedule() func prev … Schedule() saved EAX, ECX, EDX Arguments to contex_switch() Return address to schedule() TSS Old (schedule’s()) EBP … tss->esp0 esp task_struct thread.eip thread.esp thread.esp0 ©Gabriel Kliot, Technion 4 Context switch in Linux – OS course #3 – switch_to: save esi, edi, ebp on the stack of prev prev … Schedule() saved EAX, ECX, EDX Arguments to contex_switch() Return address to schedule() TSS Old (schedule’s()) EBP … tss->esp0 ESI EDI EBP esp task_struct thread.eip thread.esp thread.esp0 ©Gabriel Kliot, Technion 5 Context switch in Linux – OS course #4 – switch_to: save esp in prev->thread.esp
    [Show full text]
  • Openvms Record Management Services Reference Manual
    OpenVMS Record Management Services Reference Manual Order Number: AA-PV6RD-TK April 2001 This reference manual contains general information intended for use in any OpenVMS programming language, as well as specific information on writing programs that use OpenVMS Record Management Services (OpenVMS RMS). Revision/Update Information: This manual supersedes the OpenVMS Record Management Services Reference Manual, OpenVMS Alpha Version 7.2 and OpenVMS VAX Version 7.2 Software Version: OpenVMS Alpha Version 7.3 OpenVMS VAX Version 7.3 Compaq Computer Corporation Houston, Texas © 2001 Compaq Computer Corporation Compaq, AlphaServer, VAX, VMS, the Compaq logo Registered in U.S. Patent and Trademark Office. Alpha, PATHWORKS, DECnet, DEC, and OpenVMS are trademarks of Compaq Information Technologies Group, L.P. in the United States and other countries. UNIX and X/Open are trademarks of The Open Group in the United States and other countries. All other product names mentioned herein may be the trademarks of their respective companies. Confidential computer software. Valid license from Compaq required for possession, use, or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor’s standard commercial license. Compaq shall not be liable for technical or editorial errors or omissions contained herein. The information in this document is provided "as is" without warranty of any kind and is subject to change without notice. The warranties for Compaq products are set forth in the express limited warranty statements accompanying such products. Nothing herein should be construed as constituting an additional warranty.
    [Show full text]
  • What Is an Operating System III 2.1 Compnents II an Operating System
    Page 1 of 6 What is an Operating System III 2.1 Compnents II An operating system (OS) is software that manages computer hardware and software resources and provides common services for computer programs. The operating system is an essential component of the system software in a computer system. Application programs usually require an operating system to function. Memory management Among other things, a multiprogramming operating system kernel must be responsible for managing all system memory which is currently in use by programs. This ensures that a program does not interfere with memory already in use by another program. Since programs time share, each program must have independent access to memory. Cooperative memory management, used by many early operating systems, assumes that all programs make voluntary use of the kernel's memory manager, and do not exceed their allocated memory. This system of memory management is almost never seen any more, since programs often contain bugs which can cause them to exceed their allocated memory. If a program fails, it may cause memory used by one or more other programs to be affected or overwritten. Malicious programs or viruses may purposefully alter another program's memory, or may affect the operation of the operating system itself. With cooperative memory management, it takes only one misbehaved program to crash the system. Memory protection enables the kernel to limit a process' access to the computer's memory. Various methods of memory protection exist, including memory segmentation and paging. All methods require some level of hardware support (such as the 80286 MMU), which doesn't exist in all computers.
    [Show full text]
  • Chapter 1. Origins of Mac OS X
    1 Chapter 1. Origins of Mac OS X "Most ideas come from previous ideas." Alan Curtis Kay The Mac OS X operating system represents a rather successful coming together of paradigms, ideologies, and technologies that have often resisted each other in the past. A good example is the cordial relationship that exists between the command-line and graphical interfaces in Mac OS X. The system is a result of the trials and tribulations of Apple and NeXT, as well as their user and developer communities. Mac OS X exemplifies how a capable system can result from the direct or indirect efforts of corporations, academic and research communities, the Open Source and Free Software movements, and, of course, individuals. Apple has been around since 1976, and many accounts of its history have been told. If the story of Apple as a company is fascinating, so is the technical history of Apple's operating systems. In this chapter,[1] we will trace the history of Mac OS X, discussing several technologies whose confluence eventually led to the modern-day Apple operating system. [1] This book's accompanying web site (www.osxbook.com) provides a more detailed technical history of all of Apple's operating systems. 1 2 2 1 1.1. Apple's Quest for the[2] Operating System [2] Whereas the word "the" is used here to designate prominence and desirability, it is an interesting coincidence that "THE" was the name of a multiprogramming system described by Edsger W. Dijkstra in a 1968 paper. It was March 1988. The Macintosh had been around for four years.
    [Show full text]
  • Hiding Process Memory Via Anti-Forensic Techniques
    DIGITAL FORENSIC RESEARCH CONFERENCE Hiding Process Memory via Anti-Forensic Techniques By: Frank Block (Friedrich-Alexander Universität Erlangen-Nürnberg (FAU) and ERNW Research GmbH) and Ralph Palutke (Friedrich-Alexander Universität Erlangen-Nürnberg) From the proceedings of The Digital Forensic Research Conference DFRWS USA 2020 July 20 - 24, 2020 DFRWS is dedicated to the sharing of knowledge and ideas about digital forensics research. Ever since it organized the first open workshop devoted to digital forensics in 2001, DFRWS continues to bring academics and practitioners together in an informal environment. As a non-profit, volunteer organization, DFRWS sponsors technical working groups, annual conferences and challenges to help drive the direction of research and development. https://dfrws.org Forensic Science International: Digital Investigation 33 (2020) 301012 Contents lists available at ScienceDirect Forensic Science International: Digital Investigation journal homepage: www.elsevier.com/locate/fsidi DFRWS 2020 USA d Proceedings of the Twentieth Annual DFRWS USA Hiding Process Memory Via Anti-Forensic Techniques Ralph Palutke a, **, 1, Frank Block a, b, *, 1, Patrick Reichenberger a, Dominik Stripeika a a Friedrich-Alexander Universitat€ Erlangen-Nürnberg (FAU), Germany b ERNW Research GmbH, Heidelberg, Germany article info abstract Article history: Nowadays, security practitioners typically use memory acquisition or live forensics to detect and analyze sophisticated malware samples. Subsequently, malware authors began to incorporate anti-forensic techniques that subvert the analysis process by hiding malicious memory areas. Those techniques Keywords: typically modify characteristics, such as access permissions, or place malicious data near legitimate one, Memory subversion in order to prevent the memory from being identified by analysis tools while still remaining accessible.
    [Show full text]
  • The Evolution of the Unix Time-Sharing System*
    The Evolution of the Unix Time-sharing System* Dennis M. Ritchie Bell Laboratories, Murray Hill, NJ, 07974 ABSTRACT This paper presents a brief history of the early development of the Unix operating system. It concentrates on the evolution of the file system, the process-control mechanism, and the idea of pipelined commands. Some attention is paid to social conditions during the development of the system. NOTE: *This paper was first presented at the Language Design and Programming Methodology conference at Sydney, Australia, September 1979. The conference proceedings were published as Lecture Notes in Computer Science #79: Language Design and Programming Methodology, Springer-Verlag, 1980. This rendition is based on a reprinted version appearing in AT&T Bell Laboratories Technical Journal 63 No. 6 Part 2, October 1984, pp. 1577-93. Introduction During the past few years, the Unix operating system has come into wide use, so wide that its very name has become a trademark of Bell Laboratories. Its important characteristics have become known to many people. It has suffered much rewriting and tinkering since the first publication describing it in 1974 [1], but few fundamental changes. However, Unix was born in 1969 not 1974, and the account of its development makes a little-known and perhaps instructive story. This paper presents a technical and social history of the evolution of the system. Origins For computer science at Bell Laboratories, the period 1968-1969 was somewhat unsettled. The main reason for this was the slow, though clearly inevitable, withdrawal of the Labs from the Multics project. To the Labs computing community as a whole, the problem was the increasing obviousness of the failure of Multics to deliver promptly any sort of usable system, let alone the panacea envisioned earlier.
    [Show full text]
  • Context Switch Overheads for Linux on ARM Platforms
    Context Switch Overheads for Linux on ARM Platforms Francis David [email protected] Jeffrey Carlyle [email protected] Roy Campbell [email protected] http://choices.cs.uiuc.edu Outline What is a Context Switch? ◦ Overheads ◦ Context switching in Linux Interrupt Handling Overheads ARM Experimentation Platform Context Switching ◦ Experiment Setup ◦ Results Interrupt Handling ◦ Experiment Setup ◦ Results What is a Context Switch? Storing current processor state and restoring another Mechanism used for multi-tasking User-Kernel transition is only a processor mode switch and is not a context switch Sources of Overhead Time spent in saving and restoring processor state Pollution of processor caches Switching between different processes ◦ Virtual memory maps need to be switched ◦ Synchronization of memory caches Paging Context Switching in Linux Context switch can be implemented in userspace or in kernelspace New 2.6 kernels use Native POSIX Threading Library (NPTL) NPTL uses one-to-one mapping of userspace threads to kernel threads Our experiments use kernel 2.6.20 Outline What is a Context Switch? ◦ Overheads ◦ Context switching in Linux Interrupt Handling Overheads ARM Experimentation Platform Context Switching ◦ Experiment Setup ◦ Results Interrupt Handling ◦ Experiment Setup ◦ Results Interrupt Handling Interruption of normal program flow Virtual memory maps not switched Also causes overheads ◦ Save and restore of processor state ◦ Perturbation of processor caches Outline What is a Context Switch? ◦ Overheads ◦ Context switching
    [Show full text]
  • Lecture 4: September 13 4.1 Process State
    CMPSCI 377 Operating Systems Fall 2012 Lecture 4: September 13 Lecturer: Prashant Shenoy TA: Sean Barker & Demetre Lavigne 4.1 Process State 4.1.1 Process A process is a dynamic instance of a computer program that is being sequentially executed by a computer system that has the ability to run several computer programs concurrently. A computer program itself is just a passive collection of instructions, while a process is the actual execution of those instructions. Several processes may be associated with the same program; for example, opening up several windows of the same program typically means more than one process is being executed. The state of a process consists of - code for the running program (text segment), its static data, its heap and the heap pointer (HP) where dynamic data is kept, program counter (PC), stack and the stack pointer (SP), value of CPU registers, set of OS resources in use (list of open files etc.), and the current process execution state (new, ready, running etc.). Some state may be stored in registers, such as the program counter. 4.1.2 Process Execution States Processes go through various process states which determine how the process is handled by the operating system kernel. The specific implementations of these states vary in different operating systems, and the names of these states are not standardised, but the general high-level functionality is the same. When a process is first started/created, it is in new state. It needs to wait for the process scheduler (of the operating system) to set its status to "new" and load it into main memory from secondary storage device (such as a hard disk or a CD-ROM).
    [Show full text]
  • IBM Power Systems Virtualization Operation Management for SAP Applications
    Front cover IBM Power Systems Virtualization Operation Management for SAP Applications Dino Quintero Enrico Joedecke Katharina Probst Andreas Schauberer Redpaper IBM Redbooks IBM Power Systems Virtualization Operation Management for SAP Applications March 2020 REDP-5579-00 Note: Before using this information and the product it supports, read the information in “Notices” on page v. First Edition (March 2020) This edition applies to the following products: Red Hat Enterprise Linux 7.6 Red Hat Virtualization 4.2 SUSE Linux SLES 12 SP3 HMC V9 R1.920.0 Novalink 1.0.0.10 ipmitool V1.8.18 © Copyright International Business Machines Corporation 2020. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents Notices . .v Trademarks . vi Preface . vii Authors. vii Now you can become a published author, too! . viii Comments welcome. viii Stay connected to IBM Redbooks . ix Chapter 1. Introduction. 1 1.1 Preface . 2 Chapter 2. Server virtualization . 3 2.1 Introduction . 4 2.2 Server and hypervisor options . 4 2.2.1 Power Systems models that support PowerVM versus KVM . 4 2.2.2 Overview of POWER8 and POWER9 processor-based hardware models. 4 2.2.3 Comparison of PowerVM and KVM / RHV . 7 2.3 Hypervisors . 8 2.3.1 Introducing IBM PowerVM . 8 2.3.2 Kernel-based virtual machine introduction . 15 2.3.3 Resource overcommitment . 16 2.3.4 Red Hat Virtualization . 17 Chapter 3. IBM PowerVM management and operations . 19 3.1 Shared processor logical partitions . 20 3.1.1 Configuring a shared processor LPAR .
    [Show full text]
  • Lecture 6: September 20 6.1 Threads
    CMPSCI 377 Operating Systems Fall 2012 Lecture 6: September 20 Lecturer: Prashant Shenoy TA: Sean Barker & Demetre Lavigne 6.1 Threads A thread is a sequential execution stream within a process. This means that a single process may be broken up into multiple threads. Each thread has its own Program Counter, registers, and stack, but they all share the same address space within the process. The primary benefit of such an approach is that a process can be split up into many threads of control, allowing for concurrency since some parts of the process to make progress while others are busy. Sharing an address space within a process allows for simpler coordination than message passing or shared memory. Threads can also be used to modularize a process { a process like a web browser may create one thread for each browsing tab, or create threads to run external plugins. 6.1.1 Processes vs threads One might argue that in general processes are more flexible than threads. For example, processes are controlled independently by the OS, meaning that if one crashes it will not affect other processes. However, processes require explicit communication using either message passing or shared memory which may add overhead since it requires support from the OS kernel. Using threads within a process allows them all to share the same address space, simplifying communication between threads. However, threads have their own problems: because they communicate through shared memory they must run on same machine and care must be taken to create thread-safe code that functions correctly despite multiple threads acting on the same set of shared data.
    [Show full text]
  • I.T.S.O. Powerpc an Inside View
    SG24-4299-00 PowerPC An Inside View IBM SG24-4299-00 PowerPC An Inside View Take Note! Before using this information and the product it supports, be sure to read the general information under “Special Notices” on page xiii. First Edition (September 1995) This edition applies to the IBM PC PowerPC hardware and software products currently announced at the date of publication. Order publications through your IBM representative or the IBM branch office serving your locality. Publications are not stocked at the address given below. An ITSO Technical Bulletin Evaluation Form for reader′s feedback appears facing Chapter 1. If the form has been removed, comments may be addressed to: IBM Corporation, International Technical Support Organization Dept. JLPC Building 014 Internal Zip 5220 1000 NW 51st Street Boca Raton, Florida 33431-1328 When you send information to IBM, you grant IBM a non-exclusive right to use or distribute the information in any way it believes appropriate without incurring any obligation to you. Copyright International Business Machines Corporation 1995. All rights reserved. Note to U.S. Government Users — Documentation related to restricted rights — Use, duplication or disclosure is subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp. Abstract This document provides technical details on the PowerPC technology. It focuses on the features and advantages of the PowerPC Architecture and includes an historical overview of the development of the reduced instruction set computer (RISC) technology. It also describes in detail the IBM Power Series product family based on PowerPC technology, including IBM Personal Computer Power Series 830 and 850 and IBM ThinkPad Power Series 820 and 850.
    [Show full text]