Isaac Waldron wrote:
>
> How close is plex to being able to run a guest OS in pageable memory? I
> don't expect that this is a huge priority, but the FreeBSD port may require
> plex to be able to do this (sorry!). Also, does the guest memory have to be
> *physically* contiguous, or is *virtually* contiguous memory (as in,
> relative to the kernel module's address space) sufficient?
>
> I've been working on a kernel module for FreeBSD for the last few days, and
> physically contiguous memory is pretty hard to come by, especially after the
> system has been running for a while. The chance of getting even 1 or 2 Mb,
> let alone the 8-32 Mb that a guest OS would need, is next to nil for a
> system that has been running for any length of time.
>
> I can't even have the module load at boot time and sit around idle, because
> the memory is allocated on demand, and I wouldn't want to tie up potentially
> half or more of a system's RAM just sitting there, waiting for a plex
> session request for memory.
Memory only needs to be contiguous in _linear_ address space
(*virtually* as you put it above). We grope the host's page
tables to find the _physical_ addresses of these pages, and
then map them into a small linear range in the monitor. There
is no need for physical continuity at this time.
So, this shouldn't be a problem at all in FreeBSD.
Now, as far as using memory which is locked down. For now,
we don't allow paging any of the allocated pages. This will
change. We assume that all the pages are locked down by default
by the host OS, except those that are involved with a shared
memory map to the user space program. We had to tell Linux
to lock those down. Something about Linux assuming shared
pages can be paged.
-Kevin
