Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1725429
| From | Andy Lutomirski <luto@kernel.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RFC Part1 PATCH v3 16/17] X86/KVM: Provide support to create Guest and HV shared per-CPU variables |
| Date | 2017-09-02 05:30 +0200 |
| Message-ID | <ul7ia-62d-1@gated-at.bofh.it> (permalink) |
| References | (1 earlier) <ujLWq-1pU-23@gated-at.bofh.it> <ujLWq-1pU-21@gated-at.bofh.it> <ukfhM-2SU-27@gated-at.bofh.it> <ukfhM-2SU-25@gated-at.bofh.it> <ul7ia-62d-3@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Fri, Sep 1, 2017 at 3:52 PM, Brijesh Singh <brijesh.singh@amd.com> wrote: > Hi Boris, > > On 08/30/2017 12:46 PM, Borislav Petkov wrote: >> >> On Wed, Aug 30, 2017 at 11:18:42AM -0500, Brijesh Singh wrote: >>> >>> I was trying to avoid mixing early and no-early set_memory_decrypted() >>> but if >>> feedback is: use early_set_memory_decrypted() only if its required >>> otherwise >>> use set_memory_decrypted() then I can improve the logic in next rev. >>> thanks >> >> >> Yes, I think you should use the early versions when you're, well, >> *early* :-) But get rid of that for_each_possible_cpu() and do it only >> on the current CPU, as this is a per-CPU path anyway. If you need to >> do it on *every* CPU and very early, then you need a separate function >> which is called in kvm_smp_prepare_boot_cpu() as there you're pre-SMP. >> > > I am trying to implement your feedback and now remember why I choose to > use early_set_memory_decrypted() and for_each_possible_cpu loop. These > percpu variables are static. Hence before clearing the C-bit we must > perform the in-place decryption so that original assignment is preserved > after we change the C-bit. Tom's SME patch [1] added sme_early_decrypt() > -- which can be used to perform the in-place decryption but we do not have > similar routine for non-early cases. In order to address your feedback, > we have to add similar functions. So far, we have not seen the need for > having such functions except this cases. The approach we have right now > works just fine and not sure if its worth adding new functions. > > Thoughts ? > > [1] Commit :7f8b7e7 x86/mm: Add support for early encryption/decryption of > memory Shouldn't this be called DEFINE_PER_CPU_UNENCRYPTED? ISTM the "HV shared" bit is incidental.
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: [RFC Part1 PATCH v3 16/17] X86/KVM: Provide support to create Guest and HV shared per-CPU variables Borislav Petkov <bp@suse.de> - 2017-08-29 12:30 +0200
Re: [RFC Part1 PATCH v3 16/17] X86/KVM: Provide support to create Guest and HV shared per-CPU variables Borislav Petkov <bp@suse.de> - 2017-08-30 19:50 +0200
Re: [RFC Part1 PATCH v3 16/17] X86/KVM: Provide support to create Guest and HV shared per-CPU variables Andy Lutomirski <luto@kernel.org> - 2017-09-02 05:30 +0200
Re: [RFC Part1 PATCH v3 16/17] X86/KVM: Provide support to create Guest and HV shared per-CPU variables Borislav Petkov <bp@suse.de> - 2017-09-04 19:10 +0200
csiph-web