linux-kernel - Re: [PATCH] swiotlb: Allow swiotlb to live at pre-defined address

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200331015949.GB81569@dhcp-128-65.nay.redhat.com>
Date:   Tue, 31 Mar 2020 09:59:49 +0800
From:   Dave Young <dyoung@...hat.com>
To:     Alexander Graf <graf@...zon.com>
Cc:     Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
        Kairui Song <kasong@...hat.com>, anthony.yznaga@...cle.com,
        Jan Setje-Eilers <jan.setjeeilers@...cle.com>,
        iommu@...ts.linux-foundation.org,
        the arch/x86 maintainers <x86@...nel.org>,
        Christoph Hellwig <hch@....de>,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        Robin Murphy <robin.murphy@....com>, linux-doc@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Mark Rutland <mark.rutland@....com>, dwmw@...zon.com,
        benh@...zon.com, Jan Kiszka <jan.kiszka@...mens.com>,
        alcioa@...zon.com, aggh@...zon.com, aagch@...zon.com,
        dhr@...zon.com, Laszlo Ersek <lersek@...hat.com>,
        Baoquan He <bhe@...hat.com>, Lianbo Jiang <lijiang@...hat.com>,
        brijesh.singh@....com,
        "Lendacky, Thomas" <thomas.lendacky@....com>,
        kexec@...ts.infradead.org,
        "Schoenherr, Jan H." <jschoenh@...zon.de>
Subject: Re: [PATCH] swiotlb: Allow swiotlb to live at pre-defined address

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