[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |