Page MenuHomeFreeBSD

tychon (Tycho Nightingale)
User

Projects

User Details

User Since
Aug 11 2014, 8:37 PM (254 w, 1 d)

Recent Activity

Wed, Jun 5

tychon committed rS348687: another occurrence where a very large dma mapping can cause integer overflow.
another occurrence where a very large dma mapping can cause integer overflow
Wed, Jun 5, 1:08 PM

Mon, Jun 3

tychon committed rS348571: very large dma mappings can cause integer overflow.
very large dma mappings can cause integer overflow
Mon, Jun 3, 7:19 PM
tychon closed D20505: very large dma mappings can cause integer overflow.
Mon, Jun 3, 7:19 PM
tychon created D20505: very large dma mappings can cause integer overflow.
Mon, Jun 3, 5:10 PM

May 17 2019

tychon committed rS347903: Remove unused define..
Remove unused define.
May 17 2019, 1:08 PM

May 16 2019

tychon committed rS347896: Fix integer overflow in r346386..
Fix integer overflow in r346386.
May 16 2019, 10:27 PM
tychon closed D20277: revert 4GB workarounds for bge and aac.
May 16 2019, 8:41 PM
tychon committed rS347890: reinstate 4GB DMA boundary workarounds for bge and aac.
reinstate 4GB DMA boundary workarounds for bge and aac
May 16 2019, 8:41 PM
tychon added inline comments to D20277: revert 4GB workarounds for bge and aac.
May 16 2019, 8:10 PM
tychon committed rS347836: Allow loading the same DMA address multiple times without any prior.
Allow loading the same DMA address multiple times without any prior
May 16 2019, 5:41 PM
tychon closed D20181: For the LinuxKPI allow loading the same DMA address multiple times without any prior unload.
May 16 2019, 5:41 PM
tychon added inline comments to D20181: For the LinuxKPI allow loading the same DMA address multiple times without any prior unload.
May 16 2019, 1:53 PM
tychon updated the diff for D20181: For the LinuxKPI allow loading the same DMA address multiple times without any prior unload.

Swapped aarch64 for arm64 per emaste's suggestion and addressed rlibby's nits.

May 16 2019, 1:48 PM
tychon created D20277: revert 4GB workarounds for bge and aac.
May 16 2019, 1:16 PM

May 15 2019

tychon added inline comments to D20263: iommu static analysis cleanup.
May 15 2019, 4:58 PM
tychon added a comment to D20097: Fix regression issues after r346645 in the LinuxKPI.

What is remaining in this review?

May 15 2019, 4:55 PM

May 13 2019

tychon updated the diff for D20181: For the LinuxKPI allow loading the same DMA address multiple times without any prior unload.

Add support for arm64 plus rework _bus_dmamap_pagesneeded to short-circuit if we don't need an exact count but just need to know if *any* are needed.

May 13 2019, 4:30 PM

May 7 2019

tychon added a comment to D20181: For the LinuxKPI allow loading the same DMA address multiple times without any prior unload.

I'll give this a spin and look for regressions in graphics land, but it might take a day or two. Can you add x11 as group reviewer?

May 7 2019, 1:37 PM
tychon updated subscribers of D20181: For the LinuxKPI allow loading the same DMA address multiple times without any prior unload.
May 7 2019, 1:36 PM
tychon created D20181: For the LinuxKPI allow loading the same DMA address multiple times without any prior unload.
May 7 2019, 1:12 PM

May 6 2019

tychon added a comment to D20097: Fix regression issues after r346645 in the LinuxKPI.

Joining a few threads on this back together, below is a fleshed out version (minus arm64) of what I am thinking. It removes some penalty (the additional LOOKUP) when dmar is enabled and significantly reduces overhead in the bounce-without-bounce case.

May 6 2019, 8:38 PM
tychon committed rS347168: zero inputs to vm_page_initfake() for predictable results.
zero inputs to vm_page_initfake() for predictable results
May 6 2019, 12:57 AM
tychon closed D20162: zero vm_page_t inputs to vm_page_initfake() for predictable results.
May 6 2019, 12:57 AM

May 5 2019

tychon updated the diff for D20162: zero vm_page_t inputs to vm_page_initfake() for predictable results.
May 5 2019, 8:02 PM
tychon updated the diff for D20162: zero vm_page_t inputs to vm_page_initfake() for predictable results.

Update to a diff with full context.

May 5 2019, 5:32 PM
tychon created D20162: zero vm_page_t inputs to vm_page_initfake() for predictable results.
May 5 2019, 5:28 PM

May 4 2019

tychon accepted D20154: amd64: fix BUS_SPACE_MAXSIZE to 64bit max value..
In D20154#434058, @kib wrote:

I think that 4G value for BUS_SPACE_MAXSIZE still chomped the PCIe max DMA transfers into 4G chunks.

May 4 2019, 11:05 AM

May 3 2019

tychon added a comment to D20097: Fix regression issues after r346645 in the LinuxKPI.

This is still running fine from a graphics perspective.
DRM has been broken for some time now, what's needed to get this in?

May 3 2019, 4:27 PM

May 2 2019

tychon added a comment to D20097: Fix regression issues after r346645 in the LinuxKPI.

In D20097#433503, @kib wrote:
Why do you suggest that length check is not needed ? Putting the discussion of a possible race aside, why the lengths of two loads must be the same ?

May 2 2019, 7:41 PM
tychon added a comment to D20097: Fix regression issues after r346645 in the LinuxKPI.
In D20097#433442, @kib wrote:

I don't see how multiple mappings aren't a bug. The linux API doesn't do any ref-counting. There the first unmap would wipe out both. If there is sharing of an underlying resource that needs to be coordinated at a higher level; this isn't the place. Tolerating it to provide some cover is one thing and I'm not sure I even agree that is the right approach. IMHO fixing the driver is.

The double-mappings should not be bugs same as they are fine for our native busdma KPI. Consider:

  • for bounce, without bounce, bus address == phys address and nothing happens both on map and unmap
  • for bounce, with bounce, second map allocates another set of bounce pages, so bus address is different
  • for DMAR, guest mapping is created anew for each map request, again it is fine.

One of my points is that physical address is user-controllable, in some situations, so the KPI must handle duplicates.

May 2 2019, 2:00 PM
tychon added a comment to D20097: Fix regression issues after r346645 in the LinuxKPI.
In D20097#433274, @kib wrote:

@kib: I was thinking it would be better in a followup commit to add a debug knob to print the backtrace when double mappings happen or when the unmap cannot find the DMA address, and trace this down in the ibcore code. It is apparently a bug. Right now DRM-next and IBCORE works with this patch, and I think the current behaviour to kill old mappings on the same address is fine.

I disagree completely. Suppose that two RDMA clients mmap the same shared memory, and then use the same buffer for transfers.

May 2 2019, 10:35 AM

May 1 2019

tychon added a comment to D20097: Fix regression issues after r346645 in the LinuxKPI.

Would it be prudent to decouple #2 and #3? The fix for #1 raises some interesting implementation questions and may ultimately be fixed better in the driver anyway.

May 1 2019, 3:45 PM

Apr 30 2019

tychon accepted D20097: Fix regression issues after r346645 in the LinuxKPI.

Ideally #2 and #3 would be discrete commits but I see the value in single place to point folks to.

Apr 30 2019, 3:48 PM

Apr 29 2019

tychon accepted D20097: Fix regression issues after r346645 in the LinuxKPI.

I really like what you did with the locking. Thanks for pitching in here!!

Apr 29 2019, 4:24 PM

Apr 25 2019

tychon committed rS346687: LinuxKPI buildfix for ppc64 after r346645..
LinuxKPI buildfix for ppc64 after r346645.
Apr 25 2019, 6:14 PM

Apr 24 2019

tychon committed rS346645: LinuxKPI should use bus_dma(9) to be compatible with an IOMMU.
LinuxKPI should use bus_dma(9) to be compatible with an IOMMU
Apr 24 2019, 8:30 PM
tychon closed D19845: to be compatible with an IOMMU LinuxKPI should use bus_dma(9).
Apr 24 2019, 8:30 PM

Apr 19 2019

tychon committed rS346386: remove the 4GB boundary requirement on PCI DMA segments.
remove the 4GB boundary requirement on PCI DMA segments
Apr 19 2019, 1:43 PM
tychon closed D19867: remove the 4GB boundary requirement on PCI DMA segments.
Apr 19 2019, 1:43 PM

Apr 18 2019

tychon added a comment to D19845: to be compatible with an IOMMU LinuxKPI should use bus_dma(9).

Some more i915 GPU testing (w/o the latest update here): after using Firefox (opengl layers, xwayland) for some time, GPU resets start happening

drmn0: Resetting chip for stuck wait on rcs0
drmn0: Resetting chip for stuck wait on rcs0
drmn0: Resetting chip for stuck wait on rcs0
…
DMAR0: Fault Overflow
DMAR0: vgapci0: pci:0:2:0 sid 10 fault acc 0 adt 0x0 reason 0x5 addr 2e09000
DMAR0: Fault Overflow
DMAR0: vgapci0: pci:0:2:0 sid 10 fault acc 0 adt 0x0 reason 0x5 addr 2e09000

and eventually the whole system freezes if I don't quit the compositor / switch to vt console.

Apr 18 2019, 12:36 PM

Apr 17 2019

tychon added inline comments to D19845: to be compatible with an IOMMU LinuxKPI should use bus_dma(9).
Apr 17 2019, 9:52 PM
tychon updated the diff for D19845: to be compatible with an IOMMU LinuxKPI should use bus_dma(9).

Bump __FreeBSD_version and serialize required bus_dma(9) calls.

Apr 17 2019, 9:48 PM

Apr 16 2019

tychon updated the diff for D19845: to be compatible with an IOMMU LinuxKPI should use bus_dma(9).

Fix most trivial of trivial whitespace issues. I just want to avoid the tool chain complaining about any divergences so I'm updating the diff.

Apr 16 2019, 8:03 PM

Apr 14 2019

tychon added a comment to D19845: to be compatible with an IOMMU LinuxKPI should use bus_dma(9).

Also tested on an AMD Ryzen + Vega system, no regressions. (No IOMMU there because no one wrote a dmar equivalent for AMD IOMMU…)
btw, amdgpu touches dma_mask in one place, had to do this to fix build:

