On 3/1/2017 3:25 AM, Dave Young wrote:

Hi Tom,

Hi Dave,

On 02/17/17 at 10:43am, Tom Lendacky wrote:

quoted

On 2/17/2017 9:57 AM, Konrad Rzeszutek Wilk wrote:

quoted

On Thu, Feb 16, 2017 at 09:47:55AM -0600, Tom Lendacky wrote:

quoted

Provide support so that kexec can be used to boot a kernel when SME is
enabled.

Is the point of kexec and kdump to ehh, dump memory ? But if the
rest of the memory is encrypted you won't get much, will you?

Kexec can be used to reboot a system without going back through BIOS.
So you can use kexec without using kdump.

For kdump, just taking a quick look, the option to enable memory
encryption can be provided on the crash kernel command line and then

Is there a simple way to get the SME status? Probably add some sysfs
file for this purpose.

Currently there is not.  I can look at adding something, maybe just the
sme_me_mask value, which if non-zero, would indicate SME is active.

quoted

crash kernel can would be able to copy the memory decrypted if the
pagetable is set up properly. It looks like currently ioremap_cache()
is used to map the old memory page.  That might be able to be changed
to a memremap() so that the encryption bit is set in the mapping. That
will mean that memory that is not marked encrypted (EFI tables, swiotlb
memory, etc) would not be read correctly.

Manage to store info about those ranges which are not encrypted so that
memremap can handle them?

I can look into whether something can be done in this area. Any input
you can provide as to what would be the best way/place to store the
range info so kdump can make use of it, would be greatly appreciated.

quoted

quoted

Would it make sense to include some printk to the user if they
are setting up kdump that they won't get anything out of it?

Probably a good idea to add something like that.

It will break kdump functionality, it should be fixed instead of
just adding printk to warn user..

I do want kdump to work. I'll investigate further what can be done in
this area.

Thanks,
Tom

Thanks
Dave