Re: [PATCH] use unfair spinlock when running on hypervisor.

that ppc64 handles it -- on a machine with overcommitted virtual cpus, it will call __spin_yield (arch/powerpc/lib/locks.c) on contention, which may cause the virtual CPU to donate its hypervisor timeslice to the vCPU which is actually holding the lock in question. -- David Woodhouse

Re: [2.6 patch] remove dummy asm/kvm.h files

On Tue, 2008-07-01 at 21:32 +0200, Sam Ravnborg wrote: On Tue, Jul 01, 2008 at 07:27:16PM +0300, Adrian Bunk wrote: This patch removes the dummy asm/kvm.h files on architectures not (yet) supporting KVM and uses the same conditional headers installation as already used for a.out.h .

Re: [PATCH 1/2] VT-d: Changes to support KVM

that it might make sense to set up such a tree. -- David WoodhouseOpen Source Technology Centre [EMAIL PROTECTED] Intel Corporation -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL

Re: [PATCHSETS #2] KVM device passthrough support with AMD IOMMU

On Wed, 2008-12-10 at 19:42 +0100, Joerg Roedel wrote: Ok, I add it, thanks. Who is the author, Mike or you? Might as well attribute it to Mike; he spotted it. -- dwmw2 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo

Re: [PATCH] VT-d: fix PCI device detach from virtual machine

On Thu, 2009-02-26 at 17:31 +0800, Han, Weidong wrote: When assign a device behind conventional PCI bridge or PCIe to PCI/PCI-x bridge to a domain, it must assign its bridge and may also need to assign secondary interface to the same domain. Dependent assignment is already there, but

Re: [PATCH] VT-d: fix PCI device detach from virtual machine

On Tue, 2010-06-15 at 16:10 +0200, Joerg Roedel wrote: On Mon, Jun 14, 2010 at 07:19:17PM -0400, David Woodhouse wrote: Why not just jump straight to the 'DMA proxy' device, and use that _only_? Not sure about Intel chipsets, but on AMD chipset a legacy device can be seen by the IOMMU

Re: [PATCH] VT-d: fix PCI device detach from virtual machine

On Thu, 2010-06-17 at 11:35 +0800, Weidong Han wrote: David Woodhouse wrote: So why do we bother setting up a context in the IOMMU for the device itself, when no DMA will ever appear to come from this device? And if the device is behind PCI Express-to-PCI/PCI-X bridge, the source-id

Re: [PATCH] intel-iommu: Fix reference by physical address in intel_iommu_attach_device()

On Thu, 2010-06-17 at 18:10 +0800, Sheng Yang wrote: BTW: I think this need to be queued for 2.6.35-rc as well. I sent Linus the pull request yesterday. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel

Re: [PATCH 04/11] VT-d: Change {un}map_range functions to implement {un}map interface

not a page-size based interface. Page size isn't always 4KiB; this code runs on IA64 too. We have enough fun with CPU vs. DMA page size on IA64 already :) -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation

Re: [PATCH v2 1/6] PCI: support the ATS capability

the whole lot through my iommu tree. OK? -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord

Re: [PATCH v5 6/6] VT-d: support the device IOTLB

) || did) ? Either way, it wants a comment. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord

Re: [PATCH v5 6/6] VT-d: support the device IOTLB

for domains which have ATS-capable devices attached. How about using a flag similar to iommu_snooping, which is recalculated only when you add or remove a device? And only calling iommu_flush_dev_iotlb() if that's set? -- David WoodhouseOpen Source Technology Centre

Re: [PATCH v5 6/6] VT-d: support the device IOTLB

device that supports it, and ignore the others? -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord

Re: [PATCH v4 resend 5/6] VT-d: cleanup iommu_flush_iotlb_psi and flush_unmaps

On Thu, 2009-05-14 at 10:32 +0800, Yu Zhao wrote: Make iommu_flush_iotlb_psi() and flush_unmaps() more readable. This doesn't apply any more. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation

Re: [PATCH v4 2/7] iommu/core: split mapping to page sizes as supported by the hardware

On Thu, 2011-11-10 at 14:17 +0800, Kai Huang wrote: And another question: have we considered the IOTLB flush operation? I think we need to implement similar logic when flush the DVMA range. Intel VT-d's manual says software needs to specify the appropriate mask value to flush large pages, but

Re: [PATCH v4 2/7] iommu/core: split mapping to page sizes as supported by the hardware

On Thu, 2011-11-10 at 18:09 +0100, Joerg Roedel wrote: The requirement for the DMA-API is, that the IOTLB must be consistent with existing mappings, and only with the parts that are really mapped. The unmapped parts are not important. This allows nice optimizations like your 'batched unmap'

Re: [PATCH v4 2/7] iommu/core: split mapping to page sizes as supported by the hardware

On Fri, 2011-11-11 at 13:58 +0100, Joerg Roedel wrote: For AMD IOMMU there is a feature called not-present cache. It says that the IOMMU caches non-present entries as well and needs an IOTLB flush when something is mapped (meant for software implementations of the IOMMU). So it can't be

RE: [PATCH v2] intel-iommu: Add device info into list before doing context mapping

On Fri, 2012-03-23 at 02:54 +, Hao, Xudong wrote: Any other comments for this patch? Or can you check-in it in your iommu tree? Apologies for the delayed response. I've just forwarded this to Linus. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature

Re: [PATCH v2] intel-iommu: Fix use after release during device attach

On Thu, 2011-04-21 at 15:28 +0100, Alex Williamson wrote: I've been wondering the exact same thing. My last patch took weeks of prodding, finally went into the maintainer's tree without acknowledgment, and there's hardly been any activity there to suggest a pull request for 2.6.39 is going to

[RFC][PATCH] Fix superpage unmap on Intel IOMMU

; + dma_pte_clear_range(dmar_domain, iova VTD_PAGE_SHIFT, (iova + size - 1) VTD_PAGE_SHIFT); -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- To unsubscribe from

Re: [RFC][PATCH] Fix superpage unmap on Intel IOMMU

On Fri, 2011-06-03 at 20:31 +0100, David Woodhouse wrote: + size = PAGE_SIZE gfp_order; Just realised it needs an extra 9 in there somewhere, if you actually wanted to test it (Allen). I think I'd prefer to fix the KVM code instead, though. -- dwmw2 -- To unsubscribe from

Re: [RFC][PATCH] Fix superpage unmap on Intel IOMMU

On Fri, 3 Jun 2011, Alex Williamson wrote: On Fri, 2011-06-03 at 20:31 +0100, David Woodhouse wrote: Tell me it isn't so... Looks accurate to me, in fact, with hugetlbfs it seems like it's doing exactly what it should do. The non-hugetlbfs case isn't efficient, but it isn't wrong either

Re: Seeing DMAR errors after multiple load/unload with SR-IOV

On Tue, 2011-06-07 at 06:38 -0700, Chris Wright wrote: I think we still leak the list entry though. Bottom line is that we need to handle hotplug ADD_DEVICE and DEL_DEVICE notifications. We happen to pick up ADD_DEVICE by accident, but it's all pretty sloppy. Yeah, keeping a list of

Re: Seeing DMAR errors after multiple load/unload with SR-IOV

On Tue, 2011-06-07 at 08:10 -0700, Chris Wright wrote: * David Woodhouse (dw...@infradead.org) wrote: On Tue, 2011-06-07 at 06:38 -0700, Chris Wright wrote: I think we still leak the list entry though. Bottom line is that we need to handle hotplug ADD_DEVICE and DEL_DEVICE notifications

Re: [PATCH 0/2] Introduce iommu_commit() function

On Thu, 2011-06-23 at 17:31 +0200, Joerg Roedel wrote: David, I think especially VT-d can benefit from such a callback. I will implement support for it in the AMD IOMMU driver and post a patch-set soon. Any comments, thoughts? Ick. We *already* do the flushes as appropriate while we're

Re: [SeaBIOS] KVM call agenda for 2013-05-28

On Wed, 2013-05-29 at 11:18 -0500, Anthony Liguori wrote: Certainly an option, but that is a long-term project. Out of curiousity, are there other benefits to using coreboot as a core firmware in QEMU? Is there a payload we would ever plausibly use besides OVMF and SeaBIOS? I like the

Re: [Qemu-devel] [SeaBIOS] KVM call agenda for 2013-05-28

On Thu, 2013-05-30 at 13:13 +0200, Laszlo Ersek wrote: Where is CorebootPkg available from? https://github.com/pgeorgi/edk2/tree/coreboot-pkg And it helps to dispel the stupid misconception in some quarters that Coreboot *competes* with UEFI and thus cannot possibly be supported because

Re: [Qemu-devel] [SeaBIOS] KVM call agenda for 2013-05-28

On Thu, 2013-05-30 at 09:20 -0700, Jordan Justen wrote: On Thu, May 30, 2013 at 5:19 AM, David Woodhouse dw...@infradead.org wrote: On Thu, 2013-05-30 at 13:13 +0200, Laszlo Ersek wrote: Where is CorebootPkg available from? https://github.com/pgeorgi/edk2/tree/coreboot-pkg

Re: [SeaBIOS] KVM call agenda for 2013-05-28

On Wed, 2013-05-29 at 21:12 -0400, Kevin O'Connor wrote: I remain doubtful that QOM has all the info needed to generate the BIOS tables. Does QOM describe how the 5th pci device uses global interrupt 11 when using global interrupts, legacy interrupt 5 when not using global interrupts, and

Re: KVM call agenda for 2013-05-28

On Fri, 2013-05-31 at 07:58 -0500, Anthony Liguori wrote: What about a small change to the SeaBIOS build system to allow ACPI table generation to be done via a plugin. SeaBIOS already accepts ACPI tables from Coreboot or UEFI, and queries them to find things that it needs. This could be as

Re: KVM call agenda for 2013-05-28

On Fri, 2013-05-31 at 08:04 -0500, Anthony Liguori wrote: soapbox Fork OVMF, drop the fat module, and just add GPL code. It's an easily solvable problem. Heh. Actually it doesn't need to be a fork. It's modular, and the FAT driver is just a single module. Which is actually included in

Re: KVM call agenda for 2013-05-28

On Fri, 2013-05-31 at 10:43 -0500, Anthony Liguori wrote: It's even more fundamental. OVMF as a whole (at least in it's usable form) is not Open Source. The FAT module is required to make EDK2 usable, and yes, that's not Open Source. So in a sense you're right. But we're talking here about

Re: [edk2] apparent KVM problem with LRET in TianoCore S3 resume trampoline

On Thu, 2013-12-05 at 23:38 +0100, Laszlo Ersek wrote: Does gas support mode switches in one file? I found examples on the net (for nasm I think) where people were thunking to real mode and back to protected mode in a single assembly file, and they could use native mnemonics for each part.

Re: [v3 06/26] iommu, x86: No need to migrating irq for VT-d Posted-Interrupts

, and the migration happens during vCPU scheduling. However, we still update the cached irte here, which can be used when changing back to remapping mode. Signed-off-by: Feng Wu feng...@intel.com Reviewed-by: Jiang Liu jiang@linux.intel.com Acked-by: David Woodhouse david.woodho

Re: [v3 26/26] iommu/vt-d: Add a command line parameter for VT-d posted-interrupts

On Fri, 2014-12-12 at 23:15 +0800, Feng Wu wrote: Enable VT-d Posted-Interrtups and add a command line parameter for it. Signed-off-by: Feng Wu feng...@intel.com Acked-by: David Woodhouse david.woodho...@intel.com -- David WoodhouseOpen Source Technology Centre

Re: [v3 04/26] iommu, x86: Implement irq_set_vcpu_affinity for intel_ir_chip

On Fri, 2014-12-12 at 23:14 +0800, Feng Wu wrote: Implement irq_set_vcpu_affinity for intel_ir_chip. Signed-off-by: Feng Wu feng...@intel.com Reviewed-by: Jiang Liu jiang@linux.intel.com Acked-by: David.Woodhouse david.woodho...@intel.com assuming a suitable answer to... +

Re: [v3 03/26] iommu, x86: Define new irte structure for VT-d Posted-Interrupts

along with the other patches rather than through me, and I'm happy for it to do so. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation smime.p7s Description: S/MIME cryptographic signature

Re: [v3 02/26] iommu: Add new member capability to struct irq_remap_ops

(*capability)(enum irq_remap_cap); + Does this need to be a function call? Or could we just have a set of flags in the irq_remap_ops instead, with less overhead to check them? -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com

Re: [v3 07/26] iommu, x86: Add cap_pi_support() to detect VT-d PI capability

On Fri, 2014-12-12 at 23:14 +0800, Feng Wu wrote: Add helper function to detect VT-d Posted-Interrupts capability. Signed-off-by: Feng Wu feng...@intel.com Reviewed-by: Jiang Liu jiang@linux.intel.com Acked-by: David Woodhouse david.woodho...@intel.com -- David Woodhouse

Re: [v3 08/26] iommu, x86: Add intel_irq_remapping_capability() for Intel

which doesn't support posted interrupts, what happens? -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation smime.p7s Description: S/MIME cryptographic signature

Re: [PATCH v1 2/2] dma-mapping-common: add DMA attribute - DMA_ATTR_IOMMU_BYPASS

On Wed, 2015-10-28 at 13:10 +0200, Shamir Rabinovitch wrote: > On Wed, Oct 28, 2015 at 03:30:01PM +0900, David Woodhouse wrote: > > > > +For systems with IOMMU it is assumed all DMA translations use the > > > > IOMMU. > > > > Not entirely true. We have per

Re: [PATCH v3 0/3] virtio DMA API core stuff

On Wed, 2015-10-28 at 13:35 +0200, Michael S. Tsirkin wrote: > E.g. on intel x86, there's an option iommu=pt which does the 1:1 > thing for devices when used by kernel, but enables > the iommu if used by userspace/VMs. That's none of your business. You call the DMA API when you do DMA. That's

Re: [PATCH v3 0/3] virtio DMA API core stuff

On Wed, 2015-10-28 at 13:23 +0200, Michael S. Tsirkin wrote: > On Wed, Oct 28, 2015 at 05:36:53PM +0900, Benjamin Herrenschmidt > wrote: > > On Wed, 2015-10-28 at 16:40 +0900, Christian Borntraeger wrote: > > > We have discussed that at kernel summit. I will try to implement > > > a dummy dma_ops

Re: [PATCH v1 2/2] dma-mapping-common: add DMA attribute - DMA_ATTR_IOMMU_BYPASS

On Wed, 2015-10-28 at 07:07 -0700, David Miller wrote: > In the sparc64 case, the 64-bit DMA address space is divided into > IOMMU translated and non-IOMMU translated. > > You just set the high bits differently depending upon what you want. Wait, does that mean a (rogue) device could *always*

Re: [PATCH v3 0/3] virtio DMA API core stuff

On Wed, 2015-10-28 at 16:05 +0200, Michael S. Tsirkin wrote: > > Short answer - platforms need a way to discover, and express different > security requirements of different devices. Sure. PLATFORMS need that. Do not let it go anywhere near your device drivers. Including the virtio drivers. > If

Re: [PATCH v3 0/3] virtio DMA API core stuff

On Wed, 2015-10-28 at 16:22 +0200, Michael S. Tsirkin wrote: > On Wed, Oct 28, 2015 at 11:13:29PM +0900, David Woodhouse wrote: > > On Wed, 2015-10-28 at 16:05 +0200, Michael S. Tsirkin wrote: > > > > > > Short answer - platforms need a way to discover, and express >

Re: [PATCH v3 0/3] virtio DMA API core stuff

On Thu, 2015-10-29 at 11:01 +0200, Michael S. Tsirkin wrote: > > Example: you have a mix of assigned devices and virtio devices. You > don't trust your assigned device vendor not to corrupt your memory so > you want to limit the damage your assigned device can do to your > guest, > so you use an

