All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Vrabel <david.vrabel@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: xen-devel@lists.xensource.com,
	"Wei Liu (Intern)" <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Julien Grall <julien.grall@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Zoltan Kiss <zoltan.kiss@citrix.com>,
	xen-users@lists.xen.org, Denis Schneider <v1ne2go@gmail.com>
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	[thread overview]
Message-ID: <53B6D814.2030606@citrix.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1407041527170.27641@kaball.uk.xensource.com>

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

  reply	other threads:[~2014-07-04 16:36 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAE8M+oJ0RjQ1Ovmry-9P5LJEkB_j186=7F6DdkR=vupkQQR-YQ@mail.gmail.com>
     [not found] ` <CAE8M+oLZZgjNaNUMV_PEvrH0kQPbg4ceV1uUJJsaE1ma5xCBgg@mail.gmail.com>
     [not found]   ` <1404295013.24733.8.camel@kazak.uk.xensource.com>
     [not found]     ` <CAE8M+oKdwA8Nx7oYTvz1kbeBJdWa0Ayr9DdOXAW1ev_q82Cwcw@mail.gmail.com>
     [not found]       ` <1404379885.14865.20.camel@kazak.uk.xensource.com>
2014-07-03 17:47         ` [Xen-users] ARM: "xen_add_mach_to_phys_entry: cannot add ... already exists and panics" Stefano Stabellini
2014-07-04 12:52           ` David Vrabel
2014-07-04 14:12             ` Stefano Stabellini
2014-07-04 14:23               ` David Vrabel
2014-07-04 14:31                 ` Stefano Stabellini
2014-07-04 16:36                   ` David Vrabel [this message]
2014-07-04 16:54                     ` David Vrabel
2014-07-07 16:25                       ` Stefano Stabellini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53B6D814.2030606@citrix.com \
    --to=david.vrabel@citrix.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=julien.grall@citrix.com \
    --cc=stefano.stabellini@citrix.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=v1ne2go@gmail.com \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xensource.com \
    --cc=xen-users@lists.xen.org \
    --cc=zoltan.kiss@citrix.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.