On Sun, 29 Jan 2006 18:17:46 -0600 "Craddock, Chris" <[EMAIL PROTECTED]> wrote:
:>> > PT uses an ASN. You have no clue <<>> whether that address space :>> > is still valid, or even whether it is in memory. :>> Isn't that why "God" invented the CML lock? You must SSAR/SSAIR to the :>> space for which you want to obtain that lock and the space needs to be :>> non-swappable. Once the CML lock is held, the address space won't :>> disappear and you can access it any way you want. :>Technically no it isn't. A CML is just the local lock of an address :>space other than your HASN. The design intent of a CML is to allow a :>cross memory caller access to resources serialized by the local lock in :>an address space the caller legitimately has access to. Those would be :>PASN, SASN and HASN. The architecture assumes that the only way :>PASN<>HASN or SASN<>HASN is that you got that way via a space switch PC. :>If you got into cross memory mode via a PC like "God" intended, then :>both PASN and HASN are properly established and can't go away (or be :>swapped) in an untimely fashion. Otherwise all bets are off. :>Yes, you can SSA(I)R or PT(I) to any space you want if you have an AX :>that lets you do it - hence Binyamin's deep desire for a task level AX. :>The core of that desire rests on wanting to just reach out and touch :>another address space without being bothered by cumbersome details like :>establishment and maintenance of addressability. The hardware will :>cheerfully let you do it, but the cross memory services software :>architecture (wisely) doesn't allow it. The CML will allow the XMS software to handle it just fine. The CML will prevent the locked address space from being swapped out. Exactly what do you feel will "confuse" the OS? :>> I must be missing something. Why do you assume the "other" address :>space :>> he wants to access is not non-swappable? I re-read this entire thread :>> and Binyamin _never_ said he wanted to access a swappable address :>space :>> (though that might be the case). As I see it, this digression is at :>best :>> tangential to the core discussion at hand. The cross-memory access :>> considerations you've detailed are true and exist today even when AX=1 :>> for the entire address space. Right? :>They exist for all cases where you access an address space via anything :>other than the formally defined mechanisms. Hence the documented :>requirement that a PC service provider must be non-swappable. An XMS provider can still vanish during a call and the client A/S will end up with some most unusual exceptions. :>> Getting back to basics: What Binyamin has asked for is the ability to :>> have the AX for one TCB/RB in an address space be different than the :>AX :>> of another TCB/RB in the same address space. On the surface, that :>seems :>> like a reasonable "wish list" item to me. We've established that this :>> function doesn't exist given the current cross-memory architecture, :>> developed decades ago -- even before XA/370, but that doesn't :>invalidate :>> the merits of the idea. Does it? :>Yeah it does. What Binyamin is explicitly asking for is the ability to :>branch into another address space. There are intractable problems with :>that idea. The only reason we're talking about the AX is that he has :>found that he needs to set an AX value (temporarily at least) that will :>allow PT to the address space he wants to be in. Messing with the AX via :>CR4 was the crux of his original question. :>But to address your point, in a purely academic sense it may well make :>sense to allow a specify task to establish a cross-memory bind to some :>server space that legitimately provides space switching functions. But :>wait, oh darn, that is what an EAX is for on a stacking PC. So no I :>don't believe there is any legitimate usage case for altering the AX of :>a single task as a general service interface. Due to lack of imagination. If the only tool that you can imagine is a hammer, everything will look like a nail. As a side point, to merely look at another address space one need merely set up a public access ALET to it (which is an in-line operation - and, gee whiz there is a special keyword - CHKEAX=NO - will allow a supervisor state routine to do this even without AX authority). Obviously one must make sure that the target address space is not swappable. Unfortunately, that also has an exposure as anyone can now get over to the address space via the ALET. -- Binyamin Dissen <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
