[Xen-devel] arm64: dma_to_phys/phys_to_dma need to be properly implemented

[Oleksandr Andrushchenko <andr2000@xxxxxxxxx>]

Hi, all!

First of all this could be a generic ARM64 question, but
only(?) Xen users will suffer.

At the moment for ARM64 dma_to_phys/phys_to_dma both assume that
MFN == PFN and though those do not do MFN <-> PFN conversion.
In case if MFN is mapped from other domain, then
MFN != PFN and the above assumption is not true any more and
proper MFN to PFN and vice versa must be implemented.

Use-case:
1. Get gref_u in DomU (PFN_u/MFN_u) and pass to Dom0
2. Balloon out a page PFN_0
3. Map gref_u onto PFN_0
4. Now PFN_0 is mapped to MFN_u and PFN_0 != MFN_u

If pair PFN_0/MFN_u is about to be used for example for
DMA sg table (which is my case), then conversion
dma_to_phys(MFN_u << PAGE_SHIFT) results in wrong PFN_bad,
not usable by CPU anymore because PFN_0 is expected instead

Is there any reason for ARM64's dma_to_phys/phys_to_dma to be
not implemented?

Thank you,

Oleksandr


On 03/23/2017 05:40 PM, Oleksandr Andrushchenko wrote:
> Hi, all!
>
> I am trying to implement a zero-copy scenario for DRM front/back,
> e.g. buffers allocated by DomU in the DRM frontend used as is
> by Dom0. The requirement I have is that the buffer is contiguous.
>
> So, what I currently have is:
> 1. DomU is 1:1 mapped and is able to allocate physically contiguous
> buffer, e.g. PFNs and MFNs are sequential.
> 2. On Dom0 side I allocate ballooned pages (because I need reservation)
> and am able to map those (gnttab_map_refs with grefs from DomU):
> pfn 52a35 dev_bus_addr 6c100000
> pfn 52a34 dev_bus_addr 6c101000
> ...
> pfn 52a2c dev_bus_addr 6c109000
>
> 3. Then I have to create an SG table from these, so I can pass the buffer
> to real HW DRM driver: as you can see from the above PFNs they are not
> sequential as those were allocated from the balloon. Thus, sg_table
> is also has number of segments != 1 which is not ok for my use-case.
>
> Still, if I do __pfn_to_mfn(page_to_pfn(balloon_page[i])) I get the
>
> correct MFN, which is expected because p2m translation happens.
>
> 4. If I try to do a hack:
> dev_bus_pages[i] = pfn_to_page(MFN[i]) and then create an SG table from
> these pages then of course the sg table is configuous and
> I can share the SG with HW DRM driver.
> What is naturally happens next is:
> "Unable to handle kernel paging request at virtual address 
> ffff80002c100000"
> [   86.263197] PC is at __clean_dcache_area_poc+0x20/0x40
> [   86.268377] LR is at __swiotlb_map_page+0x80/0x98
> for the very first maddr == 6c100000, because my dev_bus_addr[i] and
> dev_bus_pages[i] have no translation set up.
>
> So, the question: is there any way I can make those ballooned pages
> to convert into contiguous scatter-gather? So, sg table consists
> of a single entry?
>
> I was thinking of:
> 1. Is it possible to update translation manually so dev_bus_addr[i]
> has corresponding continuous pages, e.g. so I can do
> dev_bus_pages[i] = pfn_to_page(MFN[i]) and CPU can access those?
> 2. I can of course allocate contiguous buffer in Dom0 and
> manually (unfortunately there is no API to do that) increase/decrease
> reservation for the pages as balloon driver does and use those for 
> mapping.
> This way MFN will follow PFN (we are in Dom0 which is 1:1).
> But this is going to be clumsy, as I'll have to copy-paste part
> of the balloon driver into mine 
> (decrease_reservation/increase_reservation)
> 3. Any other neat solution?
>
> Thank you,
> Oleksandr

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