Re: [Xen-devel] [Xen-users] ARM: "xen_add_mach_to_phys_entry: cannot add ... already exists and panics"

[David Vrabel <david.vrabel@xxxxxxxxxx>]

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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel