[SIG-CLOUD-8] Rebase custom changes to kernel-4.18.0-553.74.1.el8_10 #592
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…tead of a two-phase approach jira roc-2673 commit fbf6449 Instead of setting x86_virt_bits to a possibly-correct value and then correcting it later, do all the necessary checks before setting it. At this point, the #VC handler references boot_cpu_data.x86_virt_bits, and in the previous version, it would be triggered by the CPUIDs between the point at which it is set to 48 and when it is set to the correct value. Suggested-by: Dave Hansen <[email protected]> Signed-off-by: Adam Dunlap <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Tested-by: Jacob Xu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ronnie Sahlberg <[email protected]> Signed-off-by: Jonathan Maple <[email protected]> Signed-off-by: Shreeya Patel <[email protected]>
jira roc-2673 commit 3e32552 c->x86_cache_alignment is initialized from c->x86_clflush_size. However, commit fbf6449 moved c->x86_clflush_size initialization to later in boot without moving the c->x86_cache_alignment assignment: fbf6449 ("x86/sev-es: Set x86_virt_bits to the correct value straight away, instead of a two-phase approach") This presumably left c->x86_cache_alignment set to zero for longer than it should be. The result was an oops on 32-bit kernels while accessing a pointer at 0x20. The 0x20 came from accessing a structure member at offset 0x10 (buffer->cpumask) from a ZERO_SIZE_PTR=0x10. kmalloc() can evidently return ZERO_SIZE_PTR when it's given 0 as its alignment requirement. Move the c->x86_cache_alignment initialization to be after c->x86_clflush_size has an actual value. Fixes: fbf6449 ("x86/sev-es: Set x86_virt_bits to the correct value straight away, instead of a two-phase approach") Signed-off-by: Dave Hansen <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Link: https://lore.kernel.org/r/[email protected] (cherry picked from commit 3e32552) Signed-off-by: Ronnie Sahlberg <[email protected]> Signed-off-by: Jonathan Maple <[email protected]> Signed-off-by: Shreeya Patel <[email protected]>
jira LE-2183 bug-fix x86/sev-es: Set x86_virt_bits commit-author Paolo Bonzini <[email protected]> commit 9a45819 In commit fbf6449 ("x86/sev-es: Set x86_virt_bits to the correct value straight away, instead of a two-phase approach"), the initialization of c->x86_phys_bits was moved after this_cpu->c_early_init(c). This is incorrect because early_init_amd() expected to be able to reduce the value according to the contents of CPUID leaf 0x8000001f. Fortunately, the bug was negated by init_amd()'s call to early_init_amd(), which does reduce x86_phys_bits in the end. However, this is very late in the boot process and, most notably, the wrong value is used for x86_phys_bits when setting up MTRRs. To fix this, call get_cpu_address_sizes() as soon as X86_FEATURE_CPUID is set/cleared, and c->extended_cpuid_level is retrieved. Fixes: fbf6449 ("x86/sev-es: Set x86_virt_bits to the correct value straight away, instead of a two-phase approach") Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Dave Hansen <[email protected]> Cc:[email protected] Link: https://lore.kernel.org/all/20240131230902.1867092-2-pbonzini%40redhat.com (cherry picked from commit 9a45819) Signed-off-by: Jonathan Maple <[email protected]> Signed-off-by: Jonathan Maple <[email protected]> Signed-off-by: Shreeya Patel <[email protected]>
…sizes() jira LE-2183 bug-fix-prereq x86/sev-es: Set x86_virt_bits commit-author Borislav Petkov (AMD) <[email protected]> commit 95bfb35 Drop 'vp_bits_from_cpuid' as it is not really needed. No functional changes. Signed-off-by: Borislav Petkov (AMD) <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Link: https://lore.kernel.org/r/[email protected] (cherry picked from commit 95bfb35) Signed-off-by: Jonathan Maple <[email protected]> Signed-off-by: Jonathan Maple <[email protected]> Signed-off-by: Shreeya Patel <[email protected]>
jira LE-2183 bug-fix x86/sev-es: Set x86_virt_bits commit-author Dave Hansen <[email protected]> commit 2a38e4c tl;dr: CPUs with CPUID.80000008H but without CPUID.01H:EDX[CLFSH] will end up reporting cache_line_size()==0 and bad things happen. Fill in a default on those to avoid the problem. Long Story: The kernel dies a horrible death if c->x86_cache_alignment (aka. cache_line_size() is 0. Normally, this value is populated from c->x86_clflush_size. Right now the code is set up to get c->x86_clflush_size from two places. First, modern CPUs get it from CPUID. Old CPUs that don't have leaf 0x80000008 (or CPUID at all) just get some sane defaults from the kernel in get_cpu_address_sizes(). The vast majority of CPUs that have leaf 0x80000008 also get ->x86_clflush_size from CPUID. But there are oddballs. Intel Quark CPUs[1] and others[2] have leaf 0x80000008 but don't set CPUID.01H:EDX[CLFSH], so they skip over filling in ->x86_clflush_size: cpuid(0x00000001, &tfms, &misc, &junk, &cap0); if (cap0 & (1<<19)) c->x86_clflush_size = ((misc >> 8) & 0xff) * 8; So they: land in get_cpu_address_sizes() and see that CPUID has level 0x80000008 and jump into the side of the if() that does not fill in c->x86_clflush_size. That assigns a 0 to c->x86_cache_alignment, and hilarity ensues in code like: buffer = kzalloc(ALIGN(sizeof(*buffer), cache_line_size()), GFP_KERNEL); To fix this, always provide a sane value for ->x86_clflush_size. Big thanks to Andy Shevchenko for finding and reporting this and also providing a first pass at a fix. But his fix was only partial and only worked on the Quark CPUs. It would not, for instance, have worked on the QEMU config. 1. https://raw.githubusercontent.com/InstLatx64/InstLatx64/master/GenuineIntel/GenuineIntel0000590_Clanton_03_CPUID.txt 2. You can also get this behavior if you use "-cpu 486,+clzero" in QEMU. [ dhansen: remove 'vp_bits_from_cpuid' reference in changelog because bpetkov brutally murdered it recently. ] Fixes: fbf6449 ("x86/sev-es: Set x86_virt_bits to the correct value straight away, instead of a two-phase approach") Reported-by: Andy Shevchenko <[email protected]> Signed-off-by: Dave Hansen <[email protected]> Tested-by: Andy Shevchenko <[email protected]> Tested-by: Jörn Heusipp <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/all/[email protected]/ Link: https://lore.kernel.org/lkml/[email protected]/ Link: https://lore.kernel.org/all/20240517200534.8EC5F33E%40davehans-spike.ostc.intel.com (cherry picked from commit 2a38e4c) Signed-off-by: Jonathan Maple <[email protected]> Signed-off-by: Jonathan Maple <[email protected]> Signed-off-by: Shreeya Patel <[email protected]>
jira LE-3812 commit-author Haiyang Zhang <[email protected]> commit 40a1d11 Change the Kconfig dependency, so this driver can be built and run on ARM64 with 4K page size. 16/64K page sizes are not supported yet. Signed-off-by: Haiyang Zhang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> (cherry picked from commit 40a1d11) Signed-off-by: Shreeya Patel <[email protected]> Signed-off-by: Jonathan Maple <[email protected]> Signed-off-by: Shreeya Patel <[email protected]>
jira LE-3812 commit-author Haiyang Zhang <[email protected]> commit 382d174 As defined by the MANA Hardware spec, the queue size for DMA is 4KB minimal, and power of 2. And, the HWC queue size has to be exactly 4KB. To support page sizes other than 4KB on ARM64, define the minimal queue size as a macro separately from the PAGE_SIZE, which we always assumed it to be 4KB before supporting ARM64. Also, add MANA specific macros and update code related to size alignment, DMA region calculations, etc. Signed-off-by: Haiyang Zhang <[email protected]> Reviewed-by: Michael Kelley <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> (cherry picked from commit 382d174) Signed-off-by: Shreeya Patel <[email protected]> Signed-off-by: Jonathan Maple <[email protected]> Signed-off-by: Shreeya Patel <[email protected]>
jira LE-3812 commit-author Konstantin Taranov <[email protected]> commit e02497f Use ib_umem_dma_offset() helper to calculate correct dma offset. Fixes: 0266a17 ("RDMA/mana_ib: Add a driver for Microsoft Azure Network Adapter") Signed-off-by: Konstantin Taranov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Leon Romanovsky <[email protected]> (cherry picked from commit e02497f) Signed-off-by: Shreeya Patel <[email protected]> Signed-off-by: Jonathan Maple <[email protected]> Signed-off-by: Shreeya Patel <[email protected]>
…l page jira LE-3812 commit-author Long Li <[email protected]> commit 4a3b99b When mapping doorbell page from user-mode, the driver should use the system page size as this memory is allocated via mmap() from user-mode. Cc: [email protected] Fixes: 0266a17 ("RDMA/mana_ib: Add a driver for Microsoft Azure Network Adapter") Signed-off-by: Long Li <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Leon Romanovsky <[email protected]> (cherry picked from commit 4a3b99b) Signed-off-by: Shreeya Patel <[email protected]> Signed-off-by: Jonathan Maple <[email protected]> Signed-off-by: Shreeya Patel <[email protected]>
… size jira LE-3812 commit-author Long Li <[email protected]> commit 9e517a8 MANA hardware uses 4k page size. When calculating the page table index, it should use the hardware page size, not the system page size. Cc: [email protected] Fixes: 0266a17 ("RDMA/mana_ib: Add a driver for Microsoft Azure Network Adapter") Signed-off-by: Long Li <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Leon Romanovsky <[email protected]> (cherry picked from commit 9e517a8) Signed-off-by: Shreeya Patel <[email protected]> Signed-off-by: Jonathan Maple <[email protected]> Signed-off-by: Shreeya Patel <[email protected]>
shreeya-patel98
requested review from
PlaidCat,
bmastbergen,
kerneltoast and
thefossguy-ciq
shreeya-patel98
merged commit 75e099e
into
sig-cloud-8/4.18.0-553.74.1.el8_10
2 checks passed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Update process (This kernel CentOS base for
4.18.0-553)src.rpms hosted by RESFsig-cloud-8/4.18.0-553.74.1.el8_10branchelrelease.Removed Commits
None
Rebase Results
Build
kernel-build.log
KeslfTests
kselftest-after.log
kselftest-before.log