IOMMU Archive on
 help / color / Atom feed
From: Dave Young <>
To: Alexander Graf <>
Cc: Mark Rutland <>,, Lianbo Jiang <>,, Jan Kiszka <>,
	"Schoenherr, Jan H." <>,
	Christoph Hellwig <>,
	the arch/x86 maintainers <>,, Laszlo Ersek <>,, "Lendacky, Thomas" <>,
	Konrad Rzeszutek Wilk <>,,,
	Jan Setje-Eilers <>,, Kairui Song <>,,
	Linux Kernel Mailing List <>,,,
	Robin Murphy <>,
Subject: Re: [PATCH] swiotlb: Allow swiotlb to live at pre-defined address
Date: Tue, 31 Mar 2020 09:59:49 +0800
Message-ID: <> (raw)
In-Reply-To: <>


> 2) Reuse the SWIOTLB from the previous boot on kexec/kdump

We should only care about kdump

> I see little direct relation to SEV here. The only reason SEV makes it more
> relevant, is that you need to have an SWIOTLB region available with SEV
> while without you could live with a disabled IOMMU.

Here is some comment in arch/x86/kernel/pci-swiotlb.c, it is enforced
for some reason.
         * If SME is active then swiotlb will be set to 1 so that bounce
         * buffers are allocated and used for devices that do not support
         * the addressing range required for the encryption mask.
        if (sme_active())
                swiotlb = 1;

> However, I can definitely understand how you would want to have a way to
> tell the new kexec'ed kernel where the old SWIOTLB was, so it can reuse its
> memory for its own SWIOTLB. That way, you don't have to reserve another 64MB
> of RAM for kdump.
> What I'm curious on is whether we need to be as elaborate. Can't we just
> pass the old SWIOTLB as free memory to the new kexec'ed kernel and
> everything else will fall into place? All that would take is a bit of
> shuffling on the e820 table pass-through to the kexec'ed kernel, no?

Maybe either of the two is fine.  But we may need ensure these swiotlb
area to be reused explictly in some way.  Say about the crashkernel=X,high case,
major part is in above 4G region, and a small piece in low memory. Then
when kernel booting, kernel/driver initialization could use out of the
low memory, and the remain part for swiotlb could be not big enough and
finally swiotlb allocation fails. 


iommu mailing list

  parent reply index

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-26 16:29 Alexander Graf via iommu
2020-03-26 17:05 ` Christoph Hellwig
2020-03-26 17:11   ` Alexander Graf via iommu
2020-03-26 17:16     ` David Woodhouse
2020-03-30 13:24     ` Mark Rutland
2020-03-27  9:58 ` Jan Kiszka
2020-03-28 11:57 ` Dave Young
2020-03-30  6:06   ` Kairui Song
2020-03-30 13:40     ` Konrad Rzeszutek Wilk
2020-03-30 20:42       ` Alexander Graf via iommu
2020-03-30 23:37         ` Anthony Yznaga
2020-03-31  1:59         ` Dave Young [this message]
2020-03-31  2:16         ` Baoquan He
2020-03-31  1:46       ` Dave Young

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:

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

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

IOMMU Archive on

Archives are clonable:
	git clone --mirror linux-iommu/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-iommu linux-iommu/ \
	public-inbox-index linux-iommu

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone