All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Borislav Petkov <bp@alien8.de>, Ashish Kalra <Ashish.Kalra@amd.com>
Cc: tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com,
	joro@8bytes.org, thomas.lendacky@amd.com, x86@kernel.org,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	srutherford@google.com, seanjc@google.com,
	venu.busireddy@oracle.com, brijesh.singh@amd.com
Subject: Re: [PATCH v13 09/12] mm: x86: Invoke hypercall when page encryption status is changed
Date: Wed, 21 Apr 2021 14:00:42 +0200	[thread overview]
Message-ID: <f63735b4-8ec2-fdb4-0bac-8ee0921268b0@redhat.com> (raw)
In-Reply-To: <20210421100508.GA11234@zn.tnic>

On 21/04/21 12:05, Borislav Petkov wrote:
> On Thu, Apr 15, 2021 at 03:57:26PM +0000, Ashish Kalra wrote:
>> +static inline void page_encryption_changed(unsigned long vaddr, int npages,
>> +						bool enc)
> 
> When you see a function name "page_encryption_changed", what does that
> tell you about what that function does?
> 
> Dunno but it doesn't tell me a whole lot.
> 
> Now look at the other function names in struct pv_mmu_ops.
> 
> See the difference?
> 
>> +static void set_memory_enc_dec_hypercall(unsigned long vaddr, int npages,
> 
> If I had to guess what that function does just by reading its name, it
> sets a memory encryption/decryption hypercall.
> 
> Am I close?

The words are right but the order is wrong (more like "hypercall to set 
some memory's encrypted/decrypted state").  Perhaps? 
kvm_hypercall_set_page_enc_status.

page_encryption_changed does not sound bad to me though, it's a 
notification-like function name.  Maybe notify_page_enc_status_changed?

Paolo

>> +					bool enc)
>> +{
>> +	unsigned long sz = npages << PAGE_SHIFT;
>> +	unsigned long vaddr_end, vaddr_next;
>> +
>> +	vaddr_end = vaddr + sz;
>> +
>> +	for (; vaddr < vaddr_end; vaddr = vaddr_next) {
>> +		int psize, pmask, level;
>> +		unsigned long pfn;
>> +		pte_t *kpte;
>> +
>> +		kpte = lookup_address(vaddr, &level);
>> +		if (!kpte || pte_none(*kpte))
>> +			return;
>> +
>> +		switch (level) {
>> +		case PG_LEVEL_4K:
>> +			pfn = pte_pfn(*kpte);
>> +			break;
>> +		case PG_LEVEL_2M:
>> +			pfn = pmd_pfn(*(pmd_t *)kpte);
>> +			break;
>> +		case PG_LEVEL_1G:
>> +			pfn = pud_pfn(*(pud_t *)kpte);
>> +			break;
>> +		default:
>> +			return;
>> +		}
> 
> Pretty much that same thing is in __set_clr_pte_enc(). Make a helper
> function pls.
> 
>> +
>> +		psize = page_level_size(level);
>> +		pmask = page_level_mask(level);
>> +
>> +		kvm_sev_hypercall3(KVM_HC_PAGE_ENC_STATUS,
>> +				   pfn << PAGE_SHIFT, psize >> PAGE_SHIFT, enc);
>> +
>> +		vaddr_next = (vaddr & pmask) + psize;
>> +	}
> 
> As with other patches from Brijesh, that should be a while loop. :)
> 
>> +}
>> +
>>   static void __init __set_clr_pte_enc(pte_t *kpte, int level, bool enc)
>>   {
>>   	pgprot_t old_prot, new_prot;
>> @@ -286,12 +329,13 @@ static void __init __set_clr_pte_enc(pte_t *kpte, int level, bool enc)
>>   static int __init early_set_memory_enc_dec(unsigned long vaddr,
>>   					   unsigned long size, bool enc)
>>   {
>> -	unsigned long vaddr_end, vaddr_next;
>> +	unsigned long vaddr_end, vaddr_next, start;
>>   	unsigned long psize, pmask;
>>   	int split_page_size_mask;
>>   	int level, ret;
>>   	pte_t *kpte;
>>   
>> +	start = vaddr;
>>   	vaddr_next = vaddr;
>>   	vaddr_end = vaddr + size;
>>   
>> @@ -346,6 +390,8 @@ static int __init early_set_memory_enc_dec(unsigned long vaddr,
>>   
>>   	ret = 0;
>>   
>> +	set_memory_enc_dec_hypercall(start, PAGE_ALIGN(size) >> PAGE_SHIFT,
>> +					enc);
>>   out:
>>   	__flush_tlb_all();
>>   	return ret;
>> @@ -481,6 +527,15 @@ void __init mem_encrypt_init(void)
>>   	if (sev_active() && !sev_es_active())
>>   		static_branch_enable(&sev_enable_key);
>>   
>> +#ifdef CONFIG_PARAVIRT
>> +	/*
>> +	 * With SEV, we need to make a hypercall when page encryption state is
>> +	 * changed.
>> +	 */
>> +	if (sev_active())
>> +		pv_ops.mmu.page_encryption_changed = set_memory_enc_dec_hypercall;
>> +#endif
> 
> There's already a sev_active() check above it. Merge the two pls.
> 
>> +
>>   	print_mem_encrypt_feature_info();
>>   }
>>   
>> diff --git a/arch/x86/mm/pat/set_memory.c b/arch/x86/mm/pat/set_memory.c
>> index 16f878c26667..3576b583ac65 100644
>> --- a/arch/x86/mm/pat/set_memory.c
>> +++ b/arch/x86/mm/pat/set_memory.c
>> @@ -27,6 +27,7 @@
>>   #include <asm/proto.h>
>>   #include <asm/memtype.h>
>>   #include <asm/set_memory.h>
>> +#include <asm/paravirt.h>
>>   
>>   #include "../mm_internal.h"
>>   
>> @@ -2012,6 +2013,12 @@ static int __set_memory_enc_dec(unsigned long addr, int numpages, bool enc)
>>   	 */
>>   	cpa_flush(&cpa, 0);
>>   
>> +	/* Notify hypervisor that a given memory range is mapped encrypted
>> +	 * or decrypted. The hypervisor will use this information during the
>> +	 * VM migration.
>> +	 */
> 
> Kernel comments style is:
> 
> 	/*
> 	 * A sentence ending with a full-stop.
> 	 * Another sentence. ...
> 	 * More sentences. ...
> 	 */
> 


  reply	other threads:[~2021-04-21 12:00 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-15 15:52 [PATCH v13 00/12] Add AMD SEV guest live migration support Ashish Kalra
2021-04-15 15:53 ` [PATCH v13 01/12] KVM: SVM: Add KVM_SEV SEND_START command Ashish Kalra
2021-04-20  8:50   ` Paolo Bonzini
2021-04-15 15:53 ` [PATCH v13 02/12] KVM: SVM: Add KVM_SEND_UPDATE_DATA command Ashish Kalra
2021-04-15 15:54 ` [PATCH v13 03/12] KVM: SVM: Add KVM_SEV_SEND_FINISH command Ashish Kalra
2021-04-15 15:54 ` [PATCH v13 04/12] KVM: SVM: Add support for KVM_SEV_RECEIVE_START command Ashish Kalra
2021-04-20  8:38   ` Paolo Bonzini
2021-04-20  9:18     ` Paolo Bonzini
2021-04-15 15:55 ` [PATCH v13 05/12] KVM: SVM: Add KVM_SEV_RECEIVE_UPDATE_DATA command Ashish Kalra
2021-04-20  8:40   ` Paolo Bonzini
2021-04-20  8:43     ` Paolo Bonzini
2021-04-15 15:55 ` [PATCH v13 06/12] KVM: SVM: Add KVM_SEV_RECEIVE_FINISH command Ashish Kalra
2021-04-15 15:56 ` [PATCH v13 07/12] KVM: x86: Add AMD SEV specific Hypercall3 Ashish Kalra
2021-04-15 15:57 ` [PATCH v13 08/12] KVM: X86: Introduce KVM_HC_PAGE_ENC_STATUS hypercall Ashish Kalra
2021-04-20 11:10   ` Paolo Bonzini
2021-04-20 17:24     ` Sean Christopherson
2021-04-15 15:57 ` [PATCH v13 09/12] mm: x86: Invoke hypercall when page encryption status is changed Ashish Kalra
2021-04-20  9:39   ` Paolo Bonzini
2021-04-21 10:05   ` Borislav Petkov
2021-04-21 12:00     ` Paolo Bonzini [this message]
2021-04-21 14:09       ` Borislav Petkov
2021-04-21 12:12     ` Ashish Kalra
2021-04-21 13:50       ` Brijesh Singh
2021-04-21 13:52       ` Borislav Petkov
2021-04-15 15:58 ` [PATCH v13 10/12] KVM: x86: Introduce new KVM_FEATURE_SEV_LIVE_MIGRATION feature & Custom MSR Ashish Kalra
2021-04-19 23:06   ` Sean Christopherson
2021-04-20 10:49     ` Paolo Bonzini
2021-04-20  9:47   ` Paolo Bonzini
2021-04-15 15:58 ` [PATCH v13 11/12] EFI: Introduce the new AMD Memory Encryption GUID Ashish Kalra
2021-04-15 16:01 ` [PATCH v13 12/12] x86/kvm: Add guest support for detecting and enabling SEV Live Migration feature Ashish Kalra
2021-04-15 16:01   ` Ashish Kalra
2021-04-20 10:52   ` Paolo Bonzini
2021-04-20 10:52     ` Paolo Bonzini
2021-04-21 14:44   ` Borislav Petkov
2021-04-21 14:44     ` Borislav Petkov
2021-04-21 15:22     ` Ashish Kalra
2021-04-21 15:22       ` Ashish Kalra
2021-04-21 15:32       ` Borislav Petkov
2021-04-21 15:32         ` Borislav Petkov
2021-04-21 15:38     ` Paolo Bonzini
2021-04-21 15:38       ` Paolo Bonzini
2021-04-21 18:48       ` Ashish Kalra
2021-04-21 18:48         ` Ashish Kalra
2021-04-21 19:19         ` Ashish Kalra
2021-04-21 19:19           ` Ashish Kalra
2021-04-16 21:43 ` [PATCH v13 00/12] Add AMD SEV guest live migration support Steve Rutherford
2021-04-19 14:40   ` Ashish Kalra
2021-04-20 11:11 ` Paolo Bonzini
2021-04-20 18:51   ` Borislav Petkov
2021-04-20 19:08     ` Paolo Bonzini
2021-04-20 20:28       ` Borislav Petkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f63735b4-8ec2-fdb4-0bac-8ee0921268b0@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=Ashish.Kalra@amd.com \
    --cc=bp@alien8.de \
    --cc=brijesh.singh@amd.com \
    --cc=hpa@zytor.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=seanjc@google.com \
    --cc=srutherford@google.com \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.com \
    --cc=venu.busireddy@oracle.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.