linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Young <dyoung@redhat.com>
To: Alexander Graf <graf@amazon.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Kairui Song <kasong@redhat.com>,
	anthony.yznaga@oracle.com,
	Jan Setje-Eilers <jan.setjeeilers@oracle.com>,
	iommu@lists.linux-foundation.org,
	the arch/x86 maintainers <x86@kernel.org>,
	Christoph Hellwig <hch@lst.de>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Robin Murphy <robin.murphy@arm.com>,
	linux-doc@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	dwmw@amazon.com, benh@amazon.com,
	Jan Kiszka <jan.kiszka@siemens.com>,
	alcioa@amazon.com, aggh@amazon.com, aagch@amazon.com,
	dhr@amazon.com, Laszlo Ersek <lersek@redhat.com>,
	Baoquan He <bhe@redhat.com>, Lianbo Jiang <lijiang@redhat.com>,
	brijesh.singh@amd.com, "Lendacky,
	Thomas" <thomas.lendacky@amd.com>,
	kexec@lists.infradead.org, "Schoenherr,
	Jan H." <jschoenh@amazon.de>
Subject: Re: [PATCH] swiotlb: Allow swiotlb to live at pre-defined address
Date: Tue, 31 Mar 2020 09:59:49 +0800	[thread overview]
Message-ID: <20200331015949.GB81569@dhcp-128-65.nay.redhat.com> (raw)
In-Reply-To: <51432837-8804-0600-c7a3-8849506f999e@amazon.com>

Hi,

[snip]
> 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. 

Thanks
Dave


  parent reply	other threads:[~2020-03-31  2:00 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-26 16:29 [PATCH] swiotlb: Allow swiotlb to live at pre-defined address Alexander Graf
2020-03-26 17:05 ` Christoph Hellwig
2020-03-26 17:11   ` Alexander Graf
2020-03-26 17:16     ` David Woodhouse
2020-03-30 13:24     ` Mark Rutland
2020-03-27  6:05 ` kbuild test robot
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
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:
  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=20200331015949.GB81569@dhcp-128-65.nay.redhat.com \
    --to=dyoung@redhat.com \
    --cc=aagch@amazon.com \
    --cc=aggh@amazon.com \
    --cc=alcioa@amazon.com \
    --cc=anthony.yznaga@oracle.com \
    --cc=benh@amazon.com \
    --cc=bhe@redhat.com \
    --cc=brijesh.singh@amd.com \
    --cc=dhr@amazon.com \
    --cc=dwmw@amazon.com \
    --cc=graf@amazon.com \
    --cc=hch@lst.de \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jan.kiszka@siemens.com \
    --cc=jan.setjeeilers@oracle.com \
    --cc=jschoenh@amazon.de \
    --cc=kasong@redhat.com \
    --cc=kexec@lists.infradead.org \
    --cc=konrad.wilk@oracle.com \
    --cc=lersek@redhat.com \
    --cc=lijiang@redhat.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=mark.rutland@arm.com \
    --cc=robin.murphy@arm.com \
    --cc=thomas.lendacky@amd.com \
    --cc=x86@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).