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

>> Also bear in mind the plan to avoid the grant mapping at all in the
>> direct-to-wire transmit case. This also will rely on a #PF (or some other
>> fault, potentially) if the guest tries to access that pseudophysical page of
>> memory. If we can work out a way to make this work on ia64 then the
>> delayed-copy implementation problems are solved too.
> That's to avoid the TLB flush costs, right?
> On ia64 (or anything other than x86-32 for that matter) you have
> enough virtual address bits to map the entire physical memory
> into dom0 (or the driver domain) so that could also be used to
> avoid TLB flushes.

Once we have IOMMU support we want to completely close off driver domain
access to arbitrary memory (which they currently have via DMA). Giving a
mapping of all physical memory would be a step in quite the opposite

 -- Keir

Xen-devel mailing list

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