Laurent Vivier wrote: > Avi Kivity wrote: > >> Michael Riepe wrote: >> >>> Hi! >>> >>> This is just a (probably silly) idea I had the other day. Currently, the >>> guest's memory is allocated inside the kernel and exported to userspace >>> via mmap(). But wouldn't it also be possible to create a file in >>> userspace and pass its descriptor to kvm? If we also pass file offset >>> and length parameters for each memslot, all segments can (but need not) >>> reside in the same file. There would be a persistent snapshot of the >>> VM's physical memory, and it would enable the VM to page out the guest's >>> pages. One could also do strange things like mapping a portion of the >>> file several times, e.g. to emulate an architecture with incomplete >>> address decoding. Applications that absolutely want to use anonymous >>> memory could pass -1 as the fd, as they do with mmap(MAP_ANONYMOUS). >>> >>> >> Arnd suggested this way back when kvm was first posted on lkml, and I >> agree that this is a very useful mechanism. You get on-demand loading, >> swap, hugetlbfs, and maybe other nifty stuff. I think I know how to do >> this for the current mmu, but I'm worried that it will have a >> performance impact with the nested page tables mmu. >> >> > > Perhaps you could use code from kqemu ? > >
The non-npt case is not so difficult, it is the npt case which I'm concerned about and that doesn't have a parallel in kqemu. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ kvm-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kvm-devel
