Re: i915 and swiotlb_max_segment

2021-06-03 Thread Joonas Lahtinen
+ Tvrtko to take a look

Quoting Konrad Rzeszutek Wilk (2021-05-20 18:12:58)
> On Mon, May 10, 2021 at 05:25:25PM +0200, Christoph Hellwig wrote:
> > Hi all,
> > 
> > swiotlb_max_segment is a rather strange "API" export by swiotlb.c,
> > and i915 is the only (remaining) user.
> > 
> > swiotlb_max_segment returns 0 if swiotlb is not in use, 1 if
> > SWIOTLB_FORCE is set or swiotlb-zen is set, and the swiotlb segment
> > size when swiotlb is otherwise enabled.
> > 
> > i915 then uses it to:
> > 
> >  a) decided on the max order in i915_gem_object_get_pages_internal
> >  b) decide on a max segment size in i915_sg_segment_size
> > 
> > for a) it really seems i915 should switch to dma_alloc_noncoherent
> > or dma_alloc_noncontigous ASAP instead of using alloc_page and
> > streaming DMA mappings.  Any chance I could trick one of the i915
> > maintaines into doing just that given that the callchain is not
> > exactly trivial?
> > 
> > For b) I'm not sure swiotlb and i915 really agree on the meaning
> > of the value.  swiotlb_set_max_segment basically returns the entire
> > size of the swiotlb buffer, while i915 seems to use it to limit
> > the size each scatterlist entry.  It seems like dma_max_mapping_size
> > might be the best value to use here.
> 
> Yes. The background behind that was SWIOTLB would fail because well, the
> size of the sg was too large. And some way to limit it to max size
> was needed - the dma_max_mapping_size "should" be just fine.
> 
> > 
> > Once that is fixed I'd like to kill off swiotlb_max_segment as it is
> > a horribly confusing API.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v4 0/7] Convert the intel iommu driver to the dma-iommu api

2020-11-03 Thread Joonas Lahtinen
Quoting Tvrtko Ursulin (2020-11-03 11:14:32)
> 
> 
> On 03/11/2020 02:53, Lu Baolu wrote:
> > On 11/2/20 7:52 PM, Tvrtko Ursulin wrote:
> >>
> >> On 02/11/2020 02:00, Lu Baolu wrote:
> >>> Hi Tvrtko,
> >>> On 10/12/20 4:44 PM, Tvrtko Ursulin wrote:
> 
>  On 29/09/2020 01:11, Lu Baolu wrote:



>  FYI we have merged the required i915 patches to out tree last week 
>  or so. I *think* this means they will go into 5.11. So the i915 
>  specific workaround patch will not be needed in Intel IOMMU.
> >>>
> >>> Do you mind telling me what's the status of this fix patch? I tried this
> >>> series on v5.10-rc1 with the graphic quirk patch dropped. I am still
> >>> seeing dma faults from graphic device.
> >>
> >> Hmm back then I thought i915 fixes for this would land in 5.11 so I 
> >> will stick with that. :) (See my quoted text a paragraph above yours.)
> > 
> > What size are those fixes? I am considering pushing this series for
> > v5.11. Is it possible to get some acks for those patches and let them
> > go to Linus through iommu tree?
> 
> For 5.10 you mean? They feel a bit too large for comfort to go via a 
> non-i915/drm tree. These are the two patches required:
> 
> https://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-gt-next=8a473dbadccfc6206150de3db3223c40785da348
> https://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-gt-next=934941ed5a3070a7833c688c9b1d71484fc01a68
> 
> I'll copy Joonas as our maintainer - how does the idea of taking the 
> above two patches through the iommu tree sound to you?

Hi Lu,

The patches have already been merged into our tree and are heading
towards 5.11, so I don't think we should merge them elsewhere. DRM
subsystem had the feature freeze for 5.10 at the time of 5.9-rc5
and only drm-intel-fixes pull requests are sent after that.

The patches seem to target to eliminate need for a previously used
workaround. To me it seems more appropriate for the patches to follow
the regular process as new feature for 5.11 to make sure the changes
get validated as part of linux-next.

Would that work for you? We intend to send the feature pull requests
to DRM for 5.11 in the upcoming weeks.

