2007/7/24, Avi Kivity <[email protected]>:
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
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
