AW: Re: Does >4K PGFIX make sure the frames are contiguous? (was: diagnose 8 / interesting dilemma)
> Data chaining was the original solution to this problem. It was probably a bad idea to mention I/O in my post (I know about data chainging and IDAW). I was thinking more about the possible need to have more than 4k of contiguous real storage. Like Tony mentioned, new interfaces such as SMC-R/D might need this. There might be internal interfaces for this, right. It just triggered my curiosity. But the net seems to be, my assumption is wrong. If an area >4k is PGFIXed, then I need to find the real address of every page and cannot assume the real storage is contiguous. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Does >4K PGFIX make sure the frames are contiguous? (was: diagnose 8 / interesting dilemma)
Data chaining was the original solution to this problem. On Wed, 19 Oct 2016 00:27:56 +0200 Peter Hunkelerwrote: :> :>Below discussion triggered a question I could not answer by RTFM. I had never thought about this before in this detail, but now that I do, I wonder if the following is correct. :> :>Program allocates >4k of virtual storage. The real frames backing it may or may not be contiguous. The program wants to use this area with some interface (I/O, etc) that will use real addresses when accessing the storage, so it does a PGFIX. PGFIX would move the possibly non-contiguous frames guaranteeing the area is backed by contiguous frames. After all, the interface using real addresses would expect the the frames to be contiguous. :> :> :>Am I wrong? I would have expected to find this documented with the PGFIX or PGSER FIX macros, but did not find it. -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Does >4K PGFIX make sure the frames are contiguous? (was: diagnose 8 / interesting dilemma)
On Tue, 18 Oct 2016 19:34:10 -0400, Tony Harminc wrote: > >If you want to do I/O to your real storage, that is what IDAWs are >for. Perhaps there are undocumented (or at least not publicly >documented) IBM facilities -- I'm guessing things like crypto, >compression, newer non traditional I/O -- that take real addresses and >need more than a page at a time, but I don't know of any. In this >sense, VM's Diagnose interface is an outlier. > I understand that for some time IEBCOPY could not deal with VIO because IEBCOPY dealt only with real addresses and VIO dealt only with virtual addresses. I was slightly surprised when the conflict was resolved by modifying VIO rather than IEBCOPY. I suppose this required something like an inverse LRA. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Does >4K PGFIX make sure the frames are contiguous? (was: diagnose 8 / interesting dilemma)
On 18 October 2016 at 18:27, Peter Hunkelerwrote: > Below discussion triggered a question I could not answer by RTFM. I had never > thought about this before in this detail, > but now that I do, I wonder if the following is correct. > > Program allocates >4k of virtual storage. The real frames backing it may or > may not be contiguous. The program wants to > use this area with some interface (I/O, etc) that will use real addresses > when accessing the storage, so it does a PGFIX. > PGFIX would move the possibly non-contiguous frames guaranteeing the area is > backed by contiguous frames. After all, > the interface using real addresses would expect the the frames to be > contiguous. > > Am I wrong? I would have expected to find this documented with the PGFIX or > PGSER FIX macros, but did not find it. I do not believe there is such a service documented. As Jim Mulder pointed out, there are 1M pages available above the bar, but that's relatively new stuff. And there are unexposed RSM services to manage pairs of frames (and quads, I think he said). If you want to do I/O to your real storage, that is what IDAWs are for. Perhaps there are undocumented (or at least not publicly documented) IBM facilities -- I'm guessing things like crypto, compression, newer non traditional I/O -- that take real addresses and need more than a page at a time, but I don't know of any. In this sense, VM's Diagnose interface is an outlier. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Does >4K PGFIX make sure the frames are contiguous? (was: diagnose 8 / interesting dilemma)
Below discussion triggered a question I could not answer by RTFM. I had never thought about this before in this detail, but now that I do, I wonder if the following is correct. Program allocates >4k of virtual storage. The real frames backing it may or may not be contiguous. The program wants to use this area with some interface (I/O, etc) that will use real addresses when accessing the storage, so it does a PGFIX. PGFIX would move the possibly non-contiguous frames guaranteeing the area is backed by contiguous frames. After all, the interface using real addresses would expect the the frames to be contiguous. Am I wrong? I would have expected to find this documented with the PGFIX or PGSER FIX macros, but did not find it. -- Peter Hunkeler On 10/17/2016 08:23 AM, Paul Schuster wrote: > I am issuing DIAGNOSE 8 on my z/os image under VM (z/vm) to do a QUERY > VIRTUAL DASD. It works—up to a certain point: > > The QUERY VIRTUAL DASD command returns (for me) 38617 (decimal) bytes, > according to the CC=0 after the DIAGNOSE 8 command. My buffer is large > enough to accommodate this. I have tried several different sub-pools of > storage. I PGSER FIX the buffer pages. I do a SYSEVENT DONTSWAP. I do a > LRA of the virtual address of the start of the buffer. The DIAGNOSE > completes CC=0. But, in my buffer, I am only seeing the first page (4095) > bytes of the output. > > My question: I don’t see any documented restriction in the VM manuals that > limits the DIAGNOSE 8 output buffer to 4K (rather the limitation is the > architecture limit depending on your amode.) The z/vm manuals say the buffer > can cross page boundaries. So is there a way to force the real storage > addresses of the page-fixed pages to be consecutive? According to the > diagnose 8 doc., the buffer needs to be in guest-real storage, hence the LRA. > And it is working for the first 4k page. > > Thank you for any insight you can provide. As you already guessed, the memory you get is virtual, so the pages are not consecutive. The LRA will give you the address of the first page, but the 2nd, 3rd and so on will be somewhere else. Please note that your code will even cause random memory overwrites in your z/OS as the diag8 will write to the real address of your LRA, the real address of your LRA+4096 and so on. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN