Re: [Freemint-discuss] Virtual Memory Implementation Ideas

[Adam K. <ada...@gm...>]

pon., 8 maj 2023 o 13:43 Mark Duckworth via Freemint-discuss <
fre...@li...> napisał(a):

>
> On 5/8/23 1:12 AM, Thorsten Otto wrote:
> > On Montag, 8. Mai 2023 04:55:46 CEST Mark Duckworth via Freemint-discuss
> > wrote:
> >> You will
> >> be able to specify your virtual address space but I will choose
> >> 0xbdffffff-0xfdffffff as an example.
> > Using an address space that is negative will not be the best idea.
> Malloc()
> > for example will then return such addresses, and that might be
> interpreted as
> > failure.
>
>
Malloc returns 0 on unsuccessful allocation, any other value is pointer to
allocated memory, both in case of kernel and libc. Libc malloc() may also
ser errno, so there is no risk here.


> I was attempting to specify a range.  0xbdffffff to 0xfdffffff for a
> total virtual address space size of 0x40000000, not a negative value.
>
> >> Now the question is, what is my idea missing?  Is this viable?
> > I think you forgot the most important thing: virtual memory means that
> > addresses of user programs and the kernel are no longer the same. That
> means
> > that all such addresses cannot longer be directly accessed by the
> kernel, and
> > you have to use special functions to copyin such parameters from
> user-space,
> > and copyout back to it. That might be doable in the GEMDOS interface,
> but i
> > think will be hard to do in the BIOS and XBIOS interfaces. It will also
> > disallow user programs to use Supexec and/or Super() in most cases. But
> the
> > most troublesome part is the AES, when it tries to access deeply nested
> > structures. It also applies to any GEM protocols used, since addresses
> of one
> > process are different from others. So basically i think, virtual memory
> cannot
> > be supported for GEM programs at all (or at least not without heavy
> > modifications).
> >
> The kernel would remain in the physical address space.  Those virtual
> addresses would transparently translate to the same physical address for
> all processes.  GEM programs would simply not get or use virtual memory
> to start, and possibly never.  And this is no great loss IMHO.
>
>
I think it could be fine to allow them to use virtual memory in TT-RAM
space, but it should be share between all GEM programs

I'd suggest (as before) splitting everything between 2 worlds
 - old world - no virtualization in ST-RAM, maybe in TT-RAM but shared
address space
 - new world - fol ELFs only, fully vitrtualized with some ability to
interact with old world (fixed shared mem window ST-RAM?) and probably
redesigned GEM api (to suit virtual environment)

As for GEMDOS, we could use trick used by other OSes (Linux, Windows) where
for each process, first 2GB is kernel space (and protected from process
access), and 2nd 2GB is process space (this should/could be configurable).
This simplifies transfering data between user/kernel space.

-- 
Semper Fidelis

Adam Klobukowski
ada...@gm...