[Lguest] Sharing PTEs between host and lguest instance

[Earlence Fernandes]

But wouldn't mmapping some file to the end of guest memory effectively
increase the
size of physical memory that the guest sees?

I was thinking more along the following lines: Correct me if I'm wrong at
any stage

1. A process inside the guest appears as a process on the host. There is a
one to one correspondence.
2. The host lguest kernel module (page_tables.c) maintains page tables for
each guest process. This is the shadow table.
3. When a guest process faults, the guest kernel sets up a new PTE (if
legal) and then notifies the host kernel module.
4. The host kernel module receives this hypercall upon every new page
allocation for _any_ guest process and performs
the real allocation of the PTE in the shadow.

Assuming all of this were true, then wouldn't it suffice to modify the host
kernel module's handling of the shadow PTE setting
and set it to a page that belongs to some other non-virtualized host
process. Would this enable the sharing of a page between
a regular host process and a virtualized guest process running on the guest
kernel?

-Earlence



On Wed, Jan 29, 2014 at 1:36 AM, Rusty Russell <rusty at rustcorp.com.au>wrote:

> Earlence Fernandes <earlenceferns at gmail.com> writes:
> > I think what I'm saying is that how do I shared pages between a host
> > process and a guest process, since at the end, both of them are processes
> > on the host kernel.
>
> Yes, it can be done.
>
> We currently mmap the entire guest memory:
>
>                         guest_base = map_zeroed_pages(mem / getpagesize()
>                                                       + DEVICE_PAGES);
>                         guest_limit = mem;
>                         guest_max = mem + DEVICE_PAGES*getpagesize();
>
> You could mmap some other file too (eg. at the end) but make usre you
> increase guest_limit, as that is what the kernel uses to prevent the
> guest from accessing outside its allowed memory.
>
> Cheers,
> Rusty.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/lguest/attachments/20140129/b55215ad/attachment.html>