From: Wei Wang <wei.wang2@amd.com>
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>
Subject: Re: [PATCH 2 of 6 V6] amd iommu: call guest_iommu_set_base from hvmloader
Date: Mon, 15 Oct 2012 15:41:46 +0200 [thread overview]
Message-ID: <507C129A.2010203@amd.com> (raw)
In-Reply-To: <507C233702000078000A1670@nat28.tlf.novell.com>
On 10/15/2012 02:52 PM, Jan Beulich wrote:
>>>> On 15.10.12 at 14:23, Wei Wang<wei.wang2@amd.com> wrote:
>> 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.
>
> That'll likely make the interface even more ugly than the more
> flexible variant allowing for multiple IOMMUs independent of
> the segment they're on/for. But let's see what you come up
> with...
Hi Jan
My idea is to make the interface looks like that
guest_iommu_set_base(d, iommu_base, iommu_seg)
This will allow hvmloader to choose a non-zero iommu segment.
if iommu_seg > 0, then I will add a new iommu to guest iommu list and
update iommu_segment field accordingly. But I seem to see no reason to
add multiple guest iommus to pci segment 0.
Thanks,
Wei
> Jan
>
>
next prev parent reply other threads:[~2012-10-15 13:41 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-26 14:46 [PATCH 2 of 6 V6] amd iommu: call guest_iommu_set_base from hvmloader Wei Wang
2012-09-27 8:27 ` Jan Beulich
2012-10-15 10:00 ` Wei Wang
2012-10-15 10:11 ` Jan Beulich
2012-10-15 12:23 ` Wei Wang
2012-10-15 12:52 ` Jan Beulich
2012-10-15 13:41 ` Wei Wang [this message]
2012-10-15 13:51 ` Jan Beulich
2012-10-30 0:56 ` Zhang, Yang Z
-- strict thread matches above, loose matches on Subject: below --
2012-03-08 13:21 [PATCH 0 of 6 V6] amd iommu: support ats/gpgpu passthru on iommuv2 systems Wei Wang
2012-03-08 13:21 ` [PATCH 2 of 6 V6] amd iommu: call guest_iommu_set_base from hvmloader Wei Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=507C129A.2010203@amd.com \
--to=wei.wang2@amd.com \
--cc=Ian.Campbell@citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=JBeulich@suse.com \
--cc=keir@xen.org \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.