[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v3 0/3] map grant refs at pfn = mfn
On 1 August 2014 18:16, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx> wrote: > On Fri, 1 Aug 2014, Thomas Leonard wrote: >> 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? > > Checkout the branch grant_map_identity_4.4_2 Thanks - it's working now! -- 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |