Re: Xen virtual IOMMU high level design doc V2

["Lan, Tianyu" <tianyu.lan@intel.com>]

On 10/26/2016 5:39 PM, Jan Beulich wrote:
>>>> On 22.10.16 at 09:32, <tianyu.lan@intel.com> wrote:
>> On 10/21/2016 4:36 AM, Andrew Cooper wrote:
>>>>>> 3.5 Implementation consideration
>>>>>> VT-d spec doesn't define a capability bit for the l2 translation.
>>>>>> Architecturally there is no way to tell guest that l2 translation
>>>>>> capability is not available. Linux Intel IOMMU driver thinks l2
>>>>>> translation is always available when VTD exits and fail to be loaded
>>>>>> without l2 translation support even if interrupt remapping and l1
>>>>>> translation are available. So it needs to enable l2 translation first
>>>>>> before other functions.
>>>>>
>>>>> What then is the purpose of the nested translation support bit in the
>>>>> extended capability register?
>>>>
>>>> It's to translate output GPA from first level translation(IOVA->GPA)
>>>> to HPA.
>>>>
>>>> Detail please see VTD spec - 3.8 Nested Translation
>>>> "When Nesting Enable (NESTE) field is 1 in extended-context-entries,
>>>> requests-with-PASID translated through first-level translation are also
>>>> subjected to nested second-level translation. Such extendedcontext-
>>>> entries contain both the pointer to the PASID-table (which contains the
>>>> pointer to the firstlevel translation structures), and the pointer to
>>>> the second-level translation structures."
>>>
>>> I didn't phrase my question very well.  I understand what the nested
>>> translation bit means, but I don't understand why we have a problem
>>> signalling the presence or lack of nested translations to the guest.
>>>
>>> In other words, why can't we hide l2 translation from the guest by
>>> simply clearing the nested translation capability?
>>
>> You mean to tell no support of l2 translation via nest translation bit?
>> But the nested translation is a different function with l2 translation
>> even from guest view and nested translation only works requests with
>> PASID (l1 translation).
>>
>> Linux intel iommu driver enables l2 translation unconditionally and free
>> iommu instance when failed to enable l2 translation.
>
> In which cases the wording of your description is confusing: Instead of
> "Linux Intel IOMMU driver thinks l2 translation is always available when
> VTD exits and fail to be loaded without l2 translation support ..." how
> about using something closer to what you've replied with last?
>
> Jan
>

Hi All:
I have some updates about implementation dependency between l2
translation(DMA translation) and irq remapping.

I find there are a kernel parameter "intel_iommu=on" and kconfig option
CONFIG_INTEL_IOMMU_DEFAULT_ON which control DMA translation function.
When they aren't set, DMA translation function will not be enabled by
IOMMU driver even if some vIOMMU registers show L2 translation function
available. In the meantime, irq remapping function still can work to
support >255 vcpus.

I check distribution RHEL, SLES, Oracle and ubuntu don't set the kernel
parameter or select the kconfig option. So we can emulate irq remapping
fist with some capability bits(e,g SAGAW of Capability Register) of l2
translation for >255 vcpus support without l2 translation emulation.

Showing l2 capability bits is to make sure IOMMU driver probe ACPI DMAR
tables successfully because IOMMU driver access these bits during
reading ACPI tables.

If someone add "intel_iommu=on" kernel parameter manually, IOMMU driver
will panic guest because it can't enable DMA remapping function via gcmd
register and "Translation Enable Status" bit in gsts register is never
set by vIOMMU. This shows actual vIOMMU status of no l2 translation
emulation and warn user should not enable l2 translation.




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