Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!sun-barr!oliveb!amiga!cbmvax!jesup From: jesup@cbmvax.UUCP (Randell Jesup) Newsgroups: comp.sys.amiga.tech Subject: Re: (Fairly) Complete Amiga VM design (was Re: MEMF_PHYSICAL?) Message-ID: <7063@cbmvax.UUCP> Date: 7 Jun 89 20:18:49 GMT References: <8906010252.AA11810@jade.berkeley.edu> <367@xdos.UUCP> <7039@cbmvax.UUCP> <370@xdos.UUCP> Reply-To: jesup@cbmvax.UUCP (Randell Jesup) Organization: Commodore Technology, West Chester, PA Lines: 110 In article <370@xdos.UUCP> doug@xdos.UUCP (Doug Merritt) writes: >In article <7039@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: >> Wrong. The whole point of VM is that the addresses can be mapped. >>A single address space merely means that all processes share a single >>mapping of virtual->physical. Your hypothetical situation only arises >>if processes can have different mappings. > >True. I was simply trying to point out that this issue means you can't >have a *pure* single address space model, since if each task *does* have >pages that have the same address, you either have to swap (if they're >the same *physical* address, as required by the single address space >model), or else you have to given them overlapping *virtual* pages, >in which case you don't have a pure single address space model. Instead >you have some pages in the same address space, and others outside of it. Sorry, you're assuming that "each task *does* have pages that have the same physical address". I'm saying that in the single address space model, ALL tasks have EXACTLY the same Virtual->physical address translations. This gives a SINGLE 4 gig address space for everything in the system. You're talking about a multiple address space model with some sharing between tasks; a different thing than a single address space. Moving on to protection issues,... >What, precisely, *is* needed? This: > - Message passing pages must be in a universally shared portion > of the address space because we don't know who will need to > see the message and write to it. This implies that allocated > memory must be in the global space. For protection, messages must be writable by anyone, and often (but not always) the data pointed to must be writable. The data must be readable, though. > - Allocated memory should be tracked and freed. This can be > accomplished to a large extent by initially giving each task > private pages for allocation. When another task accesses one > of those pages (in the global space but initially r/w only > to the initial owner), AmigaDOS notes that page ownership is > now shared by both programs and turns on r/w access for the > second task. If that never happens (the normal case; consider > big chunks of allocation like custom screens allocated by > DPaint or games), then the memory is freed when the program > exits. Already that's a big win. Won't work: you have race conditions. Another task may have been passed a pointer to some memory by the first task. The first task then exits, the memory is freed, and THEN the second task accesses the memory passed by the first (which has now been freed). You also have problem with memory blocks that overlap page boundaries. > - Some programs use statically allocated messages. This implies > that they must be forced to be in the global space. This is > a pathological case, but could be dealt with via header > information in the executable chunk. This info would have to > be set by a sort of patch utility. The patch utility should > be run automatically (after getting user permission from > a requester) when the system detects a write fault. Thus > the program would fail the first time it was run, but would > get mapped into the global space on later runs. With proper > requester phraseology, this would work even with novices. They also use staticly allocated ports, etc, etc. In can get tricky deciding what is a random pointer access and what is an attempt to get to a static structure. Not to say it isn't feasible to do in the way you specify, just that it's harder than you say. > - What about demand paging? By default, CHIP memory should not > be paged because hardware may access it without prior warning, > and we can't put hardware on hold while we process an interrupt. Correct, chip memory cannot be paged safely. > FAST memory is not subject to custom chip i/o, and therefore > can be paged. Most reasonable forbid/permit accesses are to > system memory, so that's not a problem. Others may surround > message massaging, and it's ok to page these globally shared > pages even inside forbid(). Forbid (and worse, Disable) are real show-stoppers. There's no way to know WHAT was left inconsistant when the page fault occurs; and you need to allow other tasks to run, access resources, etc in order to handle the page fault. The solution here is to eliminate any need by application for Forbid/Disable, and if you do need them you must be 100% certain that all code and data pages that will be accessed are locked into memory first. >Given all the above to handle existing software, the discussion about >introducing new AmigaDOS features (MEM_PHYSICAL/VIRTUAL/SHARED/PRIVATE/VOYEUR/ >etc) then allows better control for newly written software. Semaphores >become very important, too. Yes, semaphores are VERY important to being able to implement any sort of transparent VM (as opposed to VM only for allocations that specify it). >> Virtual machines are an amusing idea, and can be useful for debugging >>OS's (slowly) on fairly generic machines, but the killer is hardware access. > >Yes, but even slow virtual machines can be useful. Look at all the people >willing to use MS-DOS software simulators, for instance. The hardware access >issue is very real, but that's the way it goes...you get either danger >or slowness (ideally a choice). The Amiga custom hardware is a wee bit more complex than an generic PC clone. :-) This makes a virtual machine not just slower, but it would be absolutely GLACIAL. :-( -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup