Re: [Xen-devel] [PATCH] AMD/IOMMU: correct handling when XT's prereq features are unavailable

[Jan Beulich <jbeulich@xxxxxxxx>]

On 28.02.2020 09:14, Jan Beulich wrote:
> On 27.02.2020 16:25, Andrew Cooper wrote:
>> On 27/02/2020 14:34, Jan Beulich wrote:
>>> @@ -1400,9 +1401,8 @@ int __init amd_iommu_prepare(bool xt)
>>>          if ( rc )
>>>              goto error_out;
>>>  
>>> -        rc = -ENODEV;
>>> -        if ( xt && (!iommu->features.flds.ga_sup || 
>>> !iommu->features.flds.xt_sup) )
>>> -            goto error_out;
>>> +        if ( !iommu->features.flds.ga_sup || !iommu->features.flds.xt_sup )
>>> +            no_xt = true;
>>>      }
>>>  
>>>      for_each_amd_iommu ( iommu )
>>
>> ... the contents of this loop depends on the early exit path you've just
>> deleted.
>>
>> In the case of x2apic not being available, we'll still set {ga,xt}_en to
>> the caller requested value.
> 
> Oh, indeed (and Roger, thank you too for noticing this). In fact
> it explains a hang later during boot that I did observe, and that
> I meant to look into later. That said, interrupts for Dom0 still
> don't seem to work quite right in this (partly broken) mode even
> with this fixed (there are several "No irq handler for vector"
> messages, and at the very least the disk doesn't work); I'll see
> to find time to look into that as well, but I'm pretty convinced
> it's an independent issue. (Seeing that interrupt remapping gets
> enabled this way, and x2APIC is pre-enabled, I'm suspecting this
> is another case where we need to force physical mode.)

And indeed x2apic_phys on the command line makes things work. Now
I'll have to figure a reasonable way when and how to communicate
the need to switch the mode. (Another potential issue I'm seeing is
that it may not be okay to bring up a CPU with APIC ID 0xff in
this case, and it pretty certainly would require further precautions
if we were to allow bringing up CPUs with even larger APIC IDs.)

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel