From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: [Xen-users] ARM: "xen_add_mach_to_phys_entry: cannot add ... already exists and panics" Date: Fri, 4 Jul 2014 17:36:36 +0100 Message-ID: <53B6D814.2030606@citrix.com> References: <1404295013.24733.8.camel@kazak.uk.xensource.com> <1404379885.14865.20.camel@kazak.uk.xensource.com> <53B6A37B.4020605@citrix.com> <53B6B8E5.8070201@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Stefano Stabellini Cc: xen-devel@lists.xensource.com, "Wei Liu (Intern)" , Ian Campbell , Julien Grall , Stefano Stabellini , Zoltan Kiss , xen-users@lists.xen.org, Denis Schneider List-Id: xen-devel@lists.xenproject.org On 04/07/14 15:31, Stefano Stabellini wrote: > On Fri, 4 Jul 2014, David Vrabel wrote: >> On 04/07/14 15:12, Stefano Stabellini wrote: >>> On Fri, 4 Jul 2014, David Vrabel wrote: >>>> On 03/07/14 18:47, Stefano Stabellini wrote: >>>>> >>>>> At the moment I would like a way to disable grant mappings and go back >>>>> to grant copies on demand. Maybe we could have a feature flag to change >>>>> the behaviour of the network backend? >>>> >>>> You must fix the ARM code to handle this properly. >>>> >>>> blkback also uses grant maps and depending on the frontend blkback may >>>> grant map the same machine frame multiple time. We have see frontends >>>> that send such requests. >>> >>> Indeed, it must be fixed properly. The workaround of disabling grant >>> mappings would be just to buy us some time to come up with the fix. >> >> It's an expensive workaround though. > > In terms of performances or in terms of code? > If it's the performances you are worried about, we could enable the > workaround just for arm and arm64. Expensive in terms of effort required to implement and maintain. >>>> I can't remember how the ARM code works. Where is the problematic m2p >>>> lookup? >>> >>> arch/arm/xen/p2m.c >>> >>> >>>> Perhaps this could be avoided for foreign frames? >>> >>> Unfortunately no. The whole point of p2m.c is to be able to translate >>> foreign frames for dma operations. >> >> This is a p2m lookup though, which is fine, yes? Where, specifically is >> a mfn_to_pfn() lookup needed for a foreign MFN. > > drivers/xen/swiotlb-xen.c:xen_unmap_single. xen_bus_to_phys is based on > the value returned by mfn_to_pfn. I think you can probably get away with not doing the cache operations on foreign pages when DMA map/unmapping. DMA mapped foreign pages are (currently) either: a) packets from a guest being Tx'd off host. These are read-only and are immediately freed after they're tranmitted. b) block requests from blkback and these pages are never accessed. David