Messages in this thread | | | Date | Wed, 25 Jul 2007 19:55:21 +0800 | From | "Shaohua Li" <> | Subject | Re: [kvm-devel] [RFC 7/8]KVM: swap out guest pages |
| |
2007/7/24, Avi Kivity <avi@qumranet.com>: > 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 <shaohua.li@intel.com> > > --- > > > > +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 So write to a file, right? Yes, it can avoid use move to swap, and should be feasible.
> 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(). This page_private flag's job, I think.
Thanks, Shaohua - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |