Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1651045 > unrolled thread

Re: [PATCH v5 31/32] x86: Add sysfs support for Secure Memory Encryption

Started byDave Young <dyoung@redhat.com>
First post2017-05-26 05:00 +0200
Last post2017-05-26 07:10 +0200
Articles 2 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH v5 31/32] x86: Add sysfs support for Secure Memory  Encryption Dave Young <dyoung@redhat.com> - 2017-05-26 05:00 +0200
    Re: [PATCH v5 31/32] x86: Add sysfs support for Secure Memory  Encryption Xunlei Pang <xpang@redhat.com> - 2017-05-26 07:10 +0200

#1651045 — Re: [PATCH v5 31/32] x86: Add sysfs support for Secure Memory Encryption

FromDave Young <dyoung@redhat.com>
Date2017-05-26 05:00 +0200
SubjectRe: [PATCH v5 31/32] x86: Add sysfs support for Secure Memory Encryption
Message-ID<tLdDP-8v1-1@gated-at.bofh.it>
Ccing Xunlei he is reading the patches see what need to be done for
kdump. There should still be several places to handle to make kdump work.

On 05/18/17 at 07:01pm, Borislav Petkov wrote:
> On Tue, Apr 18, 2017 at 04:22:12PM -0500, Tom Lendacky wrote:
> > Add sysfs support for SME so that user-space utilities (kdump, etc.) can
> > determine if SME is active.
> 
> But why do user-space tools need to know that?
> 
> I mean, when we load the kdump kernel, we do it with the first kernel,
> with the kexec_load() syscall, AFAICT. And that code does a lot of
> things during that init, like machine_kexec_prepare()->init_pgtable() to
> prepare the ident mapping of the second kernel, for example.
> 
> What I'm aiming at is that the first kernel knows *exactly* whether SME
> is enabled or not and doesn't need to tell the second one through some
> sysfs entries - it can do that during loading.
> 
> So I don't think we need any userspace things at all...

If kdump kernel can get the SME status from hardware register then this
should be not necessary and this patch can be dropped.

Thanks
Dave

[toc] | [next] | [standalone]


#1651082

FromXunlei Pang <xpang@redhat.com>
Date2017-05-26 07:10 +0200
Message-ID<tLfFE-1Dm-9@gated-at.bofh.it>
In reply to#1651045
On 05/26/2017 at 10:49 AM, Dave Young wrote:
> Ccing Xunlei he is reading the patches see what need to be done for
> kdump. There should still be several places to handle to make kdump work.
>
> On 05/18/17 at 07:01pm, Borislav Petkov wrote:
>> On Tue, Apr 18, 2017 at 04:22:12PM -0500, Tom Lendacky wrote:
>>> Add sysfs support for SME so that user-space utilities (kdump, etc.) can
>>> determine if SME is active.
>> But why do user-space tools need to know that?
>>
>> I mean, when we load the kdump kernel, we do it with the first kernel,
>> with the kexec_load() syscall, AFAICT. And that code does a lot of
>> things during that init, like machine_kexec_prepare()->init_pgtable() to
>> prepare the ident mapping of the second kernel, for example.
>>
>> What I'm aiming at is that the first kernel knows *exactly* whether SME
>> is enabled or not and doesn't need to tell the second one through some
>> sysfs entries - it can do that during loading.
>>
>> So I don't think we need any userspace things at all...
> If kdump kernel can get the SME status from hardware register then this
> should be not necessary and this patch can be dropped.

Yes, I also agree with dropping this one.

Regards,
Xunlei

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web