Re: [Xen-devel] [PATCH] iommu: leave IOMMU enabled by default during kexec crash transition

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 22.02.19 at 13:40, <igor.druzhinin@xxxxxxxxxx> wrote:
> On 22/02/2019 09:52, Jan Beulich wrote:
>>>>> On 20.02.19 at 19:19, <igor.druzhinin@xxxxxxxxxx> wrote:
>>> On 20/02/2019 08:48, Jan Beulich wrote:
>>>>
>>>> Some entity needs to decide whether to add the respective command
>>>> line option to the crash kernel's command line. It should be this same
>>>> entity to tell Xen whether to keep the IOMMU enabled while invoking
>>>> the crash kernel. I am merely guessing that this entity is the kexec
>>>> tool.
>>>>
>>>
>>> I was just double checking and it seems (assuming the device reset
>>> correctly in the crash kernel) everything seem to work even without
>>> enabling intel_iommu in the command line - newer kernels handle this
>>> case by explicitly disabling translation in any case: they expect it to
>>> be enabled by the previous kernel.
>> 
>> So if they disable translation, how is them doing so any better than us
>> doing so, other than theirs occurring slightly later on the time scale and
>> hence there being better chances of in-flight (at the time of the crash)
>> DMA having completed meanwhile?
>> 
> 
> There are several reasons why it's better:
> a) kernel is able to perform device reset properly as it has bus
> specific code that does this. There is even a comment in the code
> mentioning that at the moment it disables the translation bus-specific
> reset is finished and it's safer (as devices likely stopped DMA at this
> point) to do it now.
> b) kernel has the drivers that do per-driver-specific reset of the
> devices that do not work well with bus-specific reset. It's simply
> impossible to implement that in Xen
> c) even if a device is uncooperative and keeps sending bus transactions,
> an error event that I mentioned earlier will be properly handled as we
> have facilities for it in the kernel at that point

Okay, c) is a convincing argument. a) and b) are partly only: Iirc
crash kernels don't load unnecessary drivers, so a babbling device
may be left untouched unless generic kernel code can reset or
otherwise silence it.

Jan



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