Re: [kvm-devel] [PATCH] export notifier #1
From: Avi Kivity
Date: Thu Jan 24 2008 - 07:34:51 EST
Andrea Arcangeli wrote:
On Thu, Jan 24, 2008 at 07:56:43AM +0200, Avi Kivity wrote:
What I need is a list of (mm, va) that map the page. kvm doesn't have
access to that, export notifiers do. It seems reasonable that export
notifier do that rmap walk since they are part of core mm, not kvm.
Yes. Like said in earlier email we could ignore the slowdown and
duplicate the mm/rmap.c code inside kvm, but that looks a bad layering
violation and it's unnecessary, dirty and suboptimal IMHO.
Historical note: old kvm versions (like the what will eventually ship in
2.6.24) have a page-based rmap (hooking the rmap list off
page->private). We changed that to an mm based rmap since page->private
is not available when kvm maps general userspace memory.
Alternatively, kvm can change its internal rmap structure to be page based
instead of (mm, hva) based. The problem here is to size this thing, as we
don't know in advance (when the kvm module is loaded) whether 0% or 100%
(or some value in between) of system memory will be used for kvm.
Another issue is that for things like the page sharing driver, it's
more convenient to be able to know exactly which "sptes" belongs to a
certain userland mapping, and only that userland mapping (not all
others mappings of the physical page). So if the rmap becomes page
based, it'd be nice to still be able to find the "mm" associated with
that certain spte pointer to skip all sptes in the other "mm" during
the invalidate.
You also need the mm (or rather, the kvm structure, but they have a 1:1
relationship) to be able to lock and maintain the shadow structures
properly.
--
Any sufficiently difficult bug is indistinguishable from a feature.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/