Does a new booting kernel by "kexec -l" need to copy IR table from previous kernel?

Does a new booting kernel by "kexec -l" need to copy IR table from previous kernel?

[Zhuo, Qiuxu]

[-- Attachment #1.1: Type: text/plain, Size: 2168 bytes --]

Hi Joerg Roedel,

   When we run below command, the kernel message showed below confusing failed messages:
         sudo kexec -l /boot/vmlinuz-4.11.0-rc7 --append=root=UUID=276659dd-77f0-47f9-967c-7643c260b746 --initrd=/boot/initrd.img-4.11.0-rc7
         sudo kexec -e
          ---
     [ 0.203397] DMAR-IR: Failed to copy IR table for dmar2 from previous kernel
        [ 0.211568] DMAR-IR: Failed to copy IR table for dmar1 from previous kernel
        [ 0.219738] DMAR-IR: Failed to copy IR table for dmar0 from previous kernel
        [ 0.227906] DMAR-IR: Failed to copy IR table for dmar3 from previous kernel
   ---

      The driver "intel_irq_remapping.c" uses "is_kdump_kernel()" API to determine whether copy IR table from previous kernel.
      a) When booting a kdump kernel specified by "kexec -p" (loading the new kernel for use on panic), the "is_kdump_kernel()" API is true then the driver copy IR table from previous kernel.
      b) While when booting a new kernel specified by "kexec -l" (loading the new kernel into current kernel) the "is_kdump_kernel()" API is false then the driver prints error message "Failed to copy IR table from
            previous kernel" directly. It looks like the printk is misleading and it's nothing actually failed, but just it isn't copying if the new kernel is not a kdump kernel.

       Found that the commit id "af3b358e48115" said:
        ---
        iommu/vt-d: Copy IR table from old kernel when in kdump mode
        When we are booting into a kdump kernel and find IR enabled,
        copy over the contents of the previous IR table so that
        spurious interrupts will not be target aborted.
       ---

       May I ask some questions:
       What are spurious interrupts?
       For kdump kernel can we just reinitializing IR table(as like normal kernel boot from power on) to handle the "spurious interrupts" issue instead of copying IR  table from previous kernel?
       For booting a new kernel by "kexec -l" (my test case), do we still need to copy IR table from previous kernel to handle the "spurious interrupts" issue?

Thanks!
qiuxu




BR
qiuxu


[-- Attachment #1.2: Type: text/html, Size: 8613 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Does a new booting kernel by "kexec -l" need to copy IR table from previous kernel?

[joro-zLv9SwRftAIdnm+yROfE0A]

On Thu, Apr 27, 2017 at 03:34:06PM +0000, Zhuo, Qiuxu wrote:
> It looks like the printk is misleading and it’s nothing actually
> failed, but just it isn’t copying if the new kernel is not a kdump
> kernel.

Yes, that is true. But the messages are harmless and you are safe to
ignore them in your usecase. We only care about the kdump case when
copying the old IR and DMAR tables into the new kernel, because in the
kdump case the old kernel crashed and left devices in an undefined
state, so that they might still send DMA and IRQ requests to the new
kernel, corrupting data or causing spurious/blocked irqs. Blocked IRQs
or DMA requests might even break devices so that the new kernel can't
initialize them anymore.

That is why we want to make sure, that no spurious IRQ or DMA requests
are blocked when the new kernel initializes the IOMMU. In the non-kdump
case we can assume that the old kernel put the devices into a defined
state where they are not sending spurious requests.

>        For kdump kernel can we just reinitializing IR table(as like normal
> kernel boot from power on) to handle the “spurious interrupts” issue instead of
> copying IR  table from previous kernel?
> 
>        For booting a new kernel by “kexec -l” (my test case), do we still need
> to copy IR table from previous kernel to handle the “spurious interrupts”
> issue?

As I said, for your case there is no need to do the copying and you can
ignore the messages.


Regards,

	Joerg

_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: Does a new booting kernel by "kexec -l" need to copy IR table from previous kernel?

[Raj, Ashok]

Hi Joerg,

On Thu, Apr 27, 2017 at 06:12:38PM +0200, joro@8bytes.org wrote:
> On Thu, Apr 27, 2017 at 03:34:06PM +0000, Zhuo, Qiuxu wrote:
> > It looks like the printk is misleading and it’s nothing actually
> > failed, but just it isn’t copying if the new kernel is not a kdump
> > kernel.
> 
> Yes, that is true. But the messages are harmless and you are safe to
> ignore them in your usecase. We only care about the kdump case when

Looks like maybe sanitizing the message to make it less disturbing 
should be enough :-) 

> copying the old IR and DMAR tables into the new kernel, because in the
> kdump case the old kernel crashed and left devices in an undefined
> state, so that they might still send DMA and IRQ requests to the new
> kernel, corrupting data or causing spurious/blocked irqs. Blocked IRQs
> or DMA requests might even break devices so that the new kernel can't
> initialize them anymore.

Cheers,
Ashok
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

RE: Does a new booting kernel by "kexec -l" need to copy IR table from previous kernel?

[Zhuo, Qiuxu]

Hi Joerg Roedel,

> From: joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org [mailto:joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org] 
> Yes, that is true. But the messages are harmless and you are safe to ignore them in your usecase. 
> We only care about the kdump case when copying the old IR and DMAR tables into the new kernel, 
> because in the  kdump case the old kernel crashed and left devices in an undefined state, so that 
> they might still send DMA and IRQ requests to the new kernel, corrupting data or causing spurious/blocked irqs. 
> Blocked IRQs or DMA requests might even break devices so that the new kernel can't initialize them anymore.
...
> That is why we want to make sure, that no spurious IRQ or DMA requests are blocked when the new
>  kernel initializes the IOMMU. In the non-kdump case we can assume that the old kernel put the devices
> into a defined state where they are not sending spurious requests.

Thanks so much for your detail and clear comments, get it now.  Send you a patch " Don't print the failure message
when booting non-kdump kernel" to make it less alarming or misleading. Please review it, thanks!

BR
qiuxu