On 11/19/2016 3:43 AM, Julien Grall wrote:
Hi Lan,
On 17/11/2016 09:36, Lan Tianyu wrote:
1) Definition of "struct xen_dmop_viommu_op" as new hypercall parameter.
struct xen_dmop_viommu_op {
u32 cmd;
u32 domid;
u32 viommu_id;
union {
struct {
u32 capabilities;
} query_capabilities;
struct {
/* IN parameters. */
u32 capabilities;
u64 base_address;
struct {
u32 size;
XEN_GUEST_HANDLE_64(uint32) dev_list;
} dev_scope;
/* Out parameters. */
u32 viommu_id;
} create_iommu;
struct {
/* IN parameters. */
u32 vsbdf;
I only gave a quick look through this design document. The new
hypercalls looks arch/device agnostic except this part.
Having a virtual IOMMU on Xen ARM is something we might consider in the
future.
In the case of ARM, a device can either be a PCI device or integrated
device. The latter does not have a sbdf. The IOMMU will usually be
configured with a stream ID (SID) that can be deduced from the sbdf and
hardcoded for integrated device.
So I would rather not tie the interface to PCI and use a more generic
name for this field. Maybe vdevid, which then can be architecture specific.
Hi Julien:
Thanks for your input. This interface is just for virtual PCI device
which is called by Qemu. I am not familiar with ARM. Are there any
non-PCI emulated devices for arm in Qemu which need to be covered by vIOMMU?
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel