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>, Keir Fraser <Keir.Fraser@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] RFC: [0/2] Remove netloop by lazy copying in netback
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Thu, 22 Mar 2007 15:40:59 +0000
Cc: Xen Development Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <keir@xxxxxxxxxxxxx>
Delivery-date: Thu, 22 Mar 2007 08:40:37 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20070322105055.GA8918@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: AcdsmHzru2gOHdiLEduHbwAX8io7RQ==
Thread-topic: [Xen-devel] RFC: [0/2] Remove netloop by lazy copying in netback
User-agent: Microsoft-Entourage/
> On Tue, Mar 20, 2007 at 03:18:54AM -0700, Keir Fraser wrote:
>> That's quite a valid concern, but I think that the required addition to the
>> #PF handler (certainly for i386 and x86/64) will be clean and small, and it
>> will not affect #PF critical-path latencies. I'd be fairly optimistic about
>> it getting accepted upstream, perhaps modulo concerns over whether we'd need
>> to implement it for *every* architecture.
> OK I've given it a spin and it's pretty straight-forward for
> x86 as you said.  However, we'll need a bit more work for
> ia64/ppc either on the kernel side or on the hypervisor side
> as there is no way currently to swap entries in the P2M table.
> Any better suggestions for dealing with those two?

I didn't look super closely at the precise set of steps on x86 either. Do
you take a normal page of memory in the guest's address space and simply
give it an extra mapping in the netback area? Or do you take a page with no
pseudophysical address and assign it a pseudophysical address corresponding
to its place in the netback area?

I certainly assumed (a), and I think that would work fine on ia64 and
powerpc, as the page would already have a pseudophysical address?

Maybe I'm misunderstanding something... :-)

 -- Keir

Xen-devel mailing list

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