From: Tom Lendacky <firstname.lastname@example.org> To: email@example.com Cc: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org Subject: Re: swiotlb cleanups v3 Date: Sat, 17 Apr 2021 16:20:57 -0500 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> On 4/17/21 11:39 AM, Tom Lendacky wrote: >> Hi Konrad, >> >> this series contains a bunch of swiotlb cleanups, mostly to reduce the >> amount of internals exposed to code outside of swiotlb.c, which should >> helper to prepare for supporting multiple different bounce buffer pools. > > Somewhere between the 1st and 2nd patch, specifying a specific swiotlb > for an SEV guest is no longer honored. For example, if I start an SEV > guest with 16GB of memory and specify swiotlb=131072 I used to get a > 256MB SWIOTLB. However, after the 2nd patch, the swiotlb=131072 is no > longer honored and I get a 982MB SWIOTLB (as set via sev_setup_arch() in > arch/x86/mm/mem_encrypt.c). > > I can't be sure which patch caused the issue since an SEV guest fails to > boot with the 1st patch but can boot with the 2nd patch, at which point > the SWIOTLB comes in at 982MB (I haven't had a chance to debug it and so > I'm hoping you might be able to quickly spot what's going on). Ok, I figured out the 1st patch boot issue (which is gone when the second patch is applied). Here's the issue if anyone is interested: diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c index d9c097f0f78c..dbe369674afe 100644 --- a/kernel/dma/swiotlb.c +++ b/kernel/dma/swiotlb.c @@ -226,7 +226,7 @@ int __init swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int verbose) alloc_size = PAGE_ALIGN(mem->nslabs * sizeof(size_t)); mem->alloc_size = memblock_alloc(alloc_size, PAGE_SIZE); - if (mem->alloc_size) + if (!mem->alloc_size) panic("%s: Failed to allocate %zu bytes align=0x%lx\n", __func__, alloc_size, PAGE_SIZE); The 1st patch still allowed the command line specified size of 256MB SWIOTLB. So that means the 2nd patch causes the command line specified 256MB SWIOTLB size to be ignored and results in a 982MB SWIOTLB size for the 16GB guest. Thanks, Tom > > Thanks, > Tom > >> >> Changes since v2: >> - fix a bisetion hazard that did not allocate the alloc_size array >> - dropped all patches already merged >> >> Changes since v1: >> - rebased to v5.12-rc1 >> - a few more cleanups >> - merge and forward port the patch from Claire to move all the global >> variables into a struct to prepare for multiple instances >
next prev parent reply other threads:[~2021-04-17 21:21 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-03-18 16:14 Christoph Hellwig 2021-03-18 16:14 ` [PATCH 1/3] swiotlb: move global variables into a new io_tlb_mem structure Christoph Hellwig 2021-03-18 16:14 ` [PATCH 2/3] swiotlb: dynamically allocate io_tlb_default_mem Christoph Hellwig 2021-03-18 16:14 ` [PATCH 3/3] swiotlb: remove swiotlb_nr_tbl Christoph Hellwig 2021-04-17 16:39 ` swiotlb cleanups v3 Tom Lendacky 2021-04-17 21:20 ` Tom Lendacky [this message] 2021-04-20 9:23 ` Christoph Hellwig 2021-04-20 13:48 ` Tom Lendacky
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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: swiotlb cleanups v3' \ /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
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).