> > This is great! Works really well. Very effective. > One thing that would make it more complete would be to > also support LOADPARM, which unlike PARM does have a HW equivalent. > I'm thinking maybe append "loadparm=whatever" to the parm line > iff a LOADPARM is supplied (by hardware IPL or by VM IPL). > The "loadparm=" token would then trigger ... whatever! > It's a very zSeries-centric option, but not unlike parm tricks > I've seen on other architectures. LOADPARM is only 8 bytes. > Well, I'd be happy to and have been attempting it since I posted the PARM patch, but I've never done interrupt processing and the SERVC instruction appears to require it. And, near as I can tell, is undocumented.
Here's what I had in mind... ZIPL normally stores information about the selected config in a file called bootmap. This would normally contains a list of blocks for the desired kernel, parmfile, (maybe) initrd, and, lastly, an "execute" entry that tells zipl to startup the kernel. I was going to modify ZIPL to store ALL the configurations found in "/etc/zipl.conf" and allow you to select the desired one using the LOADPARM (and HMC equiv.) when IPLing. To do this, I need to retrieve the LOADPARM using the SERVC instruction. Unfortunately, I've been unsuccessful at getting it to work. I usually get: HCPMCV1459E The virtual machine is placed in check-stop state due to a system malfunction with CPU 00. I'm fairly certain I have the registers and storage setup correctly. What I'm not at all certain about is whether the instruction works in "real" mode and what state the control registers and PSW need to be in. I've enabled external interrupts and have been partially successful there in that I can (as a test) generate and process 1005 events, but I never receive 2401 service signals. Any ideas or examples would be GREATLY appreciated. > > http://www.homerow.net/projects/zlinux/vmparms.htm > > I can't thank you enough for this! > I've been using it on a 2.4.19 kernel (31 bit) for several days. > That's good to hear. I never really tested the 31bit version and I thank you for trying it. BTW: An update to the patch will be posted soon to "correcct" an assumption the current one makes. Right now, it assumes that a hex zero will be in the high byte of register 0 at IPL time if no PARM parameter was specified. This may not be the case as Alan had mentioned before that the registers are "undefined" at IPL if the PARM keyword and parameter are not specified. While there doesn't seem to be a surefire way of determining if PARMs were specified (unless there's some DIAG that'll do it for me), I'll be putting in a requirement that the word LINE followed by a space be specified at the start of the parms. While not entirely foolproof, it should be a tad bit safer. It would be something like this: IPL 4000 PARM LINE root=/dev/dasda1 dasd=4000,5000,6000 ... Actually, it's up to whoever is applying the patch what, if any, the eyecatcher should be as it will be a "define" in the source. Leland
