how to port

Laurent Vivier mol-devel@lists.maconlinux.org
Wed, 29 Oct 2003 11:16:29 +0100


Hello Samuel,

do you think MOL can be used as a base of a virtual machine on Itanium-2 IA=
 64=20
linux ?
Can we use technical solutions found for powerPC and Openfirmware with=20
Itanium-2 and EFI ?

Laurent

Le Jeudi 2 Octobre 2003 12:43, Samuel Rydh a =E9crit :
> On Wed, Oct 01, 2003 at 07:21:02AM -0700, Andrew Musselman wrote:
> > I would like to contribute if I can; do you have any good how-to's on
> > what needs to be changed when porting from linux to OSX/Darwin?  I have
> > some Apple doc's, but do you have anything else?
>
> Well, the main problem is porting the kernel module.
>
> The rest is just ordinary porting (missing headers etc.). Actually,
> the rest of the code used to compiled once upon a time so there
> should be no big problems in this area (of course, OSX needs some
> speical support for networking etc).
>
> As for the kernel module, the amoung of code needed
> is quite small. However, it is technically complicated
> and insights into how a unix kernel handles memory mappings
> are required. A good understanding of the PowerPC MMU
> is also very important.
>
> More specifically, what needs to be done is:
>
> i) Fixing the 'mol userspace' <-> kernel module (IOKit driver)
> interface. MOL uses an ioctl interface under linux. OSX uses
> a more complicated model based upon mach ports. A test selector
> has already been implemented but it needs to be extended to all
> ioctls.
>
> ii) MOL needs to own a range of virtual segment IDs (VSIDs).
> This require some sort of hack, possibly an on-the-fly
> kernel patch. To get started, one could examine the OSX algorithm
> for VSID allocation and just steal VSIDs from the end of the free
> range. Of course, OSX will crash when OSX and MOL uses
> the same VSIDs but that ought to take a day or two since
> the number of available VSIDs are immense. Obviously this
> would not be the final solution...
>
> iii) MOL does not wire MOL RAM pages. This means that MOL needs
> to be told whenever a RAM page (owned by the userspace
> process) is switched out in order to flush it from
> MOL owned VSIDs. Under linux, this is achieved through
> a hook of the flush_tlb_page(). Somethink similar
> could probably be done under OSX.
>
> iv) The flushing of PTEs from VSIDs needs locking (on SMP systems).
> The lock can only be taken from non-faulting memory (i.e. BAT mapped
> or with the MMU off).
>
> v) I'm not sure MOL and OSX can easily share the same PTE hash. Linux
> only uses it as a cache so PTE evicts are harmless. I believe OSX
> uses a more complicated model though. It might be simplest to use
> a private PTE table for MOL. It costs some wired continuous memory
> though...
>
> vi) The OSX kernel module (IOKit driver) can't easily access the
> RAM of the MOL userspace process. Under linux, this space is mapped
> into the kernel. This is not the case under OSX however. The MOL
> kernel module primarily accesses the virtual RAM in order
> to do emulated PTE lookups. (This is not a big problem; either
> get_user() type of calls could be used to copy the relevant PTEGs from
> userspace or the lookup could be performed in the low-level asm
> code rather than from the C-code).
>
> vii) The transition between the low-level asm part (where
> MOL completely owns the CPU) and the C-level kernel module
> code needs some work. Under linunx, a trampoline (or a faked
> syscall) is used. Under OSX, we might have to do a full userspace
> return from the low-level asm part and then invoke the C-level
> stuff through the mach port interface.
>
> viii) MOL needs to be able to page in userspace (RAM) pages.
> Under linux, MOL essentially contains a copy of the kernel
> page-in code. It is possible to do this completely without
> relying on kernel internals though. Basically one would
> have to access the RAM page in question from userspace (causing
> the page in) and then lookup the physical page through a PTE
> walk (or by calling a suitable kernel function). This would
> be more expensive than the linux solution but the overhead
> of page-ins are more or less neglible under MOL/linux so
> this extra overhead might not matter that much.
>
> Cheers,
>
> /Samuel
>
> _______________________________________________
> mol-devel mailing list
> mol-devel@lists.maconlinux.org
> http://lists.maconlinux.org/mailman/listinfo/mol-devel

=2D-=20
"La R=E9publique ne reconna=EEt, ne salarie ni ne subventionne aucun culte."
Article 2, loi du 9 d=E9cembre 1905