Re: Compiling makedumpfile from source
Thank you Kazuhito san. I will check the mentioned source. Manty On Wed, Jul 28, 2021 at 2:43 PM HAGIO KAZUHITO(萩尾 一仁) wrote: > > -Original Message- > > Hi kazuhito san, > > > > Just following up on my last email. > > Sincere apologies for asking for your time. > > I want to specifically understand what the "user data" section is and > > what it means to exclude it from the dump. > > "user data" are anonymous pages or huge pages. > https://github.com/makedumpfile/makedumpfile/blob/master/makedumpfile.c#L6224 > > Please consult the __exclude_unnecessary_pages() function above for > what conditions correspond to the type of page. > > Thanks, > Kazu > > > > > Thank you very much. > > > > Best Regards, > > Manty > > > > On Fri, Jul 9, 2021 at 10:45 AM manty kuma wrote: > > > > > > Hi Kazuhito san, > > > > > > I am looking to better understand the sections being filtering out > > > with each of the following options. > > > > > > Zero page: > > > Pages that are empty. Ignoring these pages won't have any impact on > > > analysis. > > > > > > non-private cache and private cache: > > > What exactly are these sections of memory? Just a one-line overview > > > about them is sufficient. > > > (My understanding was that cache is not part of RAM. Is this cache > > > something else? Like some bookkeeping data maintained by the kernel?) > > > > > > > > > user data: > > > Are these sections of the memory for the user space processes/memory > > > sections allocated using malloc? > > > My understanding is that If I exclude this section, gcore would not > > > work. Is my understanding correct? > > > I expected this section to be big. But in fact excluding this did not > > > have much impact on the dump size. > > > > > > free page: > > > unallocated pages. Since they are not allocated. filtering them out > > > won't have any impact on dump analysis. > > > Please correct me if I am wrong. > > > > > > > > > If there is already some place that explains what these sections > > > filter out, please just drop the reference to them and i will look > > > into it. > > > Thank you very much in advance! > > > > > > Manty > > > > > > On Thu, Jul 8, 2021 at 8:17 PM manty kuma wrote: > > > > > > > > Sorry. I am not sure how but I completely missed this email. > > > > Yes, /tmp was not available in my env. I just did mkdir before > > > > executing `makedumpfile` and it is now working well. > > > > Thank you very much. > > > > > > > > On Mon, Jun 28, 2021 at 4:07 PM HAGIO KAZUHITO(萩尾 一仁) > > > > wrote: > > > > > > > > > > -Original Message- > > > > > > Hi Kazuhito san, > > > > > > > > > > > > I am getting the following error when trying to use makedumpfile > > > > > > utility. > > > > > > > > > > > > > copy_vmcoreinfo: Can't open the vmcoreinfo > > > > > > > file(/tmp/vmcoreinfoLUQc25). No such file or directory. > > > > > > > makedumpfile Failed > > > > > > > > > > > > In your setup how are you providing the vmcoreinfo file? In my case > > > > > > it > > > > > > is checking /tmp/vmcoreinfoLUQc25 > > > > > > Who generates this file? > > > > > > > > > > Generally, vmcoreinfo is copied from vmcore's ELF note to > > > > > /tmp/vmcoreinfoXX > > > > > by makedumpfile, please see copy_vmcoreinfo(). So no need to provide > > > > > explicitly. > > > > > > > > > > Is there the /tmp directory on your environment? > > > > > > > > > > Kazu > > > > > > > > > > ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 00/11] Implement generic prot_guest_has() helper function
Am 28.07.21 um 00:26 schrieb Tom Lendacky:
This patch series provides a generic helper function, prot_guest_has(),
to replace the sme_active(), sev_active(), sev_es_active() and
mem_encrypt_active() functions.
It is expected that as new protected virtualization technologies are
added to the kernel, they can all be covered by a single function call
instead of a collection of specific function calls all called from the
same locations.
The powerpc and s390 patches have been compile tested only. Can the
folks copied on this series verify that nothing breaks for them.
As GPU driver dev I'm only one end user of this, but at least from the
high level point of view that makes totally sense to me.
Feel free to add an Acked-by: Christian König .
We could run that through the AMD GPU unit tests, but I fear we actually
don't test on a system with SEV/SME active.
Going to raise that on our team call today.
Regards,
Christian.
Cc: Andi Kleen
Cc: Andy Lutomirski
Cc: Ard Biesheuvel
Cc: Baoquan He
Cc: Benjamin Herrenschmidt
Cc: Borislav Petkov
Cc: Christian Borntraeger
Cc: Daniel Vetter
Cc: Dave Hansen
Cc: Dave Young
Cc: David Airlie
Cc: Heiko Carstens
Cc: Ingo Molnar
Cc: Joerg Roedel
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Michael Ellerman
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Thomas Zimmermann
Cc: Vasily Gorbik
Cc: VMware Graphics
Cc: Will Deacon
---
Patches based on:
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git master
commit 79e920060fa7 ("Merge branch 'WIP/fixes'")
Tom Lendacky (11):
mm: Introduce a function to check for virtualization protection
features
x86/sev: Add an x86 version of prot_guest_has()
powerpc/pseries/svm: Add a powerpc version of prot_guest_has()
x86/sme: Replace occurrences of sme_active() with prot_guest_has()
x86/sev: Replace occurrences of sev_active() with prot_guest_has()
x86/sev: Replace occurrences of sev_es_active() with prot_guest_has()
treewide: Replace the use of mem_encrypt_active() with
prot_guest_has()
mm: Remove the now unused mem_encrypt_active() function
x86/sev: Remove the now unused mem_encrypt_active() function
powerpc/pseries/svm: Remove the now unused mem_encrypt_active()
function
s390/mm: Remove the now unused mem_encrypt_active() function
arch/Kconfig | 3 ++
arch/powerpc/include/asm/mem_encrypt.h | 5 --
arch/powerpc/include/asm/protected_guest.h | 30 +++
arch/powerpc/platforms/pseries/Kconfig | 1 +
arch/s390/include/asm/mem_encrypt.h| 2 -
arch/x86/Kconfig | 1 +
arch/x86/include/asm/kexec.h | 2 +-
arch/x86/include/asm/mem_encrypt.h | 13 +
arch/x86/include/asm/protected_guest.h | 27 ++
arch/x86/kernel/crash_dump_64.c| 4 +-
arch/x86/kernel/head64.c | 4 +-
arch/x86/kernel/kvm.c | 3 +-
arch/x86/kernel/kvmclock.c | 4 +-
arch/x86/kernel/machine_kexec_64.c | 19 +++
arch/x86/kernel/pci-swiotlb.c | 9 ++--
arch/x86/kernel/relocate_kernel_64.S | 2 +-
arch/x86/kernel/sev.c | 6 +--
arch/x86/kvm/svm/svm.c | 3 +-
arch/x86/mm/ioremap.c | 16 +++---
arch/x86/mm/mem_encrypt.c | 60 +++---
arch/x86/mm/mem_encrypt_identity.c | 3 +-
arch/x86/mm/pat/set_memory.c | 3 +-
arch/x86/platform/efi/efi_64.c | 9 ++--
arch/x86/realmode/init.c | 8 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 4 +-
drivers/gpu/drm/drm_cache.c| 4 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 4 +-
drivers/gpu/drm/vmwgfx/vmwgfx_msg.c| 6 +--
drivers/iommu/amd/init.c | 7 +--
drivers/iommu/amd/iommu.c | 3 +-
drivers/iommu/amd/iommu_v2.c | 3 +-
drivers/iommu/iommu.c | 3 +-
fs/proc/vmcore.c | 6 +--
include/linux/mem_encrypt.h| 4 --
include/linux/protected_guest.h| 37 +
kernel/dma/swiotlb.c | 4 +-
36 files changed, 218 insertions(+), 104 deletions(-)
create mode 100644 arch/powerpc/include/asm/protected_guest.h
create mode 100644 arch/x86/include/asm/protected_guest.h
create mode 100644 include/linux/protected_guest.h
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 01/11] mm: Introduce a function to check for virtualization protection features
On Wed, Jul 28, 2021 at 02:17:27PM +0100, Christoph Hellwig wrote: > So common checks obviously make sense, but I really hate the stupid > multiplexer. Having one well-documented helper per feature is much > easier to follow. We had that in x86 - it was called cpu_has_ where xxx is the feature bit. It didn't scale with the sheer amount of feature bits that kept getting added so we do cpu_feature_enabled(X86_FEATURE_XXX) now. The idea behind this is very similar - those protected guest flags will only grow in the couple of tens range - at least - so having a multiplexer is a lot simpler, I'd say, than having a couple of tens of helpers. And those PATTR flags should have good, readable names, btw. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 02/11] x86/sev: Add an x86 version of prot_guest_has()
On Tue, Jul 27, 2021 at 05:26:05PM -0500, Tom Lendacky via iommu wrote: > Introduce an x86 version of the prot_guest_has() function. This will be > used in the more generic x86 code to replace vendor specific calls like > sev_active(), etc. > > While the name suggests this is intended mainly for guests, it will > also be used for host memory encryption checks in place of sme_active(). > > The amd_prot_guest_has() function does not use EXPORT_SYMBOL_GPL for the > same reasons previously stated when changing sme_active(), sev_active and None of that applies here as none of the callers get pulled into random macros. The only case of that is sme_me_mask through sme_mask, but that's not something this series replaces as far as I can tell. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 01/11] mm: Introduce a function to check for virtualization protection features
On Tue, Jul 27, 2021 at 05:26:04PM -0500, Tom Lendacky via iommu wrote: > In prep for other protected virtualization technologies, introduce a > generic helper function, prot_guest_has(), that can be used to check > for specific protection attributes, like memory encryption. This is > intended to eliminate having to add multiple technology-specific checks > to the code (e.g. if (sev_active() || tdx_active())). So common checks obviously make sense, but I really hate the stupid multiplexer. Having one well-documented helper per feature is much easier to follow. > +#define PATTR_MEM_ENCRYPT0 /* Encrypted memory */ > +#define PATTR_HOST_MEM_ENCRYPT 1 /* Host encrypted > memory */ > +#define PATTR_GUEST_MEM_ENCRYPT 2 /* Guest encrypted > memory */ > +#define PATTR_GUEST_PROT_STATE 3 /* Guest encrypted > state */ The kerneldoc comments on these individual helpers will give you plenty of space to properly document what they indicate and what a (potential) caller should do based on them. Something the above comments completely fail to. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
