On 13.01.2023 09:10, Xenia Ragiadakou wrote:
>
> On 1/12/23 17:53, Jan Beulich wrote:
>> On 12.01.2023 16:43, Xenia Ragiadakou wrote:
>>> On 1/12/23 13:49, Xenia Ragiadakou wrote:
>>>> On 1/12/23 13:31, Jan Beulich wrote:
>>>>> On 04.01.2023 09:44, Xenia Ragiadakou wrote:
>>>>>> --- a/xen/include/xen/iommu.h
>>>>>> +++ b/xen/include/xen/iommu.h
>>>>>> @@ -74,9 +74,13 @@ extern enum __packed iommu_intremap {
>>>>>> iommu_intremap_restricted,
>>>>>> iommu_intremap_full,
>>>>>> } iommu_intremap;
>>>>>> -extern bool iommu_igfx, iommu_qinval, iommu_snoop;
>>>>>> #else
>>>>>> # define iommu_intremap false
>>>>>> +#endif
>>>>>> +
>>>>>> +#ifdef CONFIG_INTEL_IOMMU
>>>>>> +extern bool iommu_igfx, iommu_qinval, iommu_snoop;
>>>>>> +#else
>>>>>> # define iommu_snoop false
>>>>>> #endif
>>>>>
>>>>> Do these declarations really need touching? In patch 2 you didn't move
>>>>> amd_iommu_perdev_intremap's either.
>>>>
>>>> Ok, I will revert this change (as I did in v2 of patch 2) since it is
>>>> not needed.
>>>
>>> Actually, my patch was altering the current behavior by defining
>>> iommu_snoop as false when !INTEL_IOMMU.
>>>
>>> IIUC, there is no control over snoop behavior when using the AMD iommu.
>>> Hence, iommu_snoop should evaluate to true for AMD iommu.
>>> However, when using the INTEL iommu the user can disable it via the
>>> "iommu" param, right?
>>
>> That's the intended behavior, yes, but right now we allow the option
>> to also affect behavior on AMD - perhaps wrongly so, as there's one
>> use outside of VT-x and VT-d code. But of course the option is
>> documented to be there for VT-d only, so one can view it as user
>> error if it's used on a non-VT-d system.
>>
>>> If that's the case then iommu_snoop needs to be moved from vtd/iommu.c
>>> to x86/iommu.c and iommu_snoop assignment via iommu param needs to be
>>> guarded by CONFIG_INTEL_IOMMU.
>>
>> Or #define to true when !INTEL_IOMMU and keep the variable where it
>> is.
>
> Given the current implementation, if defined to true, it will be true
> even when !iommu_enabled.
Which is supposed to be benign; I'm about to send a patch to actually
make it benign in shadow code as well (which is the one place where I
notice it isn't right now).
Jan