Regards, Joonas
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH] iommu/intel: quirk to disable DMAR for QM57 igfx

2019-01-23 Thread Joonas Lahtinen
Quoting Joerg Roedel (2019-01-22 18:51:35)
> On Tue, Jan 22, 2019 at 04:48:26PM +0200, Joonas Lahtinen wrote:
> > According to our IOMMU folks there exists some desire to be able to assign
> > the iGFX device aka have intel_iommu=on instead of intel_iommu=igfx_off
> > due to how the devices might be grouped in IOMMU groups. Even when you
> > would not be using the iGFX device.
> 
> You can force the igfx device into a SI domain, or does that also
> trigger the iommu issues on the chipset?

To be honest, we've had a mixture different issues on different SKUs
that have not been hit in the past when intel_iommu was just disabled by
default.

I know that in one group of the problems, the issue has been debugged
into the GPU having its own set of virtualization mapping translation
hardware with caching and it fails to track changes to the mapping. So
if a identity mapping was established and never changed, I'd assume that
to fix at least that class of problems.

Would just passing intel_iommu=on already cause a non-identity mapping to
possibly be used for the integrated GPU? If it did, then it would
explain quite few of the issues.

We have many reports where just having intel_iommu=on (and using the
system normally, without any virtualization stuff going on) will cause
unexplained GPU hangs. For those users, simply switching to
intel_iommu=igfx_off solves the problems, and the debug often ends
there.

Regards, Joonas

> In any case, if iommu=on breaks these systems I want to make them work
> again with opt-out, even at the cost of breaking assignability.
> 
> Regards,
> 
> Joerg
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH] iommu/intel: quirk to disable DMAR for QM57 igfx

2019-01-22 Thread Joonas Lahtinen
Quoting Joerg Roedel (2019-01-22 13:01:09)
> Hi Daniel,
> 
> On Tue, Jan 22, 2019 at 11:46:39AM +0100, Daniel Vetter wrote:
> > Note that the string of platforms which have various issues with iommu
> > and igfx is very long, thus far we only disabled it where there's no
> > workaround to stop it from hanging the box, but otherwise left it
> > enabled. So if we make a policy change to also disable it anywhere
> > where it doesn't work well (instead of not at all), there's a pile
> > more platforms to switch.
> 
> I think its best to just disable iommu for the igfx devices on these
> platforms. Can you pick up Eric's patch and extend it with the list of
> affected platforms?

We've been discussing this again more actively since a few months ago,
and the discussion is still ongoing internally.

According to our IOMMU folks there exists some desire to be able to assign
the iGFX device aka have intel_iommu=on instead of intel_iommu=igfx_off
due to how the devices might be grouped in IOMMU groups. Even when you
would not be using the iGFX device.

So for some uses, the fact that the device (group) is assignable seems
to be more important than the iGFX device to be working. I'm afraid
that retroactively disabling the assignment for such an old platform
might break those usage scenarios. By my quick reading of the code,
there's no way for user to turn the iGFX DMAR on once the quirk
disables it.

I guess one solution would be to default to intel_iommu=igfx_off for
platforms that are older than certain threshold. But still allow
user to enable. But that then requires duplicating the PCI ID database
into iommu code.

I don't really have winning moves to present, but I'm open to hearing
how we can avoid more damage than starting to default to intel_iommu=on
did already.

Regards, Joonas

> 
> Thanks,
> 
> Joerg
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: iommu_intel or i915 regression in 4.18, 4.19.12 and drm-tip

2019-01-04 Thread Joonas Lahtinen
Quoting Eric Wong (2019-01-04 03:06:26)
> Joonas Lahtinen  wrote:
> > Quoting Eric Wong (2018-12-27 13:49:48)
> > > I just got a used Thinkpad X201 (Core i5 M 520, Intel QM57
> > > chipset) and hit some kernel panics while trying to view
> > > image/animation-intensive stuff in Firefox (X11) unless I use
> > > "iommu_intel=igfx_off".
> > > 
> > > With Debian stable backport kernels, "linux-image-4.17.0-0.bpo.3-amd64"
> > > (4.17.17-1~bpo9+1) has no problems.  But 
> > > "linux-image-4.18.0-0.bpo.3-amd64"
> > > (4.18.20-2~bpo9+1) gives a blank screen before I can login via agetty
> > > and run startx.
> 
> > Most confusing about this is that 4.17 would have worked to begin with,
> > without intel_iommu=igfx_off (unless it was the default for older
> > kernel?)
> 
> Yeah, so the Debian bpo 4.17(.17) kernel did not set
> CONFIG_INTEL_IOMMU_DEFAULT_ON, so I didn't encounter problems.
> My self-built kernels all set CONFIG_INTEL_IOMMU_DEFAULT_ON.

