Re: [RFC/PATCH LGUEST X86_64 01/13] HV VM Fix map area for HV.

[Rusty Russell <rusty@rustcorp.com.au>]

On Thu, 2007-03-08 at 12:38 -0500, Steven Rostedt wrote:
> One solution is just to do a single area for boot up, and then
> use the vmalloc to map. But this gets quite complex, since we need to
> force the guest to map a given area, after the fact, hoping that
> it didn't map it someplace else before we get to the code to map it.
> This can be done, but doing it this way is (for now) much easier.

Well, this way was more code, but you're right about the theoretical
failure mode of the vmalloc method.

>     Host            Guest1          Guest2
>  +-----------+   +-----------+  +-----------+
>  |           |   |           |  |           |
>  +-----------+   +-----------+  +-----------+
>  | HV FIXMAP |   | HV FIXMAP |  | HV FIXMAP |
>  |   TEXT    |   |   TEXT    |  |   TEXT    |
>  +-----------+   +-----------+  +-----------+
>  | GUEST 1   |   | GUEST 1   |  | UNMAPPED  |
>  |SHARED DATA|   |SHARED DATA|  |           |
>  +-----------+   +-----------+  +-----------+
>  | GUEST 2   |   | UNMAPPED  |  | GUEST 2   |
>  |SHARED DATA|   |           |  |SHARED DATA|
>  +-----------+   |           |  +-----------+
>  |           |   |           |  |           |

I think it's better to do this per-cpu, as in the recently posted 32-but
patches.  You have to copy in when changing guests, but you can support
an infinite number of guests with (HV TEXTSIZE + NR_CPUS*2) pages.

Damn, I forgot to cc you on that patch.  Sorry, I suck 8(

They went to lkml as:
[PATCH 7/9] lguest: use read-only pages rather than segments to protect high-mapped switcher
[PATCH 8/9] lguest: Optimize away copy in and out of per-cpu guest pages

Cheers!
Rusty.