Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1582914
| From | Borislav Petkov <bp@alien8.de> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RFC PATCH v4 03/28] x86: Add the Secure Memory Encryption CPU feature |
| Date | 2017-02-16 21:10 +0100 |
| Message-ID | <tbAxk-2RL-37@gated-at.bofh.it> (permalink) |
| References | <tbyvy-1iO-79@gated-at.bofh.it> <tbyOT-1GL-45@gated-at.bofh.it> <tbyOT-1GL-43@gated-at.bofh.it> <tbAxk-2RL-39@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Thu, Feb 16, 2017 at 01:42:13PM -0600, Tom Lendacky wrote:
> I realize it's a bit more code and expands the changes but I thought it
> would be a bit clearer as to what was going on this way. And then the
> follow on patch for the physical address reduction goes in nicely, too.
Well, the code from the next patch should go to AMD-specific place like
arch/x86/kernel/cpu/amd.c anyway, where you don't have to do vendor
checks.
> If you prefer I stay with the scattered feature approach and then clear
> the bit based on the MSR at the end of init_amd() I can do that. I'm
> not attached to either method.
Yes please. We should keep the shole X86_FEATURE machinery from
exploding in size. Especially if CPUID_0x8000001f is not a leaf we're
going to be adding the majority of its bits, to warrant a separate
->x86_capability array element.
[If it does later, we can always move it to a separate element. ]
Thanks.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
Re: [RFC PATCH v4 03/28] x86: Add the Secure Memory Encryption CPU feature Borislav Petkov <bp@alien8.de> - 2017-02-16 19:20 +0100 Re: [RFC PATCH v4 03/28] x86: Add the Secure Memory Encryption CPU feature Borislav Petkov <bp@alien8.de> - 2017-02-16 21:10 +0100
csiph-web