So it's the case that IOMMU never worked on your machine.

My recommendation would be to simply use intel_iommu=igfx_off if you
need IOMMU.

Old hardware is known to have issues with IOMMU, and retroactively
enabling IOMMU on those machines just brings them up :/

Regards, Joonas

> Booting the Debian 4.17 kernel with "intel_iommu=on" gives the
> same hanging problem I hit with self-built 4.19.{12,13} kernels.
> 
> I'm not sure how far back the problem goes (maybe forever),
> since I only got this hardware.  Not sure what's the problem
> with Debian 4.18, either; but (self-built) 4.19.13 is fine w/o
> CONFIG_INTEL_IOMMU_DEFAULT_ON.
> 
> Debian backports doesn't have kernels for 4.19 or 4.20, yet.
> 
> > Did you maybe update other parts of the system while updating the
> > kernel?
> 
> Definitely not; just the kernel + headers ("make bindeb-pkg)".
> 
> > If you could attach full boot dmesg from working and non-working kernel +
> > have config file of both kernel's in Bugzilla. That'd be a good start!
> 
> Sorry, I get anxiety attacks when it comes to logins and forms.
> Anyways, I managed to get the Debian kernel dmesg output uploaded
> with and without iommu_intel=on:
> https://bugs.freedesktop.org/attachment.cgi?bugid=109219
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: iommu_intel or i915 regression in 4.18, 4.19.12 and drm-tip

2019-01-02 Thread Joonas Lahtinen
Quoting Eric Wong (2018-12-27 13:49:48)
> I just got a used Thinkpad X201 (Core i5 M 520, Intel QM57
> chipset) and hit some kernel panics while trying to view
> image/animation-intensive stuff in Firefox (X11) unless I use
> "iommu_intel=igfx_off".
> 
> With Debian stable backport kernels, "linux-image-4.17.0-0.bpo.3-amd64"
> (4.17.17-1~bpo9+1) has no problems.  But "linux-image-4.18.0-0.bpo.3-amd64"
> (4.18.20-2~bpo9+1) gives a blank screen before I can login via agetty
> and run startx.

Could you open a new bug at (and attach relevant information there):

https://01.org/linuxgraphics/documentation/how-report-bugs

Most confusing about this is that 4.17 would have worked to begin with,
without intel_iommu=igfx_off (unless it was the default for older
kernel?)

Did you maybe update other parts of the system while updating the
kernel?

If you could attach full boot dmesg from working and non-working kernel +
have config file of both kernel's in Bugzilla. That'd be a good start!

Regards, Joonas

> Building 4.19.12 myself got me into X11 and able to start
> Firefox to panic the kernel.  I also updated to the latest BIOS
> (1.40), but it's an EOL laptop (but it's still the most powerful
> laptop I use).  I intend to replace the BIOS with Coreboot soon...
> 
> Initially, I thought I was hitting another GPU hang from 4.18+:
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=107945
> 
> But building drm-tip @ commit 28bb1fc015cedadf3b099b8bd0bb27609849f362
> ("drm-tip: 2018y-12m-25d-08h-12m-37s UTC integration manifest")
> I was still able to reproduce the panic unless I use iommu_intel=igfx_off
> "i915.reset=1" did not help matters, either.
> 
> Below is what I got from netconsole while on drm-tip:
> 
> Kernel panic - not syncing: DMAR hardware is malfunctioning
> Shutting down cpus with NMI
> Kernel Offset: disabled
> ---[ end Kernel panic - not syncing: DMAR hardware is malfunctioning ]---
> [ cut here ]
> sched: Unexpected reschedule of offline CPU#3!
> WARNING: CPU: 0 PID: 105 at native_smp_send_reschedule+0x34/0x40
> Modules linked in: netconsole ccm snd_hda_codec_hdmi snd_hda_codec_conexant 
> snd_hda_codec_generic intel_powerclamp coretemp kvm_intel kvm irqbypass 
> crc32_pclmul crc32c_intel ghash_clmulni_intel arc4 iwldvm aesni_intel 
> aes_x86_64 crypto_simd cryptd mac80211 glue_helper intel_cstate iwlwifi 
> intel_uncore i915 intel_gtt i2c_algo_bit iosf_mbi drm_kms_helper cfbfillrect 
> syscopyarea intel_ips cfbimgblt sysfillrect sysimgblt fb_sys_fops cfbcopyarea 
> thinkpad_acpi prime_numbers cfg80211 ledtrig_audio i2c_i801 sg snd_hda_intel 
> led_class snd_hda_codec drm ac drm_panel_orientation_quirks snd_hwdep battery 
> e1000e agpgart snd_hda_core snd_pcm snd_timer ptp snd soundcore pps_core 
> ehci_pci ehci_hcd lpc_ich video mfd_core button acpi_cpufreq ecryptfs 
> ip_tables x_tables ipv6 evdev thermal [last unloaded: netconsole]
> CPU: 0 PID: 105 Comm: kworker/u8:3 Not tainted 4.20.0-rc7b1+ #1
> Hardware name: LENOVO 3680FBU/3680FBU, BIOS 6QET70WW (1.40 ) 10/11/2012
> Workqueue: i915 __i915_gem_free_work [i915]
> RIP: 0010:native_smp_send_reschedule+0x34/0x40
> Code: 05 69 c6 c9 00 73 15 48 8b 05 18 2d b3 00 be fd 00 00 00 48 8b 40 30 e9 
> 9a 58 7d 00 89 fe 48 c7 c7 78 73 af 81 e8 dc c2 01 00 <0f> 0b c3 66 0f 1f 84 
> 00 00 00 00 00 66 66 66 66 90 8b 05 0d 7d df
> RSP: 0018:888075003d98 EFLAGS: 00010092
> RAX: 002e RBX: 8880751a0740 RCX: 0006
> RDX: 0007 RSI: 0082 RDI: 888075015440
> RBP: 88806e823700 R08:  R09: 888072fc07c0
> R10: 888075003d60 R11: fff5c002 R12: 8880751a0740
> R13: 8880751a0740 R14:  R15: 0003
> FS:  () GS:88807500() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 7fdb1f53f000 CR3: 01c0a004 CR4: 000206f0
> Call Trace:
>  
>  ? check_preempt_curr+0x4e/0x90
>  ? ttwu_do_wakeup.isra.19+0x14/0xf0
>  ? try_to_wake_up+0x323/0x410
>  ? autoremove_wake_function+0xe/0x30
>  ? __wake_up_common+0x8d/0x140
>  ? __wake_up_common_lock+0x6c/0x90
>  ? irq_work_run_list+0x49/0x80
>  ? tick_sched_handle.isra.6+0x50/0x50
>  ? update_process_times+0x3b/0x50
>  ? tick_sched_handle.isra.6+0x30/0x50
>  ? tick_sched_timer+0x3b/0x80
>  ? __hrtimer_run_queues+0xea/0x270
>  ? hrtimer_interrupt+0x101/0x240
>  ? smp_apic_timer_interrupt+0x6a/0x150
>  ? apic_timer_interrupt+0xf/0x20
>  
>  ? panic+0x1ca/0x212
>  ? panic+0x1c7/0x212
>  ? __iommu_flush_iotlb+0x19e/0x1c0
>  ? iommu_flush_iotlb_psi+0x96/0xf0
>  ? intel_unmap+0xbf/0xf0
>  ? i915_gem_object_put_pages_gtt+0x36/0x220 [i915]
>  ? drm_ht_remove+0x20/0x20 [drm]
>  ? drm_mm_remove_node+0x1ad/0x310 [drm]
>  ? __pm_runtime_resume+0x54/0x70
>  ? __i915_gem_object_unset_pages+0x129/0x170 [i915]
>  ? __i915_gem_object_put_pages+0x70/0xa0 [i915]
>  ? __i915_gem_free_objects+0x245/0x4e0 [i915]
>  ? 

