All of lore.kernel.org
 help / color / mirror / Atom feed
From: "joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org" <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
To: "Zhuo, Qiuxu" <qiuxu.zhuo-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: "iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org"
	<iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
	"jroedel-l3A5Bk7waGM@public.gmane.org"
	<jroedel-l3A5Bk7waGM@public.gmane.org>,
	"Luck, Tony" <tony.luck-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Subject: Re: Does a new booting kernel by "kexec -l" need to copy IR table from previous kernel?
Date: Thu, 27 Apr 2017 18:12:38 +0200	[thread overview]
Message-ID: <20170427161238.GD1332@8bytes.org> (raw)
In-Reply-To: <E6AF1AFDEA62A94A97508F458CBDD47F6EBEFCC9-0J0gbvR4kThpB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org>

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

  parent reply	other threads:[~2017-04-27 16:12 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-27 15:34 Does a new booting kernel by "kexec -l" need to copy IR table from previous kernel? Zhuo, Qiuxu
     [not found] ` <E6AF1AFDEA62A94A97508F458CBDD47F6EBEFCC9-0J0gbvR4kThpB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2017-04-27 16:12   ` joro-zLv9SwRftAIdnm+yROfE0A [this message]
     [not found]     ` <20170427161238.GD1332-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2017-04-27 16:21       ` Raj, Ashok
2017-04-28  8:17       ` Zhuo, Qiuxu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170427161238.GD1332@8bytes.org \
    --to=joro-zlv9swrftaidnm+yrofe0a@public.gmane.org \
    --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=jroedel-l3A5Bk7waGM@public.gmane.org \
    --cc=qiuxu.zhuo-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    --cc=tony.luck-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.