Shaohua Li wrote:
Make KVM guest pages be allocated dynamically and able to be swaped out.
One issue: all inodes returned from anon_inode_getfd are shared,
if one module changes field of the inode, other moduels might break.
Should we introduce a new API to not share inode?
Signed-off-by: Shaohua Li <[EMAIL PROTECTED]>
---
+static int kvm_set_page_dirty(struct page *page)
+{
+ if (!PageDirty(page))
+ SetPageDirty(page);
+ return 0;
+}
+
+static int kvm_writepage(struct page *page, struct writeback_control *wbc)
+{
+ struct address_space *mapping = page->mapping;
+ struct kvm *kvm = address_space_to_kvm(mapping);
+ int ret = 0;
+
+ /*
+ * gfn_to_page is called with kvm->lock hold, which might invoke page
+ * reclaim. So the .writepage should check if we already hold the lock
+ * to avoid deadlock.
+ */
+ if (!mutex_trylock(&kvm->lock)) {
+ set_page_dirty(page);
+ return AOP_WRITEPAGE_ACTIVATE;
+ }
+
+ /*
+ * We just zap vcpu 0's page table. For a SMP guest, we should zap all
+ * vcpus'. It's better shadow page table is per-vm.
+ */
+ if (PagePrivate(page))
+ kvm_mmu_zap_pagetbl(&kvm->vcpus[0], page->index);
+
+ ret = kvm_move_to_swap(page);
+ if (ret) {
+ set_page_dirty(page);
+ goto out;
+ }
+ unlock_page(page);
+out:
+ mutex_unlock(&kvm->lock);
+
+ return ret;
+}
+
Perhaps we can use this as a base for userspace-allocated memory. We
still have a kvm inode and address_space; but instead of calling
kvm_move_to_swap(), we use the memory slot and virtual address offset to
locate the underlying address_space and call that ->writepage().
So:
kvm_writepage() removes any shadow page table references
the underlying ->writepage() does the work of paging to the underlying
store
We need to figure out how to avoid the underlying ->writepage() from not
within the context of kvm_writepage(). Maybe have a page flag
signifying layered address spaces?
[it probably violates fifteen different mm assumptions; I need to study
that code]
An alternative would be to have kvm set a page flag signifying it has
references to the page when it installs it in a shadow pte. The mm
would notice the flag and call kvm to clear it below proceeding with
normal ->writepage().
--
error compiling committee.c: too many arguments to function
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