Re: [PATCH v3 2/2] iommu: Remove cpu-local spinlock

2016-06-01 Thread Joonas Lahtinen
On ke, 2016-06-01 at 12:10 +0100, Chris Wilson wrote:
> By avoiding cross-CPU usage of the per-cpu iova cache, we can forgo
> having a spinlock inside the per-cpu struct. The only place where we
> actually may touch another CPU's data is when performing a cache flush
> after running out of memory. Here, we can instead schedule a task to run
> on the other CPU to do the flush before trying again.
> 
> Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
> Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
> Cc: Joerg Roedel <j...@8bytes.org>
> Cc: iommu@lists.linux-foundation.org
> Cc: linux-ker...@vger.kernel.org
> ---
>  drivers/iommu/iova.c | 29 ++---
>  1 file changed, 6 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
> index e23001bfcfee..36cdc8eeab1c 100644
> --- a/drivers/iommu/iova.c
> +++ b/drivers/iommu/iova.c
> @@ -390,6 +390,11 @@ free_iova(struct iova_domain *iovad, unsigned long pfn)
>  }
>  EXPORT_SYMBOL_GPL(free_iova);
>  
> +static void free_this_cached_iovas(void *info)
> +{
> + free_cpu_cached_iovas(smp_processor_id(), info);
> +}
> +
>  /**
>   * alloc_iova_fast - allocates an iova from rcache
>   * @iovad: - iova domain in question
> @@ -413,17 +418,12 @@ alloc_iova_fast(struct iova_domain *iovad, unsigned 
> long size,
>  retry:
>   new_iova = alloc_iova(iovad, size, limit_pfn, true);
>   if (!new_iova) {
> - unsigned int cpu;
> -
>   if (flushed_rcache)
>   return 0;
>  
>   /* Try replenishing IOVAs by flushing rcache. */
>   flushed_rcache = true;
> - preempt_disable();
> - for_each_online_cpu(cpu)
> - free_cpu_cached_iovas(cpu, iovad);
> - preempt_enable();
> + on_each_cpu(free_this_cached_iovas, iovad, true);

