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. _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxx https://lists.osdl.org/mailman/listinfo/virtualization
