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

From: Julien Grall <julien.grall@arm.com>
To: Lan Tianyu <tianyu.lan@intel.com>, xen-devel@lists.xen.org
Cc: kevin.tian@intel.com, wei.liu2@citrix.com,
	andrew.cooper3@citrix.com, ian.jackson@eu.citrix.com,
	jbeulich@suse.com, chao.gao@intel.com
Subject: Re: [PATCH 5/25] Xen/doc: Add Xen virtual IOMMU doc
Date: Fri, 7 Jul 2017 17:08:08 +0100	[thread overview]
Message-ID: <d14c8a94-5c30-a90d-3f07-5551390c4f80@arm.com> (raw)
In-Reply-To: <33eddcdc-1a2c-b705-5722-185643265f54@intel.com>

Hi,

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
>>>>> should
>>>>> +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.
>
> https://www.spinics.net/lists/kvm/msg147990.html
>
>>
>> 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?

Cheers,

-- 
Julien Grall

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