Hi Souptick,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on v4.17]
[cannot apply to linus/master powerpc/next sparc-next/master next-20180615]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://
In kdump mode, we need to dump the old memory into vmcore file,
if SME is enabled in the first kernel, we must remap the old
memory in encrypted manner, which will be automatically decrypted
when we read from DRAM. It helps to parse the vmcore for some tools.
Signed-off-by: Lianbo Jiang
---
Some
In kdump mode, it will copy the device table of IOMMU from the old
device table, which is encrypted when SME is enabled in the first
kernel. So we must remap it in encrypted manner in order to be
automatically decrypted when we read.
Signed-off-by: Lianbo Jiang
---
Some changes:
1. add some comme
When SME is enabled in the first kernel, we will allocate pages
for kdump without encryption in order to be able to boot the
second kernel in the same manner as kexec, which helps to keep
the same code style.
Signed-off-by: Lianbo Jiang
---
kernel/kexec_core.c | 12
1 file changed,
It is convenient to remap the old memory encrypted to the second
kernel by calling ioremap_encrypted().
Signed-off-by: Lianbo Jiang
---
Some changes:
1. remove the sme_active() check in __ioremap_caller().
2. put some logic into the early_memremap_pgprot_adjust() for
early memremap.
arch/x86/in
It is convenient to remap the old memory encrypted to the second kernel by
calling ioremap_encrypted().
When sme enabled on AMD server, we also need to support kdump. Because
the memory is encrypted in the first kernel, we will remap the old memory
encrypted to the second kernel(crash kernel), and
On Fri, 15 Jun 2018, Ricardo Neri wrote:
> On Fri, Jun 15, 2018 at 09:01:02AM +0100, Julien Thierry wrote:
> > In my patches, I'm not sure there is much to adapt to your work as most of
> > it is arch specific (although I wont say no to another pair of eyes looking
> > at them). From what I've seen
On Fri, 15 Jun 2018, Ricardo Neri wrote:
> On Fri, Jun 15, 2018 at 12:29:06PM +0200, Thomas Gleixner wrote:
> > You have to consider two cases:
> >
> > 1) !remapped mode:
> >
> > That's reasonably simple because you just have to deal with the HPET
> > TIMERn_PROCMSG_ROUT register. But th
On Fri, 15 Jun 2018, Ricardo Neri wrote:
> On Fri, Jun 15, 2018 at 11:19:09AM +0200, Thomas Gleixner wrote:
> > On Thu, 14 Jun 2018, Ricardo Neri wrote:
> > > Alternatively, there could be a counter that skips reading the HPET status
> > > register (and the detection of hardlockups) for every X NMI
