[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201209125442.GC18203@zn.tnic>
Date: Wed, 9 Dec 2020 13:54:42 +0100
From: Borislav Petkov <bp@...en8.de>
To: Ashish Kalra <ashish.kalra@....com>
Cc: konrad.wilk@...cle.com, hch@....de, tglx@...utronix.de,
mingo@...hat.com, hpa@...or.com, x86@...nel.org, luto@...nel.org,
peterz@...radead.org, dave.hansen@...ux-intel.com,
iommu@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
brijesh.singh@....com, Thomas.Lendacky@....com, Jon.Grimm@....com,
rientjes@...gle.com
Subject: Re: [PATCH v8] swiotlb: Adjust SWIOTBL bounce buffer size for SEV
guests.
On Wed, Dec 09, 2020 at 12:29:07PM +0000, Ashish Kalra wrote:
> As i mentioned in the main comments above, this cannot be called in
> mem_encrypt_init() as that breaks reserve_crashkernel() which depends
> on SWIOTLB buffer size
Please elaborate how does it break.
> and is called before mem_encrypt_init(), therefore, it needs to be
> called from setup_atch() before reserve_crashkernel().
I know you have your requirements what needs to be called when like all
the other vendors who want to run stuff early in a particular order but
our boot init order is a single fragile mess. So this better be done
right!
Also,
[ 0.016630] software IO TLB: swiotlb_adjust:
[ 0.017005] reserve_crashkernel:
[ 0.050523] software IO TLB: swiotlb_init:
this looks strange - we're doing a swiotlb size adjust before init.
It probably makes sense as in: adjust the size before the SWIOTLB is
initialized so that it uses the correct size but this better be spelled
out.
> I believe that other memory encryption architectures such as s390 are
> also looking for something similar to be available.
Until you have something more palpable than belief, "let the others
extend it when they really need it." as I already mentioned.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Powered by blists - more mailing lists