Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1651045 > unrolled thread
| Started by | Dave Young <dyoung@redhat.com> |
|---|---|
| First post | 2017-05-26 05:00 +0200 |
| Last post | 2017-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.
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
| From | Dave Young <dyoung@redhat.com> |
|---|---|
| Date | 2017-05-26 05:00 +0200 |
| Subject | Re: [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]
| From | Xunlei Pang <xpang@redhat.com> |
|---|---|
| Date | 2017-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