The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.
"Dave" <g8...@yahoo.com> writes: > Well "VM" or "CP" is very different. As the XA/ESA/z machine can't be > virtualized easily in software, I assume because of the need to make > AMODE switchs efficient, CP now relies on the SIE instruction to > provide virtual machines. I gather this uses the same "hardware" that > LPARs use. I guess you might consider this a "superset" of the VM > Assists that were available on S/370... XA wasn't as easily virtualized as 360 & 370 was ... and therefor the SIE instruction. SIE predates PR/SM and LPARs ... in that sense PR/SM and LPARs were leveraging the pre-existing infrastructure for microcode assists and SIE (and for some time, some of the assist microcode was mutually exclusive, either for VM use or LPAR use ... but not both). In the 360/370 scenario ... LPSW and interrupts loaded new PSW ... which simultaneously switched address space and privilege/problem mode in single operation (in MVS, a copy of the kernel appears in every address space ... where in cp/vm, the kernel and the guest address spaces are totally distinct). SIE was able to change address spaces and privilege/problem mode in single operation, as well as set a flag for privilege instructions ... basically "assist mode" that indicates privilege instruction is executed according to virtual machine rules (as opposed to real machine rules, basically each assisted privilege instruction has modified microcode). To simulataneously use the assists for LPARs and virtual machines ... effectively needed each privilege instruction microcode to be further modified to recognize 1) real machine, no LPAR, no virtual machine, 2) LPAR, no virtual machine, 3) virtual machine, no LPAR, 4) both LPAR and virtual machine. From a microcode standpoint, LPAR+VM is similar to virtualizing SIE (i.e. running a guest VM system under a VM virtual machine). SIE had additional performance issues on 3081 ... starting out just purely being internal tool supporting mvx/xa development ... originally never intended for shipping to customers (or production use). ... recent references to 3081 SIE microcode was "paged" (i.e. 3081 service processing paging SIE microcode from 3310 FBA ... representing something of performance issue): http://www.garlic.com/~lynn/2010e.html#34 Need tool to zap core http://www.garlic.com/~lynn/2010e.html#44 Need tool to zap core http://www.garlic.com/~lynn/2010e.html#46 Impact of solid-state drives the other is the emulated implementations ... like Hercules ... implemented on Intel platform; this could be considered analogous to the entry & mid-range mainframe implementations that had been done in vertical microcode. There was a separate performance issue going from virtual MVT guests to virtual SVS/MVS guests ... since VM started out simulating the TLB (hardware look aside buffer implementing virtual memory) with shadow page tables. The management of the entries in the shadow page tables with software was enormously slower than the hardware overhead involved in managing TLB entries. There could also be pathelogical page replacement algorithm behavior ... with MVS approximating a LRU page replacement and VM also approximating a LRU page replacement ... VM might be selecting the MVS guest page for removal from real storage ... moments before the MVS guest desides that it is the ideal next page to use (VM deciding that since it hasn't been used, it can be removed from real storage and MVS deciding that since it hasn't been used, it can be reassigned for some other use). -- 42yrs virtualization experience (since Jan68), online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
