Christoph Lameter wrote: > On Tue, 15 Jan 2008, Avi Kivity wrote: > > >>> But each guest has its own page structs. They cannot share page structs. >>> Concurrent access of two independent kernel instances for synchronization >>> and status maintenance to a single page struct? >>> >>> >> There's a host page struct (that the guest know nothing about and cannot >> touch), and optionally a guest page struct for each guest (that the host and >> the other guest know nothing about). >> > > Ok so if two linux guests want to share memory three page structs are > involved: > > 1. Host page struct > 2. Guest #1 page struct > 3. Guest #2 page struct > > I can understand that 1 and 2 point to the same physical page. Even all > three could point to the same page if the page is readonly. > > However, lets say that Guest #1 allocates some anonymous memory and wants > to share it with Guest #2. In that case something like PFNMAP is likely > going to be used? Or are you remapping the physical page so that #1 and #2 > share it? In that case two page struct describe state of the same physical > page and we have no effective synchronization for writeback etc. > >
Like I said, out of the box Linux doesn't support using memory that is shared with other instances as main memory. One usage (by the s390 folk) was to put a read-only filesystem with execute-in-place support on this memory, and so reduce the memory usage of guests. >> The host page struct may disappear if the host decides to swap the page into >> its backing store and free the page. The guest page structs (if any) would >> remain. >> > > Page structs never disappear. The pte's may disappear and the page may be > unmapped from an address space of a process but the page struct stays. > Page struct can only disappear if memory hotplug is activated and memory > is taken out of the system. > Yes, that was poorly phrased. The page and its page struct may be reallocated for other purposes. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
