On Fri, 2015-09-04 at 09:58 -0700, Jesse Barnes wrote: > I've been carrying something looking rougly like this patchset around > internally for a long time now, and with SKL out there now, I figured > it's time to get it posted and start the process of integration. > > David is working on pulling over most of the "driver based PASID > handling" and other code into the IOMMU layer, but the integration with > the rest of the driver needs some careful thought (handling task > referencing along with context referencing, context creation, etc.) I've pushed an early version of that to http://git.infradead.org/users/dwmw2/linux-svm.git/shortlog/refs/heads/i915-svm I don't have page fault handling yet, but I've at least got it to the point where gem_svm_sanity will succeed. I'll work on page faults next. However, I couldn't get your current tree to work (even with driver -mode SVM); I did this based on an older internal (svm-on-iommu-fences) branch and have blindly ported the patch across. I get this: # ./gem_svm_sanity using GPU to write 0xdead0000 to 0xca4860 value mismatch: read 0x00000000, expected 0xdead0000 And this: [ 105.490459] ------------[ cut here ]------------ [ 105.495756] WARNING: CPU: 2 PID: 1254 at drivers/gpu/drm/i915/intel_ringbuffer.c:2214 intel_ring_reserved_space_reserve+0x47/0x80 [i915]() [ 105.509917] WARN_ON(ringbuf->reserved_size) [ 105.514497] Modules linked in: tun nf_conntrack_netbios_ns nf_conntrack_broadcast ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ebtable_nat ebtable_broi [ 105.614355] CPU: 2 PID: 1254 Comm: gem_svm_sanity Tainted: G W I 4.2.0-rc8+ #2 [ 105.623680] Hardware name: Intel Corporation Skylake Client platform/Skylake Y LPDDR3 RVP3, BIOS SKLSE2R1.R00.X090.B01.1506290657 06/29/2015 [ 105.638023] ffffffffa026ed38 ffff880080093b98 ffffffff81703e35 0000000000000000 [ 105.646566] ffff880080093be8 ffff880080093bd8 ffffffff810916a6 ffff880169e40000 [ 105.655100] ffff88003f96a400 00000000000000a0 ffff880080093ce0 ffff88003f45b200 [ 105.663598] Call Trace: [ 105.666392] [<ffffffff81703e35>] dump_stack+0x45/0x57 [ 105.672252] [<ffffffff810916a6>] warn_slowpath_common+0x86/0xc0 [ 105.679119] [<ffffffff81091726>] warn_slowpath_fmt+0x46/0x50 [ 105.685705] [<ffffffffa01e7c57>] intel_ring_reserved_space_reserve+0x47/0x80 [i915] [ 105.694567] [<ffffffffa01e23bf>] intel_logical_ring_reserve_space+0x1f/0x30 [i915] [ 105.703303] [<ffffffffa01d0ef7>] i915_gem_request_alloc+0x107/0x1b0 [i915] [ 105.711274] [<ffffffffa0226c8d>] i915_fence_create_ring+0x2d/0x190 [i915] [ 105.719121] [<ffffffffa024f334>] intel_exec_mm_ioctl+0x224/0x3a0 [i915] [ 105.726806] [<ffffffffa00d7409>] drm_ioctl+0x129/0x4d0 [drm] [ 105.733372] [<ffffffffa024f110>] ? i915_getparam+0x260/0x260 [i915] [ 105.740601] [<ffffffff810bef2c>] ? __enqueue_entity+0x6c/0x70 [ 105.747282] [<ffffffff810c4afe>] ? set_next_entity+0x6e/0x400 [ 105.753976] [<ffffffff81209645>] do_vfs_ioctl+0x285/0x460 [ 105.760233] [<ffffffff812f711d>] ? selinux_file_ioctl+0x4d/0xc0 [ 105.767079] [<ffffffff812eecc3>] ? security_file_ioctl+0x43/0x60 [ 105.774026] [<ffffffff81209899>] SyS_ioctl+0x79/0x90 [ 105.779812] [<ffffffff81709c2e>] entry_SYSCALL_64_fastpath+0x12/0x71 [ 105.787152] ---[ end trace 633908b4ba32bd71 ]--- And as we discussed a little while ago, I always see this: ioctl(5, SYNC_IOC_WAIT, 0xffffffff) = -1 EFAULT (Bad address) ... so I've just stuck a sleep(5) in there to get the test to succeed. -- David Woodhouse Open Source Technology Centre David.Woodhouse@xxxxxxxxx Intel Corporation
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
