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

Re: [Xen-devel] [PATCH 5/25] Xen/doc: Add Xen virtual IOMMU doc


On 06/07/17 04:10, Lan Tianyu wrote:
On 2017年07月05日 21:25, Julien Grall wrote:

+- XEN_DOMCTL_create_viommu
+    Create vIOMMU device with vIOMMU_type, capabilities, MMIO
+base address and length. Hypervisor returns viommu_id. Capabilities
+be in range of value returned by query_viommu_caps hypercall.

Can you explain what mmio and length are here for? Do you expect to trap
and emulate the MMIO region in Xen?

Yes, we need to emulate VTD MMIO register in the Xen hypervisor and this
is agreement under design stage. The MMIO base address is passed to
guest via ACPI table which is built by tool stack and so tool stack
manages vIOMMU MMIO region. When create vIOMMU, base address and length
needs to be passed.

I am not yet sure we want to emulate an IOMMU for ARM. They are a bit
complex to emulate and we have multiple one (SMMUv2, SMMUv3,
IPMMU-VMSA,...). So PV might be the solution here. Though, it is too
early to decide.

Yes, What I got ARM vIOMMU from KVM side is that ARM engineer are
pushing PV IOMMU and reason for that is just like you said about
multiple IOMMU version.


If we wanted to use emulation, an IOMMU may have multiple MMIO ranges
and multiple interrupts (either legacy or MSI). Here you are assuming
only one MMIO and no interrupt. This new interface is a DOMCTL so it
might be ok to extend it in the future?

For Intel VTD, one instance's MMIO registers will be in "4KB-aligned
memorymapped location" and so just need to pass base address and
length(4KB). If other vendor have multi-MMIO region, the structure can
be extended.

It can be extended if the hypercall introduced is only part of non-stable ABI. I realise that it is a DOMCTL, so I guess it is fine to be extended.

Because we now just have onE vIOMMU, all virtual interrupt will be bound
to it. If need to support mult-vIOMMU, we can add device-scope
field(sbdf array or some thing like that) in the structure and specify
what devices should be under one vIOMMU.

I am not sure to follow the argument here. Even if you have only one vIOMMU you need to be able to do the correspondence between the virtual MasterID (for PCI it is based on the RID) and the host MasterID.

So how do you do that with your solution?


Julien Grall

Xen-devel mailing list



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