Re: Compiling makedumpfile from source

2021-07-28 Thread manty kuma
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

2021-07-28 Thread Christian König

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

2021-07-28 Thread Borislav Petkov
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()

2021-07-28 Thread Christoph Hellwig
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

2021-07-28 Thread Christoph Hellwig
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