Re: [Xen-devel] [PATCH v3 0/3] map grant refs at pfn = mfn

[Thomas Leonard <talex5@xxxxxxxxx>]

On 1 August 2014 18:01, Stefano Stabellini
<stefano.stabellini@xxxxxxxxxxxxx> wrote:
> On Fri, 1 Aug 2014, Thomas Leonard wrote:
>> On 1 August 2014 17:25, Stefano Stabellini
>> <stefano.stabellini@xxxxxxxxxxxxx> wrote:
>> > On Fri, 1 Aug 2014, Julien Grall wrote:
>> >> On 01/08/14 17:16, Thomas Leonard wrote:
>> >> > On 1 August 2014 16:13, Stefano Stabellini
>> >> > <stefano.stabellini@xxxxxxxxxxxxx> wrote:
>> >> > > On Fri, 1 Aug 2014, Thomas Leonard wrote:
>> >> > > > On 24/07/14 14:30, Stefano Stabellini wrote:
>> >> > > > > Hi all,
>> >> > > > > this patch series introduces a second p2m mapping of grant 
>> >> > > > > reference
>> >> > > > > on
>> >> > > > > ARM at guest physical address == machine address of the grant 
>> >> > > > > ref.  It
>> >> > > > > is safe because dom0 is already mapped 1:1. We export
>> >> > > > > XENFEAT_grant_map_identity to signal the guest that this second 
>> >> > > > > p2m
>> >> > > > > mapping is
>> >> > > > > available.
>> >> > > > >
>> >> > > > > One reason for wanting the second p2m mapping is to avoid 
>> >> > > > > tracking mfn
>> >> > > > > to pfn mappings in the guest kernel. Since the same mfn can be 
>> >> > > > > granted
>> >> > > > > multiple times to the backend, finding the right pfn 
>> >> > > > > corresponding to
>> >> > > > > a
>> >> > > > > given mfn can be difficult and expensive. Providing a second 
>> >> > > > > mapping
>> >> > > > > at
>> >> > > > > a known address allow the kernel to access the page without 
>> >> > > > > knowing
>> >> > > > > the
>> >> > > > > pfn.
>> >> > > >
>> >> > > > Is there a version of these patches for Xen 4.4 that I can test? The
>> >> > > > restriction on duplicate pages is causing trouble for networking on
>> >> > > > Mirage too
>> >> > > > (http://roscidus.com/blog/blog/2014/07/28/my-first-unikernel/#tcp-retransmissions).
>> >> > >
>> >> > > The backport is non-trivial because
>> >> > > 552710b388630dfa461932940a998e120c42277d is missing from 4.4,
>> >> > > nonetheless it wasn't too hard to port:
>> >> > >
>> >> > >    git://xenbits.xen.org/people/sstabellini/xen-unstable.git
>> >> > > grant_map_identity_4.4
>> >> >
>> >> > Thanks. I merged it with the stable-4.4 branch (as that has some
>> >> > useful fixes too), but it crashed for me when I started my Mirage
>> >> > guest:
>> >>
>> >> You have to drop the BUG_ON line 729.
>> >
>> > Yes, you are right
>>
>> This one too?
>>
>> (XEN) Xen BUG at grant_table.c:946
>> (XEN) CPU1: Unexpected Trap: Undefined Instruction
>
> Yep, sorry.

It seems that removing this makes it not compile:

arm-linux-gnueabihf-ld    -EL  -T xen.lds -N prelink.o \
            /xen-arm-builder/xen/xen/common/symbols-dummy.o -o
/xen-arm-builder/xen/xen/.xen-syms.0
prelink.o: In function `__gnttab_unmap_common':
/xen-arm-builder/xen/xen/common/grant_table.c:952: undefined reference
to `iommu_unmap_page'
/xen-arm-builder/xen/xen/common/grant_table.c:959: undefined reference
to `iommu_map_page'
prelink.o: In function `__gnttab_map_grant_ref':
/xen-arm-builder/xen/xen/common/grant_table.c:739: undefined reference
to `iommu_map_page'
/xen-arm-builder/xen/xen/common/grant_table.c:750: undefined reference
to `iommu_map_page'
arm-linux-gnueabihf-ld: /xen-arm-builder/xen/xen/.xen-syms.0: hidden
symbol `iommu_unmap_page' isn't defined
arm-linux-gnueabihf-ld: final link failed: Bad value

Maybe the BUG_ON made this code unreachable before?


-- 
Dr Thomas Leonard        http://0install.net/
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

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