From mboxrd@z Thu Jan  1 00:00:00 1970
From: Wei Wang <wei.wang2@amd.com>
Subject: Re: [PATCH 2 of 6 V6] amd iommu: call
	guest_iommu_set_base from hvmloader
Date: Mon, 15 Oct 2012 14:23:39 +0200
Message-ID: <507C004B.20003@amd.com>
References: <5063155A.4070307@amd.com>
	<50642A2A020000780009E32D@nat28.tlf.novell.com>
	<507BDED1.6020005@amd.com>
	<507BFD7802000078000A1526@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <507BFD7802000078000A1526@nat28.tlf.novell.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Jan Beulich <JBeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>, IanCampbell <Ian.Campbell@citrix.com>
List-Id: xen-devel@lists.xenproject.org

On 10/15/2012 12:11 PM, Jan Beulich wrote:
>>>> On 15.10.12 at 12:00, Wei Wang<wei.wang2@amd.com>  wrote:
>> On 09/27/2012 10:27 AM, Jan Beulich wrote:
>>>>>> On 26.09.12 at 16:46, Wei Wang<wei.wang2@amd.com>   wrote:
>>>> @@ -3834,6 +3835,9 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void)
>> arg)
>>>>               case HVM_PARAM_BUFIOREQ_EVTCHN:
>>>>                   rc = -EINVAL;
>>>>                   break;
>>>> +            case HVM_PARAM_IOMMU_BASE:
>>>> +                rc = guest_iommu_set_base(d, a.value);
>>>
>>> This suggests that you're allowing for only a single IOMMU per
>>> guest - is that not going to become an issue sooner or later?
>>
>> I think that one iommu per guest is probably enough. Because guest IVRS
>> table is totally virtual, it does not reflect any pci relationship of
>> real systems. Even if qemu supports multi pci buses, we can still
>> virtually group them together into one virtual IVRS table. It might be
>> an issue if qemu uses multi pci segments, but so far even hardware iommu
>> only uses segment 0. Additionally, the guest iommu is only used by ats
>> capable GPUs. Normal passthrough device should not make use of it. So,,
>> What do you think?
>
> Especially the multi-segment aspect makes me think that the
> interface should allow for multiple IOMMUs, even if the
> implementation supports only one for now.

Ok, then I will rework the interface to take iommu segment as an 
additional parameter.
Thanks,
Wei

> Jan
>
>