[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [RFC PATCH 1/23] VIOMMU: Add vIOMMU helper functions to create, destroy and query capabilities



On 3/22/2017 7:40 PM, Julien Grall wrote:
Hello,

On 22/03/17 08:45, Lan Tianyu wrote:
Hi  Julien:
    Thanks for review.

On 2017年03月22日 03:56, Julien Grall wrote:
=======================================

diff --git a/xen/include/public/viommu.h b/xen/include/public/viommu.h
new file mode 100644
index 0000000..ca2419b

--- /dev/null

+++ b/xen/include/public/viommu.h

@@ -0,0 +1,9 @@

+/*
+·*·include/public/viommu.h
+·*
+·*·Copyright·(c)·2017·Intel·Corporation
+·*·Author:·Lan·Tianyu·<tianyu.lan@xxxxxxxxx>
+·*
+·*·This·program·is·free·software;·you·can·redistribute·it·and/or·modify·it

+·*·under·the·terms·and·conditions·of·the·GNU·General·Public·License,
+·*·version·2,·as·published·by·the·Free·Software·Foundation.

 obj-y += vmap.o
 obj-y += vsprintf.o
 obj-y += wait.o
+obj-y += viommu.o
I see very little point to enable viommu by default on all architecture.
This is x86 specific and I am yet sure how we would be able to use it on
ARM as the current series rely on QEMU. Also this is waste space in
struct domain.

XEN_DMOP_create/destroy_viommu hypercalls we introduced are generic for
all platforms and can use in toolstack to create/destroy vIOMMU rather
than just in Qemu. This takes PVH case into account which also don't use
Qemu.

I am afraid that none of the DMOP you suggested in this series will fit
for ARM.

For instance it is not possible to select via DMOP_CREATE the kind of
vIOMMU (e.g SMMUv2, SMMUv3, IPMMU-VMSA...).

Thanks for your information. I am not sure whether we can introduce arch specific hypercalls for different vIOMMU implementations and So try to make it more general. To support more type vIOMMUs or more vIOMMU subfeature, we may extend input parameter structure.


To be clear, I am not asking to get this code ready for ARM, but at
least we need to make sure the API could be easily extended. During the
discussion on the design documented it was suggested to add a
iommu_version field to make it "future proof".

Sure. That's very good suggestion. Sorry, I missed that in this series. and thought "capability" field in struct xen_dm_op_create_viommu is enough for other vendors to extend more sub features. Will change it.


Also, I was not asking to move this code in arch/x86 but not compiling
the code on ARM by default as it is currently unusable.

Sure. Will change it.


Regards,


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.