Re: [PATCH v3 3/4] arm64: Add IOMMU dma_ops
On Fri, Jul 10, 2015 at 08:19:34PM +0100, Robin Murphy wrote:
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index d16a1ce..ccadfd4 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -526,3 +526,426 @@ static int __init dma_debug_do_init(void)
return 0;
}
fs_initcall(dma_debug_do_init);
+
+
+#ifdef CONFIG_IOMMU_DMA
+#include linux/dma-iommu.h
+#include linux/platform_device.h
+#include linux/amba/bus.h
+
+/* Thankfully, all cache ops are by VA so we can ignore phys here */
+static void flush_page(const void *virt, phys_addr_t phys)
+{
+ __dma_flush_range(virt, virt + PAGE_SIZE);
+}
+
+static void *__iommu_alloc_attrs(struct device *dev, size_t size,
+ dma_addr_t *handle, gfp_t gfp,
+ struct dma_attrs *attrs)
+{
+ bool coherent = is_device_dma_coherent(dev);
+ int ioprot = dma_direction_to_prot(DMA_BIDIRECTIONAL, coherent);
+ void *addr;
+
+ if (WARN(!dev, cannot create IOMMU mapping for unknown device\n))
+ return NULL;
+
+ if (gfp __GFP_WAIT) {
+ struct page **pages;
+ pgprot_t pgprot = coherent ? __pgprot(PROT_NORMAL) :
+ __pgprot(PROT_NORMAL_NC);
+
+ pgprot = __get_dma_pgprot(attrs, pgprot, coherent);
+ pages = iommu_dma_alloc(dev, size, gfp, ioprot, coherent,
+ handle, coherent ? NULL : flush_page);
As I replied already on the other patch, the coherent argument here
should always be true.
BTW, why do we need to call flush_page via iommu_dma_alloc() and not
flush the buffer directly in the arch __iommu_alloc_attrs()? We already
have the pointer and size after remapping in the CPU address space), it
would keep the iommu_dma_alloc() simpler.
+ if (!pages)
+ return NULL;
+
+ addr = dma_common_pages_remap(pages, size, VM_USERMAP, pgprot,
+ __builtin_return_address(0));
+ if (!addr)
+ iommu_dma_free(dev, pages, size, handle);
+ } else {
+ struct page *page;
+ /*
+ * In atomic context we can't remap anything, so we'll only
+ * get the virtually contiguous buffer we need by way of a
+ * physically contiguous allocation.
+ */
+ if (coherent) {
+ page = alloc_pages(gfp, get_order(size));
+ addr = page ? page_address(page) : NULL;
We could even use __get_free_pages(gfp ~__GFP_HIGHMEM) since we don't
have/need highmem on arm64.
+ } else {
+ addr = __alloc_from_pool(size, page, gfp);
+ }
+ if (addr) {
+ *handle = iommu_dma_map_page(dev, page, 0, size,
+ ioprot, false);
Why coherent == false?
+ if (iommu_dma_mapping_error(dev, *handle)) {
+ if (coherent)
+ __free_pages(page, get_order(size));
+ else
+ __free_from_pool(addr, size);
+ addr = NULL;
+ }
+ }
+ }
+ return addr;
+}
In the second case here (!__GFP_WAIT), do we do any cache maintenance? I
can't see it and it's needed for the !coherent case.
+static void __iommu_free_attrs(struct device *dev, size_t size, void
*cpu_addr,
+dma_addr_t handle, struct dma_attrs *attrs)
+{
+ /*
+ * @cpu_addr will be one of 3 things depending on how it was allocated:
+ * - A remapped array of pages from iommu_dma_alloc(), for all
+ * non-atomic allocations.
+ * - A non-cacheable alias from the atomic pool, for atomic
+ * allocations by non-coherent devices.
+ * - A normal lowmem address, for atomic allocations by
+ * coherent devices.
+ * Hence how dodgy the below logic looks...
+ */
+ if (__free_from_pool(cpu_addr, size)) {
+ iommu_dma_unmap_page(dev, handle, size, 0, NULL);
+ } else if (is_vmalloc_addr(cpu_addr)){
+ struct vm_struct *area = find_vm_area(cpu_addr);
+
+ if (WARN_ON(!area || !area-pages))
+ return;
+ iommu_dma_free(dev, area-pages, size, handle);
+ dma_common_free_remap(cpu_addr, size, VM_USERMAP);
+ } else {
+ __free_pages(virt_to_page(cpu_addr), get_order(size));
+ iommu_dma_unmap_page(dev, handle, size, 0, NULL);
Just slightly paranoid but it's better to unmap the page from the iommu
space before freeing (in case there is some rogue device still accessing
it).
--
Catalin
Re: [PATCH v3 3/4] arm64: Add IOMMU dma_ops
On Wed, Jul 15, 2015 at 05:27:22PM +0100, Robin Murphy wrote:
On 15/07/15 10:31, Catalin Marinas wrote:
On Fri, Jul 10, 2015 at 08:19:34PM +0100, Robin Murphy wrote:
+ if (iommu_dma_mapping_error(dev, *handle)) {
+ if (coherent)
+ __free_pages(page, get_order(size));
+ else
+ __free_from_pool(addr, size);
+ addr = NULL;
+ }
+ }
+ }
+ return addr;
+}
In the second case here (!__GFP_WAIT), do we do any cache maintenance? I
can't see it and it's needed for the !coherent case.
In the atomic non-coherent case, we're stealing from the atomic pool, so
addr is already a non-cacheable alias (and alloc_from_pool does memset(0)
through that). That shouldn't need anything extra, right?
You are right, we already flushed the cache for the atomic pool when we
allocated it in atomic_pool_init().
--
Catalin
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC 0/6] vSMMU initialization
On Wed, Jul 15, 2015 at 06:28:54PM +0100, Varun Sethi wrote: On Fri, Jun 12, 2015 at 03:20:04PM +0100, Baptiste Reynal wrote: The ARM SMMU has support for 2-stages address translations, allowing a virtual address to be translated at two levels: - Stage 1 translates a virtual address (VA) into an intermediate physical address (IPA) - Stage 2 translates an IPA into a physical address (PA) Will Deacon introduced a virtual SMMU interface for KVM, which gives a virtual machine the possibility to use an IOMMU with native drivers. While the VM will program the first stage of translation (stage 1), the interface will program the second (stage 2) on the physical SMMU. Please note that I have no plans to merge the kernel-side of this at the moment. It was merely an exploratory tool to see what a non-PV vSMMU implementation might look like and certainly not intended to be used in anger. How do you see the context fault reporting work for the PV interface? We could have an interrupt, for the PV IOMMU and have the hypervisor inject that, no? Can you please elaborate on the PV IOMMU interface. I want to understand how context fault information would be communicated to the guest. I replied to this the other day! My assumption is that we'd have an irq and some memory region to describe the fault in as general a way as possible. Whether that memory region looks like MMIO registers or something like a virtio ring buffer is an implementation detail to be resolved by prototyping. Will ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [RFC 0/6] vSMMU initialization
Hi Will, -Original Message- From: Will Deacon [mailto:will.dea...@arm.com] Sent: Tuesday, July 14, 2015 4:34 PM To: Sethi Varun-B16395 Cc: Baptiste Reynal; iommu@lists.linux-foundation.org; t...@virtualopensystems.com; qemu-de...@nongnu.org Subject: Re: [RFC 0/6] vSMMU initialization On Tue, Jul 14, 2015 at 03:21:03AM +0100, Varun Sethi wrote: Hi Will, Hi Varun, On Fri, Jun 12, 2015 at 03:20:04PM +0100, Baptiste Reynal wrote: The ARM SMMU has support for 2-stages address translations, allowing a virtual address to be translated at two levels: - Stage 1 translates a virtual address (VA) into an intermediate physical address (IPA) - Stage 2 translates an IPA into a physical address (PA) Will Deacon introduced a virtual SMMU interface for KVM, which gives a virtual machine the possibility to use an IOMMU with native drivers. While the VM will program the first stage of translation (stage 1), the interface will program the second (stage 2) on the physical SMMU. Please note that I have no plans to merge the kernel-side of this at the moment. It was merely an exploratory tool to see what a non-PV vSMMU implementation might look like and certainly not intended to be used in anger. How do you see the context fault reporting work for the PV interface? We could have an interrupt, for the PV IOMMU and have the hypervisor inject that, no? Can you please elaborate on the PV IOMMU interface. I want to understand how context fault information would be communicated to the guest. -Varun ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3 2/4] iommu: Implement common IOMMU ops for DMA mapping
Hi Catalin,
Thanks for the review.
On 14/07/15 18:16, Catalin Marinas wrote:
On Fri, Jul 10, 2015 at 08:19:33PM +0100, Robin Murphy wrote:
+/*
+ * IOVAs are IOMMU _input_ addresses, so there still exists the possibility
+ * for static bus translation between device output and IOMMU input (yuck).
+ */
+static inline dma_addr_t dev_dma_addr(struct device *dev, dma_addr_t addr)
+{
+ dma_addr_t offset = (dma_addr_t)dev-dma_pfn_offset PAGE_SHIFT;
+
+ BUG_ON(addr offset);
+ return addr - offset;
+}
Are these just theoretical or you expect to see some at some point? I
think the dma_limit in __alloc_iova() may also need to take the offset
into account (or just ignore them altogether for now).
Right now I'm not aware of any platform which has both DMA offsets and
an IOMMU on the same bus, and I would really hope it stays that way.
This is just extra complication out of attempting to cover every
possibility, and you're right about the alloc_iova oversight. I'll rip
it out for simplicity, and remain hopeful that nobody ever builds
anything mad enough to need it put back.
+
+/**
+ * dma_direction_to_prot - Translate DMA API directions to IOMMU API page flags
+ * @dir: Direction of DMA transfer
+ * @coherent: Is the DMA master cache-coherent?
+ *
+ * Return: corresponding IOMMU API page protection flags
+ */
+int dma_direction_to_prot(enum dma_data_direction dir, bool coherent)
+{
+ int prot = coherent ? IOMMU_CACHE : 0;
+
+ switch (dir) {
+ case DMA_BIDIRECTIONAL:
+ return prot | IOMMU_READ | IOMMU_WRITE;
+ case DMA_TO_DEVICE:
+ return prot | IOMMU_READ;
+ case DMA_FROM_DEVICE:
+ return prot | IOMMU_WRITE;
+ default:
+ return 0;
+ }
+}
+
+static struct iova *__alloc_iova(struct device *dev, size_t size, bool
coherent)
+{
+ struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
+ struct iova_domain *iovad = domain-dma_api_cookie;
+ unsigned long shift = iova_shift(iovad);
+ unsigned long length = iova_align(iovad, size) shift;
+ u64 dma_limit = coherent ? dev-coherent_dma_mask : dma_get_mask(dev);
coherent and coherent_dma_mask have related meanings here. As I can
see in patch 3, the coherent information passed all the way to this
function states whether the device is cache coherent or not (and whether
cache maintenance is needed). The coherent_dma_mask refers to an
allocation mask for the dma_alloc_coherent() API but that doesn't
necessarily mean that the device is cache coherent. Similarly, dma_mask
is used for streaming DMA.
You can rename it to coherent_api or simply pass a u64 dma_mask
directly.
Bleh, it seems that at some point along the way I got confused and
started mistakenly thinking the DMA masks were about the device's
ability to issue coherent/non-coherent transactions. I'll clean up the
mess...
[...]
+/**
+ * iommu_dma_alloc - Allocate and map a buffer contiguous in IOVA space
+ * @dev: Device to allocate memory for. Must be a real device
+ * attached to an iommu_dma_domain
+ * @size: Size of buffer in bytes
+ * @gfp: Allocation flags
+ * @prot: IOMMU mapping flags
+ * @coherent: Which dma_mask to base IOVA allocation on
+ * @handle: Out argument for allocated DMA handle
+ * @flush_page: Arch callback to flush a single page from caches as
+ * necessary. May be NULL for coherent allocations
+ *
+ * If @size is less than PAGE_SIZE, then a full CPU page will be allocated,
+ * but an IOMMU which supports smaller pages might not map the whole thing.
+ * For now, the buffer is unconditionally zeroed for compatibility
+ *
+ * Return: Array of struct page pointers describing the buffer,
+ *or NULL on failure.
+ */
+struct page **iommu_dma_alloc(struct device *dev, size_t size, gfp_t gfp,
+ int prot, bool coherent, dma_addr_t *handle,
+ void (*flush_page)(const void *, phys_addr_t))
So for this function, coherent should always be true since this is only
used with the coherent DMA API AFAICT.
Indeed.
+{
+ struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
+ struct iova_domain *iovad = domain-dma_api_cookie;
+ struct iova *iova;
+ struct page **pages;
+ struct sg_table sgt;
+ struct sg_mapping_iter miter;
+ dma_addr_t dma_addr;
+ unsigned int count = PAGE_ALIGN(size) PAGE_SHIFT;
+
+ *handle = DMA_ERROR_CODE;
+
+ pages = __iommu_dma_alloc_pages(count, gfp);
+ if (!pages)
+ return NULL;
+
+ iova = __alloc_iova(dev, size, coherent);
And here just __alloc_iova(dev, size, true);
In fact, everything it wanted dev for is now available at all the
callsites, so I'll rejig the whole interface.
Robin.
[...]
+dma_addr_t iommu_dma_map_page(struct device *dev, struct page *page,
+ unsigned long offset, size_t size, int prot, bool coherent)
+{
+ dma_addr_t dma_addr;
Re: [RFC 0/6] vSMMU initialization
On Tue, Jul 14, 2015 at 1:04 PM, Will Deacon will.dea...@arm.com wrote: On Tue, Jul 14, 2015 at 03:21:03AM +0100, Varun Sethi wrote: Hi Will, Hi Varun, On Fri, Jun 12, 2015 at 03:20:04PM +0100, Baptiste Reynal wrote: The ARM SMMU has support for 2-stages address translations, allowing a virtual address to be translated at two levels: - Stage 1 translates a virtual address (VA) into an intermediate physical address (IPA) - Stage 2 translates an IPA into a physical address (PA) Will Deacon introduced a virtual SMMU interface for KVM, which gives a virtual machine the possibility to use an IOMMU with native drivers. While the VM will program the first stage of translation (stage 1), the interface will program the second (stage 2) on the physical SMMU. Please note that I have no plans to merge the kernel-side of this at the moment. It was merely an exploratory tool to see what a non-PV vSMMU implementation might look like and certainly not intended to be used in anger. How do you see the context fault reporting work for the PV interface? We could have an interrupt, for the PV IOMMU and have the hypervisor inject that, no? Currently the vSMMU interface does seem quiet restrictive and it may simplify things by having PV iommu interface. But, do you see this even true in case of SMMUv3? Varun, may I know what do you mean by more restrictive ? Do you have in mind any use case which should apply to the PV interface and not the vSMMU ? I think SMMUv3 is *far* more amenable to the vSMMU approach, largely because it moves many of the data structures into memory, but also because it has support for things like ATS and PRI, so sharing page tables with the CPU becomes a real possibility (and is something that doesn't work well with a PV model). Just wondering if we can give more control with respect memory transaction attributes to the guest. Also, would it make sense to give guest control of the fault handling attributes i.e. fault/terminate model. I'd like to see the basics prototyped before we start trying to design for these more advanced use-cases. I'm confident there are plenty of things we haven't even considered at the moment. Hi Will, From my current understanding, vSMMU and PV interface seems complementary and have different target. While the PV interface targets broad compatibility with hardware and page table abstraction, the vSMMU relies on specific hardware capabilities for better performances (with dual-stage support and future ATS/PRI). As no PV interface exists for now, we decided to focus our effort on the vSMMU. Unless PV interface is strictly needed, we'd like to continue with the implementation of the vSMMU. In my opinion, both solutions are complementary and can co-exist once someone shows interest for the PV. Will Best regards, Baptiste ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC 0/6] vSMMU initialization
On Wed, Jul 15, 2015 at 02:38:15PM +0100, Baptiste Reynal wrote: On Tue, Jul 14, 2015 at 1:04 PM, Will Deacon will.dea...@arm.com wrote: I think SMMUv3 is *far* more amenable to the vSMMU approach, largely because it moves many of the data structures into memory, but also because it has support for things like ATS and PRI, so sharing page tables with the CPU becomes a real possibility (and is something that doesn't work well with a PV model). Just wondering if we can give more control with respect memory transaction attributes to the guest. Also, would it make sense to give guest control of the fault handling attributes i.e. fault/terminate model. I'd like to see the basics prototyped before we start trying to design for these more advanced use-cases. I'm confident there are plenty of things we haven't even considered at the moment. From my current understanding, vSMMU and PV interface seems complementary and have different target. While the PV interface targets broad compatibility with hardware and page table abstraction, the vSMMU relies on specific hardware capabilities for better performances (with dual-stage support and future ATS/PRI). As no PV interface exists for now, we decided to focus our effort on the vSMMU. Unless PV interface is strictly needed, we'd like to continue with the implementation of the vSMMU. On the contrary, I'm not going to merge vSMMU code unless there are strong technical reasons against PV. I don't see your performance argument (I would actually expect the vSMMU to be *slower* with SMMUv2) and I really don't want fragmentation where user ABI is concerned. Also, your argument about focussing on vSMMU because PV doesn't exist yet doesn't make sense. Mainline doesn't support either of these for ARM. In my opinion, both solutions are complementary and can co-exist once someone shows interest for the PV. I think you have this the wrong way around. We should start with PV (one portable interface) and only add vSMMU interfaces where there are good reasons to do so. Will ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3 3/4] arm64: Add IOMMU dma_ops
On 15/07/15 10:31, Catalin Marinas wrote:
On Fri, Jul 10, 2015 at 08:19:34PM +0100, Robin Murphy wrote:
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index d16a1ce..ccadfd4 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -526,3 +526,426 @@ static int __init dma_debug_do_init(void)
return 0;
}
fs_initcall(dma_debug_do_init);
+
+
+#ifdef CONFIG_IOMMU_DMA
+#include linux/dma-iommu.h
+#include linux/platform_device.h
+#include linux/amba/bus.h
+
+/* Thankfully, all cache ops are by VA so we can ignore phys here */
+static void flush_page(const void *virt, phys_addr_t phys)
+{
+ __dma_flush_range(virt, virt + PAGE_SIZE);
+}
+
+static void *__iommu_alloc_attrs(struct device *dev, size_t size,
+dma_addr_t *handle, gfp_t gfp,
+struct dma_attrs *attrs)
+{
+ bool coherent = is_device_dma_coherent(dev);
+ int ioprot = dma_direction_to_prot(DMA_BIDIRECTIONAL, coherent);
+ void *addr;
+
+ if (WARN(!dev, cannot create IOMMU mapping for unknown device\n))
+ return NULL;
+
+ if (gfp __GFP_WAIT) {
+ struct page **pages;
+ pgprot_t pgprot = coherent ? __pgprot(PROT_NORMAL) :
+__pgprot(PROT_NORMAL_NC);
+
+ pgprot = __get_dma_pgprot(attrs, pgprot, coherent);
+ pages = iommu_dma_alloc(dev, size, gfp, ioprot, coherent,
+ handle, coherent ? NULL : flush_page);
As I replied already on the other patch, the coherent argument here
should always be true.
BTW, why do we need to call flush_page via iommu_dma_alloc() and not
flush the buffer directly in the arch __iommu_alloc_attrs()? We already
have the pointer and size after remapping in the CPU address space), it
would keep the iommu_dma_alloc() simpler.
Mostly for the sake of moving arch/arm (and possibly other users) over
later, where highmem and ATTR_NO_KERNEL_MAPPING make flushing the pages
at the point of allocation seem the most sensible thing to do. Since
iommu_dma_alloc already has a temporary scatterlist we can make use of
the sg mapping iterator there, rather than have separate code to iterate
over the pages (possibly with open-coded kmap/kunmap) in all the callers.
+ if (!pages)
+ return NULL;
+
+ addr = dma_common_pages_remap(pages, size, VM_USERMAP, pgprot,
+ __builtin_return_address(0));
+ if (!addr)
+ iommu_dma_free(dev, pages, size, handle);
+ } else {
+ struct page *page;
+ /*
+* In atomic context we can't remap anything, so we'll only
+* get the virtually contiguous buffer we need by way of a
+* physically contiguous allocation.
+*/
+ if (coherent) {
+ page = alloc_pages(gfp, get_order(size));
+ addr = page ? page_address(page) : NULL;
We could even use __get_free_pages(gfp ~__GFP_HIGHMEM) since we don't
have/need highmem on arm64.
True, but then we'd have to dig the struct page back out to pass through
to iommu_map_page.
+ } else {
+ addr = __alloc_from_pool(size, page, gfp);
+ }
+ if (addr) {
+ *handle = iommu_dma_map_page(dev, page, 0, size,
+ioprot, false);
Why coherent == false?
I'm not sure I even know any more, but either way it means the wrong
thing as discussed earlier, so it'll be going away.
+ if (iommu_dma_mapping_error(dev, *handle)) {
+ if (coherent)
+ __free_pages(page, get_order(size));
+ else
+ __free_from_pool(addr, size);
+ addr = NULL;
+ }
+ }
+ }
+ return addr;
+}
In the second case here (!__GFP_WAIT), do we do any cache maintenance? I
can't see it and it's needed for the !coherent case.
In the atomic non-coherent case, we're stealing from the atomic pool, so
addr is already a non-cacheable alias (and alloc_from_pool does
memset(0) through that). That shouldn't need anything extra, right?
+static void __iommu_free_attrs(struct device *dev, size_t size, void *cpu_addr,
+ dma_addr_t handle, struct dma_attrs *attrs)
+{
+ /*
+* @cpu_addr will be one of 3 things depending on how it was allocated:
+* - A remapped array of pages from iommu_dma_alloc(), for all
+* non-atomic allocations.
+* - A non-cacheable alias from the atomic pool, for atomic
+* allocations by
RE: [RFC 0/6] vSMMU initialization
Hi Baptiste, -Original Message- From: Baptiste Reynal [mailto:b.rey...@virtualopensystems.com] Sent: Wednesday, July 15, 2015 7:08 PM To: Will Deacon Cc: Sethi Varun-B16395; iommu@lists.linux-foundation.org; t...@virtualopensystems.com; qemu-de...@nongnu.org Subject: Re: [RFC 0/6] vSMMU initialization On Tue, Jul 14, 2015 at 1:04 PM, Will Deacon will.dea...@arm.com wrote: On Tue, Jul 14, 2015 at 03:21:03AM +0100, Varun Sethi wrote: Hi Will, Hi Varun, On Fri, Jun 12, 2015 at 03:20:04PM +0100, Baptiste Reynal wrote: The ARM SMMU has support for 2-stages address translations, allowing a virtual address to be translated at two levels: - Stage 1 translates a virtual address (VA) into an intermediate physical address (IPA) - Stage 2 translates an IPA into a physical address (PA) Will Deacon introduced a virtual SMMU interface for KVM, which gives a virtual machine the possibility to use an IOMMU with native drivers. While the VM will program the first stage of translation (stage 1), the interface will program the second (stage 2) on the physical SMMU. Please note that I have no plans to merge the kernel-side of this at the moment. It was merely an exploratory tool to see what a non-PV vSMMU implementation might look like and certainly not intended to be used in anger. How do you see the context fault reporting work for the PV interface? We could have an interrupt, for the PV IOMMU and have the hypervisor inject that, no? Currently the vSMMU interface does seem quiet restrictive and it may simplify things by having PV iommu interface. But, do you see this even true in case of SMMUv3? Varun, may I know what do you mean by more restrictive ? Do you have in mind any use case which should apply to the PV interface and not the vSMMU ? [varun] What I meant was that vSMMU allows for setting up of the stage 1 translation, but doesn't specifically allow access to other SMMU hardware functionality. We can certainly extend the vSMMU interface for providing additional functionality to the guest VM. I do agree with Will, that for extending the vSMMU interface prototyping is necessary. We need to come up with specific use cases for that. For controlling stage 1 translation PV interface may be a bit simpler, but then we would need a generic interface to bind to most IOMMUs in the host. -Varun ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