Re: [PATCH v1 2/2] dma-mapping-common: add DMA attribute - DMA_ATTR_IOMMU_BYPASS

On Thu, 2015-10-29 at 11:31 -0700, Andy Lutomirski wrote: > On Oct 28, 2015 6:11 PM, "Benjamin Herrenschmidt" > <b...@kernel.crashing.org> wrote: > > > > On Thu, 2015-10-29 at 09:42 +0900, David Woodhouse wrote: > > > On Thu, 2015-10-29 a

Re: [PATCH 3/3] virtio_pci: Use the DMA API

On Wed, 2015-10-28 at 11:15 +0900, Joerg Roedel wrote: > On Tue, Oct 27, 2015 at 06:17:10PM -0700, Andy Lutomirski wrote: > > From: Andy Lutomirski > > > > This fixes virtio-pci on platforms and busses that have IOMMUs. > > This > > will break the experimental QEMU Q35

Re: [PATCH v1 2/2] dma-mapping-common: add DMA attribute - DMA_ATTR_IOMMU_BYPASS

On Sun, 2015-10-25 at 09:07 -0700, Shamir Rabinovitch wrote: > > + > +DMA_ATTR_IOMMU_BYPASS > +- > + > > +For systems with IOMMU it is assumed all DMA translations use the IOMMU. Not entirely true. We have per-device dma_ops on a most architectures already, and we were just

Re: [PATCH v3 0/3] virtio DMA API core stuff

On Tue, 2015-10-27 at 23:38 -0700, Andy Lutomirski wrote: > > Changes from v2: > - Fix really embarrassing bug. This version actually works. So embarrassing you didn't want to tell us what it was? ... --- a/drivers/virtio/virtio_ring.c +++ b/drivers/virtio/virtio_ring.c @@ -292,7 +292,7 @@

Re: [PATCH v2 2/3] virtio_ring: Support DMA APIs

On Wed, 2015-10-28 at 14:52 +0900, Christian Borntraeger wrote: >0059b25a: e3201024 lg %r2,32(%r1) > #0059b260: e310b0a4 lg %r1,160(%r11) > >0059b266: 4810100c lh %r1,12(%r1) Precisely what is

Re: [PATCH v3 0/3] virtio DMA API core stuff

On Wed, 2015-10-28 at 16:40 +0900, Christian Borntraeger wrote: > Am 28.10.2015 um 16:17 schrieb Michael S. Tsirkin: > > On Tue, Oct 27, 2015 at 11:38:57PM -0700, Andy Lutomirski wrote: > > > This switches virtio to use the DMA API unconditionally. I'm sure > > > it breaks things, but it seems to

Re: [PATCH v1 2/2] dma-mapping-common: add DMA attribute - DMA_ATTR_IOMMU_BYPASS

On Thu, 2015-10-29 at 09:32 +0900, Benjamin Herrenschmidt wrote: > On Power, I generally have 2 IOMMU windows for a device, one at the > bottom is remapped, and is generally used for 32-bit devices and the > one at the top us setup as a bypass So in the normal case of decent 64-bit devices (and

Re: [PATCH v3 0/3] virtio DMA API core stuff

On Sun, 2015-11-08 at 12:37 +0200, Michael S. Tsirkin wrote: > On Thu, Oct 29, 2015 at 05:18:56PM +0100, David Woodhouse wrote: > > On Thu, 2015-10-29 at 11:01 +0200, Michael S. Tsirkin wrote: > > > > > > But you trust your hypervisor (you have no choice anyway

Re: [PATCH v3 0/3] virtio DMA API core stuff

On Thu, 2015-11-12 at 13:09 +0200, Michael S. Tsirkin wrote: > On Wed, Nov 11, 2015 at 11:30:27PM +0100, David Woodhouse wrote: > > > > If the IOMMU is exposed, and enabled, and telling the guest kernel that > > it *does* cover the virtio devices, then

Re: [PATCH v1 2/2] dma-mapping-common: add DMA attribute - DMA_ATTR_IOMMU_BYPASS

st of the page walk can be amortised in some cases — you can look up the physical address *before* you are ready to actually start the DMA to it, and don't take that latency at the time you're actually moving the data. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation smime.p7s Description: S/MIME cryptographic signature

Re: [PATCH v3 0/3] virtio DMA API core stuff

On Wed, 2015-11-11 at 07:56 -0800, Andy Lutomirski wrote: > > Can you flesh out this trick? > > On x86 IIUC the IOMMU more-or-less defaults to passthrough. If the > kernel wants, it can switch it to a non-passthrough mode. My patches > cause the virtio driver to do exactly this, except that

Re: [PATCH v1 2/2] dma-mapping-common: add DMA attribute - DMA_ATTR_IOMMU_BYPASS

On Mon, 2015-11-02 at 08:10 +1100, Benjamin Herrenschmidt wrote: > On Sun, 2015-11-01 at 09:45 +0200, Shamir Rabinovitch wrote: > > Not sure this use case is possible for Infiniband where application hold > > the data buffers and there is no way to force application to re use the > > buffer as

Re: [PATCH v3 0/3] virtio DMA API core stuff

(Sorry, missed part of this before). On Thu, 2015-10-29 at 11:01 +0200, Michael S. Tsirkin wrote: > Isn't this specified by the hypervisor? I don't think this is a good > way to do this: guest security should be up to guest. And it is. When the guest sees an IOMMU, it can choose to use it, or

[PATCH] Fix AF_PACKET ABI breakage in 4.2

ro and use that throughout the code instead of the hard-coded 'false' for little-endian. This restores the ABI to match 4.1 and earlier kernels, and makes my test program work again. Signed-off-by: David Woodhouse <david.woodho...@intel.com> --- Or perhaps we should just use (__force u

Re: [PATCH v2] Fix AF_PACKET ABI breakage in 4.2

e with me. If I'm going to define my own accessors, I'd probably just make them use (__force __virtio16). But TBH none of the options seemed particularly pretty to me. I can live with what we have. -- David WoodhouseOpen Source Technology Centre d

[PATCH v2] Fix AF_PACKET ABI breakage in 4.2

ro and use that throughout the code instead of the hard-coded 'false' for little-endian. This restores the ABI to match 4.1 and earlier kernels, and makes my test program work again. Signed-off-by: David Woodhouse <david.woodho...@intel.com> --- On Wed, 2015-09-23 at 11:09 -0700, Da

Re: [PATCH v3 0/3] virtio DMA API core stuff

On Thu, 2015-11-19 at 13:59 -0800, Andy Lutomirski wrote: > > > > > So thinking hard about it, I don't see any real drawbacks to making this > > conditional on a new feature bit, that Xen can then set.. > > Can you elaborate?  If I run QEMU, hosting Xen, hosting Linux, and the > virtio device is

Re: [PATCH v3 0/3] virtio DMA API core stuff

> There's that, and there's an "I care about security, but > do not want to burn up cycles on fake protections that > do not work" case. It would seem to make most sense for this use case simply *not* to expose virtio devices to guests as being behind an IOMMU at all. Sure, there are esoteric

Re: [PATCH v3 0/3] virtio DMA API core stuff

> There's that, and there's an "I care about security, but > do not want to burn up cycles on fake protections that > do not work" case. It would seem to make most sense for this use case simply *not* to expose virtio devices to guests as being behind an IOMMU at all. Sure, there are esoteric

Re: [PATCH v3 0/3] virtio DMA API core stuff

On Sun, 2015-11-22 at 15:06 +0200, Marcel Apfelbaum wrote: > > > I tried to generate a DMAR table that excludes some devices from > IOMMU translation, however it does not help. > > The reason is, as far as I understand, that Linux kernel does > not allow any device being outside an IOMMU scope

Re: [PATCH v3 0/3] virtio DMA API core stuff

On Fri, 2015-11-20 at 10:21 +0200, Michael S. Tsirkin wrote: > > David, there are two things a hypervisor needs to tell the guest. > 1. The actual device is behind an IOMMU. This is what you >    are suggesting we use DMAR for. > 2. Using IOMMU from kernel (as opposed to from userspace with VFIO)