On 01/11/2017 10:40 AM, Zhenyu Wang wrote:
> On 2017.01.11 10:18:30 +0800, Jike Song wrote:
>> On 01/10/2017 02:52 PM, Zhenyu Wang wrote:
>>> Prepare to remove detect_host() hook. Move intel iommu detection early
>>> in intel_gvt_init().
>>>
>>> Signed-off-by: Zhenyu Wang <zhen...@linux.intel.com>
>>> ---
>>> drivers/gpu/drm/i915/gvt/gvt.c | 7 +++++++
>>> drivers/gpu/drm/i915/gvt/kvmgt.c | 6 ------
>>> 2 files changed, 7 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915/gvt/gvt.c
>>> index 35264a991776..7a7886644acf 100644
>>> --- a/drivers/gpu/drm/i915/gvt/gvt.c
>>> +++ b/drivers/gpu/drm/i915/gvt/gvt.c
>>> @@ -73,6 +73,13 @@ int intel_gvt_init_host(void)
>>> if (intel_gvt_host.initialized)
>>> return 0;
>>>
>>> +#ifdef CONFIG_INTEL_IOMMU
>>> + if (intel_iommu_gfx_mapped) {
>>> + gvt_err("Hardware IOMMU compatibility not yet supported, try to
>>> boot with intel_iommu=igfx_off\n");
>>> + return -ENODEV;
>>> + }
>>> +#endif
>>> +
>>
>> Hi Zhenyu,
>>
>> Per my understanding, the "intel_iommu=" parameter acts only on native
>> (think about XenGT),
>> so it's better to keep it somewhere in kvmgt.c, maybe kvmgt_init()?
>>
>
> hmm, I think it's just a limit for current gvt device model but not related
> to hypervisor,
> and it would bail out to disable gvt only. Anyway we'll fix it soon so not
> worry much for that.
>
I agree that it's only a temporary workaround, only want to point out that
hypervisor does
matter: if we take XenGT considered, it has IOMMU hardware managed by
Hypervisor, so its the
host (dom0) kernel doesn't need any special configuration for iommu :)
--
Thanks,
Jike
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