This is not on a hot path, so should be worthy change.

Reviewed-by: Joonas Lahtinen <joonas.lahti...@linux.intel.com>

Regards, Joonas

>   goto retry;
>   }
>  
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v3 1/2] iommu: Disable preemption around use of this_cpu_ptr()

2016-06-01 Thread Joonas Lahtinen
On ke, 2016-06-01 at 12:10 +0100, Chris Wilson wrote:
> Between acquiring the this_cpu_ptr() and using it, ideally we don't want
> to be preempted and work on another CPU's private data. this_cpu_ptr()
> checks whether or not preemption is disable, and get_cpu_ptr() provides
> a convenient wrapper for operating on the cpu ptr inside a preemption
> disabled critical section (which currently is provided by the
> spinlock). Indeed if we disable preemption around this_cpu_ptr,
> we do not need the CPU local spinlock - so long as take care that no other
> CPU is running that code as do perform the cross-CPU cache flushing and
> teardown, but that is a subject for another patch.
> 
> [  167.997877] BUG: using smp_processor_id() in preemptible [] code: 
> usb-storage/216
> [  167.997940] caller is debug_smp_processor_id+0x17/0x20
> [  167.997945] CPU: 7 PID: 216 Comm: usb-storage Tainted: G U  
> 4.7.0-rc1-gfxbench-RO_Patchwork_1057+ #1
> [  167.997948] Hardware name: Hewlett-Packard HP Pro 3500 Series/2ABF, BIOS 
> 8.11 10/24/2012
> [  167.997951]   880118b7f9c8 8140dca5 
> 0007
> [  167.997958]  81a3a7e9 880118b7f9f8 8142a927 
> 
> [  167.997965]  8800d499ed58 0001 000f 
> 880118b7fa08
> [  167.997971] Call Trace:
> [  167.997977]  [] dump_stack+0x67/0x92
> [  167.997981]  [] check_preemption_disabled+0xd7/0xe0
> [  167.997985]  [] debug_smp_processor_id+0x17/0x20
> [  167.997990]  [] alloc_iova_fast+0xb7/0x210
> [  167.997994]  [] intel_alloc_iova+0x7f/0xd0
> [  167.997998]  [] intel_map_sg+0xbd/0x240
> [  167.998002]  [] ? debug_lockdep_rcu_enabled+0x1d/0x20
> [  167.998009]  [] usb_hcd_map_urb_for_dma+0x4b9/0x5a0
> [  167.998013]  [] usb_hcd_submit_urb+0xe9/0xaa0
> [  167.998017]  [] ? mark_held_locks+0x6f/0xa0
> [  167.998022]  [] ? __raw_spin_lock_init+0x1c/0x50
> [  167.998025]  [] ? debug_lockdep_rcu_enabled+0x1d/0x20
> [  167.998028]  [] usb_submit_urb+0x3f3/0x5a0
> [  167.998032]  [] ? trace_hardirqs_on_caller+0x122/0x1b0
> [  167.998035]  [] usb_sg_wait+0x67/0x150
> [  167.998039]  [] usb_stor_bulk_transfer_sglist.part.3+0x82/0xd0
> [  167.998042]  [] usb_stor_bulk_srb+0x4c/0x60
> [  167.998045]  [] usb_stor_Bulk_transport+0x17e/0x420
> [  167.998049]  [] usb_stor_invoke_transport+0x242/0x540
> [  167.998052]  [] ? debug_lockdep_rcu_enabled+0x1d/0x20
> [  167.998058]  [] usb_stor_transparent_scsi_command+0x9/0x10
> [  167.998061]  [] usb_stor_control_thread+0x158/0x260
> [  167.998064]  [] ? fill_inquiry_response+0x20/0x20
> [  167.998067]  [] ? fill_inquiry_response+0x20/0x20
> [  167.998071]  [] kthread+0xea/0x100
> [  167.998078]  [] ret_from_fork+0x1f/0x40
> [  167.998081]  [] ? kthread_create_on_node+0x1f0/0x1f0
> 
> v2: convert preempt_disable(); var = this_cpu_ptr() to var = get_cpu_ptr()
> v3: Actually use get_cpu_ptr (not get_cpu_var). Drop the spinlock
> removal, concentrate on the immediate bug fix.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96293
> Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
> Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com>

Reviewed-by: Joonas Lahtinen <joonas.lahti...@linux.intel.com>

> Cc: Joerg Roedel <j...@8bytes.org>
> Cc: iommu@lists.linux-foundation.org
> Cc: linux-ker...@vger.kernel.org
> ---
>  drivers/iommu/iova.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
> index ba764a0835d3..e23001bfcfee 100644
> --- a/drivers/iommu/iova.c
> +++ b/drivers/iommu/iova.c
> @@ -420,8 +420,10 @@ retry:
>  
>   /* Try replenishing IOVAs by flushing rcache. */
>   flushed_rcache = true;
> + preempt_disable();
>   for_each_online_cpu(cpu)
>   free_cpu_cached_iovas(cpu, iovad);
> + preempt_enable();
>   goto retry;
>   }
>  
> @@ -749,7 +751,7 @@ static bool __iova_rcache_insert(struct iova_domain 
> *iovad,
>   bool can_insert = false;
>   unsigned long flags;
>  
> - cpu_rcache = this_cpu_ptr(rcache->cpu_rcaches);
> + cpu_rcache = get_cpu_ptr(rcache->cpu_rcaches);
>   spin_lock_irqsave(_rcache->lock, flags);
>  
>   if (!iova_magazine_full(cpu_rcache->loaded)) {
> @@ -779,6 +781,7 @@ static bool __iova_rcache_insert(struct iova_domain 
> *iovad,
>   iova_magazine_push(cpu_rcache->loaded, iova_pfn);
>  
>   spin_unlock_irqrestore(_rcache->lock, flags);
> + put_cpu_ptr(rcache->cpu_rcaches);
>  
>   if (mag_to_free) {
>   iova_magazin