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@xxxxxxxxxxxxx>
Date: Tue, 27 Mar 2007 10:58:46 +0100
Cc: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>, Xen Development Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 27 Mar 2007 02:57:56 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20070327092028.GA25077@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: AcdwVoJdwQEaSNxJEdu1BgAX8io7RQ==
Thread-topic: [Xen-devel] RFC: [0/2] Remove netloop by lazy copying in netback
User-agent: Microsoft-Entourage/
On 27/3/07 10:20, "Herbert Xu" <herbert@xxxxxxxxxxxxxxxxxxx> wrote:

>> That's not quite how Jose's patch works. The lazy mapping is done by the
>> guest in his patch.
> That would mean the breaking of large pages on ia64 or any other
> platform that uses them.  Is there any benefit for not doing it
> in the hypervisor?

Yet another bloody grant-table hypercall! Also there's the question of where
this lazy state gets squirrelled away until the demand mapping occurs.
Perhaps the p2m is usable in this case, since I expect we have plenty of
spare bits for a not-present entry... But anyway, we don't have the luxury
of a p2m to stick things in the x86 case.

>> 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.
> OK.  How do you want to proceed from here then?

I'll take a closer look at your original patch. Having viewed the
alternatives I don't hate it so much now. :-)

 -- Keir

Xen-devel mailing list

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