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

[Lan Tianyu <tianyu.lan@xxxxxxxxx>]

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 would prefer if you introduce a Kconfig that would be select by x86 only.
> Regards,


> Public headers sould not be GPLv2 otherwise it will cause some trouble 
> for non-GPLv2 OS. See the license in xen/include/public/COPYING.

Yes, it should be MIT license.
> 
> Regards.
> 
> -- Julien Grall


-- 
Best regards
Tianyu Lan

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