[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.)


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.