--- i/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
+++ w/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
@@ -366,7 +366,7 @@ void amdgpu_amdkfd_get_local_mem_info(struct kgd_dev *kgd,
                                      struct kfd_local_mem_info *mem_info)
 {
        struct amdgpu_device *adev = (struct amdgpu_device *)kgd;
-       uint64_t address_mask = adev->dev->dma_mask ? ~*adev->dev->dma_mask :
+       uint64_t address_mask = adev->dev->dma_priv ? ~*((uint64_t*)adev->dev->dma_priv) :
                                             ~((1ULL << 32) - 1);
        resource_size_t aper_limit = adev->gmc.aper_base + adev->gmc.aper_size;
Apr 14 2019, 2:26 PM
tychon added a comment to D19845: to be compatible with an IOMMU LinuxKPI should use bus_dma(9).

Tested on my Haswell laptop with drm-v5.0, everything works (both with DMAR on and off), this line is new in dmesg:

vgapci0: dmar0 pci0:0:2:0 rid 10 domain 0 mgaw 48 agaw 48 re-mapped

so it seems like the GPU is IOMMU'd. (full dmesg)

Apr 14 2019, 2:24 PM

Apr 12 2019

tychon committed rS346150: for a cache-only zone the destructor tries to destroy a non-existent keg.
for a cache-only zone the destructor tries to destroy a non-existent keg
Apr 12 2019, 12:46 PM
tychon closed D19835: for a cache-only zone the destructor tries to destroy a non-existent keg.
Apr 12 2019, 12:46 PM
tychon added inline comments to D19845: to be compatible with an IOMMU LinuxKPI should use bus_dma(9).
Apr 12 2019, 11:23 AM
tychon updated the diff for D19845: to be compatible with an IOMMU LinuxKPI should use bus_dma(9).

Incorporate a few more review comments: add missing BUS_DMA_NOWAIT flags to _bus_dmamap_load_phys() and optimize linux_dma_map_sg_attrs() to coalesce physically contiguous scatter list entries.

Apr 12 2019, 11:19 AM
tychon updated the diff for D19835: for a cache-only zone the destructor tries to destroy a non-existent keg.

Might a well make this as good as can be. I combined the tests into one.

Apr 12 2019, 11:02 AM

Apr 11 2019

tychon updated the diff for D19835: for a cache-only zone the destructor tries to destroy a non-existent keg.

Use markj@'s suggestion for a more overt/intuitive fix.

Apr 11 2019, 1:45 PM
tychon updated the summary of D19835: for a cache-only zone the destructor tries to destroy a non-existent keg.
Apr 11 2019, 1:43 PM
tychon added a comment to D19845: to be compatible with an IOMMU LinuxKPI should use bus_dma(9).

And just a heads-up these patches uncovered an issue with the cache-only zone destructor trying to destroy a non-existent keg. That's being worked in D19835.

Apr 11 2019, 1:30 PM
tychon updated the diff for D19845: to be compatible with an IOMMU LinuxKPI should use bus_dma(9).

Address further code review feedback: use non-sleepable allocs, fix weird formatting and add KASSERT(negs == 1).

Apr 11 2019, 1:25 PM

Apr 10 2019

tychon added inline comments to D19845: to be compatible with an IOMMU LinuxKPI should use bus_dma(9).
Apr 10 2019, 8:52 PM
tychon updated the diff for D19845: to be compatible with an IOMMU LinuxKPI should use bus_dma(9).

Addressed a few code review comments. There is a bit more work to do. Glancing at the feedback, I forgot 'assert that nseg == 1'. Plus I've got the optimization of gluing adjacent sg segments in the works too.

Apr 10 2019, 8:46 PM
tychon updated the diff for D19867: remove the 4GB boundary requirement on PCI DMA segments.

Get rid of PCI_DMA_BOUNDARY entirely.

Apr 10 2019, 1:32 PM

Apr 9 2019

tychon added reviewers for D19835: for a cache-only zone the destructor tries to destroy a non-existent keg: markj, jeff.
Apr 9 2019, 7:04 PM
tychon created D19867: remove the 4GB boundary requirement on PCI DMA segments.
Apr 9 2019, 7:03 PM
tychon updated the diff for D19845: to be compatible with an IOMMU LinuxKPI should use bus_dma(9).

No locking is provided internally by the path-compressed radix trie implementation. It worked shockingly well without until it didn't. Adding locking to make the LinuxKPI DMA routines MT-Safe.

Apr 9 2019, 1:29 PM
tychon committed rS346050: ioatcontrol(8) crc-copy flag bug and misc usage tweak.
ioatcontrol(8) crc-copy flag bug and misc usage tweak
Apr 9 2019, 10:33 AM
tychon closed D19855: ioatcontrol(8) crc-copy flag bug and misc usage tweak.
Apr 9 2019, 10:33 AM
tychon created D19855: ioatcontrol(8) crc-copy flag bug and misc usage tweak.
Apr 9 2019, 1:22 AM

Apr 8 2019

tychon updated the diff for D19845: to be compatible with an IOMMU LinuxKPI should use bus_dma(9).
Apr 8 2019, 7:17 PM
tychon added a comment to D19845: to be compatible with an IOMMU LinuxKPI should use bus_dma(9).

While trying to explain the design I realized that the UMA "linux_dma objects" zone doesn't need to be per-device. I can make that global.

Apr 8 2019, 5:52 PM
tychon updated the summary of D19845: to be compatible with an IOMMU LinuxKPI should use bus_dma(9).
Apr 8 2019, 5:50 PM
tychon added a reviewer for D19845: to be compatible with an IOMMU LinuxKPI should use bus_dma(9): hselasky.
Apr 8 2019, 3:06 PM
tychon created D19845: to be compatible with an IOMMU LinuxKPI should use bus_dma(9).
Apr 8 2019, 3:04 PM

Apr 5 2019

tychon added a reviewer for D19835: for a cache-only zone the destructor tries to destroy a non-existent keg: glebius.
Apr 5 2019, 11:56 PM
tychon created D19835: for a cache-only zone the destructor tries to destroy a non-existent keg.
Apr 5 2019, 11:55 PM

Apr 2 2019

tychon committed rS345813: ioat(4) should use bus_dma(9) for the operation source and destination.
ioat(4) should use bus_dma(9) for the operation source and destination
Apr 2 2019, 7:08 PM
tychon closed D19725: ioat(4) should use bus_dma(9) for the operation source and destination addresses to work properly with the VT-d IOMMU.
Apr 2 2019, 7:08 PM
tychon committed rS345812: ioatcontrol(8) could exercise 8k-aligned copy with page-break, crc and.
ioatcontrol(8) could exercise 8k-aligned copy with page-break, crc and
Apr 2 2019, 7:06 PM
tychon closed D19780: ioatcontrol(8) could exercise 8k-aligned copy with page-break, crc and crc-copy modes.
Apr 2 2019, 7:06 PM
tychon committed rS345811: DMAR driver assumes all physical addresses are backed by a fully.
DMAR driver assumes all physical addresses are backed by a fully
Apr 2 2019, 6:51 PM
tychon closed D19753: DMAR driver assumes all physical addresses are backed by a fully initialized struct vm_page.
Apr 2 2019, 6:51 PM
tychon added inline comments to D19753: DMAR driver assumes all physical addresses are backed by a fully initialized struct vm_page.
Apr 2 2019, 5:40 PM
tychon updated the diff for D19753: DMAR driver assumes all physical addresses are backed by a fully initialized struct vm_page.

I fixed the issues in the previous version which I should have taken more time to review myself before posting :-(

Apr 2 2019, 5:38 PM
tychon updated the diff for D19753: DMAR driver assumes all physical addresses are backed by a fully initialized struct vm_page.
Apr 2 2019, 4:46 PM
tychon added a comment to D19753: DMAR driver assumes all physical addresses are backed by a fully initialized struct vm_page.
In D19753#424464, @kib wrote:

Hm, sorry for following up immediately.
Can you change the patch slightly, to use the result of PHYS_TO_VM_PAGE() if it is usable ? In other words, only fill the missed slots in ma[].

Apr 2 2019, 4:45 PM
tychon added a comment to D19725: ioat(4) should use bus_dma(9) for the operation source and destination addresses to work properly with the VT-d IOMMU.

I think I've addressed at least many an attempt to address all outstanding feedback now. The diff is updated.

Apr 2 2019, 2:27 PM
tychon updated the diff for D19725: ioat(4) should use bus_dma(9) for the operation source and destination addresses to work properly with the VT-d IOMMU.
Apr 2 2019, 2:23 PM
tychon updated the diff for D19780: ioatcontrol(8) could exercise 8k-aligned copy with page-break, crc and crc-copy modes.
Apr 2 2019, 2:18 PM
tychon updated the diff for D19780: ioatcontrol(8) could exercise 8k-aligned copy with page-break, crc and crc-copy modes.

Add || TEST_DMA_8K_PB to pre-condition verification.

Apr 2 2019, 9:59 AM
tychon added a comment to D19780: ioatcontrol(8) could exercise 8k-aligned copy with page-break, crc and crc-copy modes.
In D19780#424304, @cem wrote:

arc-copy modes

typo: "crc-copy" (in the summary)
Looks mostly good to me. A few remarks:

Apr 2 2019, 1:09 AM
tychon updated the diff for D19780: ioatcontrol(8) could exercise 8k-aligned copy with page-break, crc and crc-copy modes.
Apr 2 2019, 1:09 AM
tychon retitled D19780: ioatcontrol(8) could exercise 8k-aligned copy with page-break, crc and crc-copy modes from ioatcontrol(8) could exercise 8k-aligned copy with page-break, crc and arc-copy modes to ioatcontrol(8) could exercise 8k-aligned copy with page-break, crc and crc-copy modes.
Apr 2 2019, 1:04 AM
tychon updated the diff for D19725: ioat(4) should use bus_dma(9) for the operation source and destination addresses to work properly with the VT-d IOMMU.

This revision includes setups up the '48-bit' DMA address constraint for the 'data' tag and the '40-bit' DMA address constraint for the 'crc data' tag.

Apr 2 2019, 12:57 AM

Apr 1 2019

tychon created D19780: ioatcontrol(8) could exercise 8k-aligned copy with page-break, crc and crc-copy modes.
Apr 1 2019, 7:38 PM
tychon added inline comments to D19725: ioat(4) should use bus_dma(9) for the operation source and destination addresses to work properly with the VT-d IOMMU.
Apr 1 2019, 7:16 PM
tychon updated the diff for D19725: ioat(4) should use bus_dma(9) for the operation source and destination addresses to work properly with the VT-d IOMMU.
Apr 1 2019, 7:11 PM
tychon committed rS345777: Devices behind downstream bridges should still get DMAR protection..
Devices behind downstream bridges should still get DMAR protection.
Apr 1 2019, 7:08 PM
tychon closed D19717: devices behind downstream bridges should still get DMAR protection.
Apr 1 2019, 7:08 PM
tychon added a comment to D19753: DMAR driver assumes all physical addresses are backed by a fully initialized struct vm_page.
In D19753#423602, @kib wrote:

I do not like it. If we always pass ficitious pages, we do not need to pass pages at all, we can get away with physical address only. But I do want to have pages there for several reasons.
I do have the same problem on my bhyve integration branch, but there I do the following:

diff --git a/sys/vm/vm_page.c b/sys/vm/vm_page.c
index a90a6f805b7..1f9d266ba7e 100644
--- a/sys/vm/vm_page.c
+++ b/sys/vm/vm_page.c
@@ -557,7 +557,7 @@ vm_page_startup(vm_offset_t vaddr)
 #ifdef WITNESS
 	int witness_size;
 #endif
-#if defined(__i386__) && defined(VM_PHYSSEG_DENSE)
+#if (defined(__i386__) || defined(__amd64__)) && defined(VM_PHYSSEG_DENSE)
 	long ii;
 #endif
@@ -800,7 +800,11 @@ vm_page_startup(vm_offset_t vaddr)
 	 * Initialize the page structures and add every available page to the
 	 * physical memory allocator's free lists.
 	 */
-#if defined(__i386__) && defined(VM_PHYSSEG_DENSE)
+#if (defined(__i386__) || defined(__amd64__)) && defined(VM_PHYSSEG_DENSE)
+	/*
+	 * i386 needs this for copyout(9) calling vm_fault_quick_hold_pages().
+	 * amd64 requires that for DMAR busdma and bhyve IOMMU.
+	 */
 	for (ii = 0; ii < vm_page_array_size; ii++) {
 		m = &vm_page_array[ii];
 		vm_page_init_page(m, (first_page + ii) << PAGE_SHIFT, 0);

As a temporal solution, you might consider using fake pages only for addresses where PHYS_TO_VM_PAGE() failed.

Apr 1 2019, 2:50 PM
tychon updated the diff for D19753: DMAR driver assumes all physical addresses are backed by a fully initialized struct vm_page.
Apr 1 2019, 2:45 PM

Mar 29 2019

tychon created D19753: DMAR driver assumes all physical addresses are backed by a fully initialized struct vm_page.
Mar 29 2019, 5:30 PM

Mar 28 2019

tychon added a comment to D19729: use the BUS_DMA_NOWRITE flag to expose and create the read-only VT-d IOMMU mappings.
In D19729#422870, @kib wrote:

Since the PCI Express endpoint and associated data paths are synthesized on the FPGA they have a larger than average vulnerability to SEUs. Hence we want to limit the "aperture" by which the DMA/bridge can scribble on memory if things go awry. That's done both by constraining access with the IOMMU and even with that limiting write-only access (using the BUS_DMA_NOWRITE) to bus_dmamap_load()) even further.

Do you enable busdma DMAR for everything, or limit the scope to the fpga device only ? If the later, do you use hw.busdma.pciX.X.X.X tunables to control that, or have something more involved ?

Mar 28 2019, 6:20 PM
tychon added a comment to D19729: use the BUS_DMA_NOWRITE flag to expose and create the read-only VT-d IOMMU mappings.
In D19729#422742, @kib wrote:
In D19729#422689, @kib wrote:

The flag is only supported by sparc64, and there is no single use of it in the tree.

Indeed there is no current in tree user. It is however used outside of the tree in conjunction with a Mellanox Innova-2 card. Plus, once in tree anyone is free to use and it will no longer be sparc64 only :-)

I am curious. Is this some private code to communicate with FPGA ? (Because I know both busdma dmar and in-tree ml5_fpga too closely).

Mar 28 2019, 1:30 AM

Mar 27 2019

tychon committed rS345601: Use the BUS_DMA_NOWRITE flag to expose and create the read-only VT-d.
Use the BUS_DMA_NOWRITE flag to expose and create the read-only VT-d
Mar 27 2019, 8:16 PM
tychon closed D19729: use the BUS_DMA_NOWRITE flag to expose and create the read-only VT-d IOMMU mappings.
Mar 27 2019, 8:16 PM