Hi,<br><br>Is there any such mechanism to allocate pages, and map in the process virtual space, where we need it?<br><br>Such a mechanism would prove useful, in ballooning, where a page ballooned by a guest can be freed by launcher. When this page is required to be deflated, it can be allocated at the same address in the virtual space of the launcher, so as to be able to use the simple address translation, that lguest is currently using.<br>
<br>It could be much better, if there was a mechanism, to free a page, but still keep its mapping in the process virtual space, and be able to map pages to the same address later.<br><br>I have managed to balloon, by changing the address translation scheme, but this adds quite an overhead. <br>
<br>I free pages in a chunk of size which is a power of 2. These addresses are kept in increasing order in a link list, and the pages are freed. When a translation is required, number of chunks before the required address are counted, in this linklist, and accordingly difference is accounted in the virtual address of the launcher.<br>
<br>Another list is kept for deflated pages. These deflated pages are allocated at a new address in launcher virtual memory. These launcher virtual addresses are stored alongwith the guest pfn they should map to in the deflate_list. When a page from deflated space is referred, the particular chunk that the page belong to is located in the deflated list, and address is translated to the new address it is mapped in.<br>
<br>I am not being able to come up with a better solution. Please suggest some better solutions for the same. <br><br>Regards,<br><br>---<br><br>Gaurav Kukreja (India)<br>+91 997 030 1257<br><br>