This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] RFC: [0/2] Remove netloop by lazy copying in netback

To: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] RFC: [0/2] Remove netloop by lazy copying in netback
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Tue, 27 Mar 2007 09:31:15 +0100
Cc: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>, Xen Development Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 27 Mar 2007 01:29:23 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20070327081352.GA24634@xxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcdwSkiGhx8jxtw9EduuUwAWy6hiGQ==
Thread-topic: [Xen-devel] RFC: [0/2] Remove netloop by lazy copying in netback
User-agent: Microsoft-Entourage/
On 27/3/07 09:13, "Herbert Xu" <herbert@xxxxxxxxxxxxxxxxxxx> wrote:

> I was actually thinking of Jose's scheme where it's mapped in on
> demand.  So you would still do your grant table map operation,
> but instead of mapping it in as we do now it would simply notify
> the hypervisor of the intention to map this page, and the hypervisor
> can then map it in when it actually faults.

That's not quite how Jose's patch works. The lazy mapping is done by the
guest in his patch.

If we're not going to go as far as supporting guest-visible 'p2m faults'
then I think overall your original patch is probably the best approach so
far. If I view the new hypercall as a special case of the existing unmap
(which is an unmap-to-zero-pte special case) then it's not so bad. At least
there should be very little new code in the hypervisor needed to implement
it. We have a little while longer to think about this since the patches
aren't for 3.0.5.

 -- Keir

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>