From: "Singh, Brijesh" <brijesh.singh@amd.com> To: "Lendacky, Thomas" <Thomas.Lendacky@amd.com>, "kvm@vger.kernel.org" <kvm@vger.kernel.org> Cc: "Singh, Brijesh" <brijesh.singh@amd.com>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, "Thomas Gleixner" <tglx@linutronix.de>, "Ingo Molnar" <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>, "Paolo Bonzini" <pbonzini@redhat.com>, "Radim Krčmář" <rkrcmar@redhat.com>, "Joerg Roedel" <joro@8bytes.org>, "Borislav Petkov" <bp@suse.de>, "x86@kernel.org" <x86@kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org> Subject: Re: [Qemu-devel] [RFC PATCH v1 08/10] KVM: X86: Introduce KVM_HC_PAGE_ENC_STATUS hypercall Date: Fri, 3 May 2019 14:25:04 +0000 [thread overview] Message-ID: <0f120899-c4fb-724a-00f9-997c362efd37@amd.com> (raw) In-Reply-To: <d31531fe-f01c-817b-06e5-f06b5968b266@amd.com> On 4/26/19 4:39 PM, Lendacky, Thomas wrote: > On 4/24/19 11:10 AM, Singh, Brijesh wrote: >> The hypercall can be used by the SEV guest to notify the page encryption > > This hyercall is used by the SEV guest to notify a change in the page... > >> status to the hypervisor. The hypercall should be invoked only when >> the encryption attribute is changed from encrypted -> decrypted and vice >> versa. By default all the guest pages should be considered encrypted. > > By default all guest page are considered > >> >> Cc: Thomas Gleixner <tglx@linutronix.de> >> Cc: Ingo Molnar <mingo@redhat.com> >> Cc: "H. Peter Anvin" <hpa@zytor.com> >> Cc: Paolo Bonzini <pbonzini@redhat.com> >> Cc: "Radim Krčmář" <rkrcmar@redhat.com> >> Cc: Joerg Roedel <joro@8bytes.org> >> Cc: Borislav Petkov <bp@suse.de> >> Cc: Tom Lendacky <thomas.lendacky@amd.com> >> Cc: x86@kernel.org >> Cc: kvm@vger.kernel.org >> Cc: linux-kernel@vger.kernel.org >> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> >> --- >> Documentation/virtual/kvm/hypercalls.txt | 14 +++++ >> arch/x86/include/asm/kvm_host.h | 2 + >> arch/x86/kvm/svm.c | 69 ++++++++++++++++++++++++ >> arch/x86/kvm/vmx/vmx.c | 1 + >> arch/x86/kvm/x86.c | 5 ++ >> include/uapi/linux/kvm_para.h | 1 + >> 6 files changed, 92 insertions(+) >> >> diff --git a/Documentation/virtual/kvm/hypercalls.txt b/Documentation/virtual/kvm/hypercalls.txt >> index da24c138c8d1..ecd44e488679 100644 >> --- a/Documentation/virtual/kvm/hypercalls.txt >> +++ b/Documentation/virtual/kvm/hypercalls.txt >> @@ -141,3 +141,17 @@ a0 corresponds to the APIC ID in the third argument (a2), bit 1 >> corresponds to the APIC ID a2+1, and so on. >> >> Returns the number of CPUs to which the IPIs were delivered successfully. >> + >> +7. KVM_HC_PAGE_ENC_STATUS >> +------------------------- >> +Architecture: x86 >> +Status: active >> +Purpose: Notify the encryption status changes in guest page table (SEV guest) >> + >> +a0: the guest physical address of the start page >> +a1: the number of pages >> +a2: set or clear the encryption attribute > > a2: encryption attribute > >> + >> + Where: >> + * 1: Encryption attribute is set >> + * 0: Encryption attribute is cleared >> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h >> index a9d03af34030..adb0ca035b97 100644 >> --- a/arch/x86/include/asm/kvm_host.h >> +++ b/arch/x86/include/asm/kvm_host.h >> @@ -1196,6 +1196,8 @@ struct kvm_x86_ops { >> uint16_t (*nested_get_evmcs_version)(struct kvm_vcpu *vcpu); >> >> bool (*need_emulation_on_page_fault)(struct kvm_vcpu *vcpu); >> + int (*page_enc_status_hc)(struct kvm *kvm, unsigned long gpa, >> + unsigned long sz, unsigned long mode); >> }; >> >> struct kvm_arch_async_pf { >> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c >> index 74b57ab742ad..f024f208b052 100644 >> --- a/arch/x86/kvm/svm.c >> +++ b/arch/x86/kvm/svm.c >> @@ -138,6 +138,8 @@ struct kvm_sev_info { >> int fd; /* SEV device fd */ >> unsigned long pages_locked; /* Number of pages locked */ >> struct list_head regions_list; /* List of registered regions */ >> + unsigned long *page_enc_bmap; >> + unsigned long page_enc_bmap_size; >> }; >> >> struct kvm_svm { >> @@ -1911,6 +1913,8 @@ static void sev_vm_destroy(struct kvm *kvm) >> >> sev_unbind_asid(kvm, sev->handle); >> sev_asid_free(kvm); >> + >> + kvfree(sev->page_enc_bmap); >> } >> >> static void avic_vm_destroy(struct kvm *kvm) >> @@ -7370,6 +7374,69 @@ static int sev_receive_finish(struct kvm *kvm, struct kvm_sev_cmd *argp) >> return ret; >> } >> >> +static int sev_resize_page_enc_bitmap(struct kvm *kvm, unsigned long new_size) >> +{ >> + struct kvm_sev_info *sev = &to_kvm_svm(kvm)->sev_info; >> + unsigned long *map; >> + unsigned long sz; >> + >> + if (sev->page_enc_bmap_size >= new_size) >> + return 0; >> + >> + sz = ALIGN(new_size, BITS_PER_LONG) / 8; >> + >> + if (sz > PAGE_SIZE) >> + map = vmalloc(sz); >> + else >> + map = kmalloc(sz, GFP_KERNEL); > > Any reason this can't always be vmalloc()? > Yes, we can use vmalloc() unconditionally. The bitmap size will be mostly greater than PAGE_SIZE hence the above is useless anyway. >> + >> + if (!map) { >> + pr_err_once("Failed to allocate decrypted bitmap size %lx\n", sz); >> + return 1; > > Should this be -ENOMEM? > >> + } >> + >> + /* mark the page encrypted (by default) */ >> + memset(map, 0xff, sz); >> + >> + bitmap_copy(map, sev->page_enc_bmap, sev->page_enc_bmap_size); >> + kvfree(sev->page_enc_bmap); >> + >> + sev->page_enc_bmap = map; >> + sev->page_enc_bmap_size = new_size; >> + >> + return 0; >> +} >> + >> +static int svm_page_enc_status_hc(struct kvm *kvm, unsigned long gpa, >> + unsigned long npages, unsigned long enc) >> +{ >> + struct kvm_sev_info *sev = &to_kvm_svm(kvm)->sev_info; >> + gfn_t gfn_start, gfn_end; >> + int r; > > int ret; ? "r" at first confused me. I will fix it in next rev. > >> + >> + if (!npages) >> + return 0; >> + >> + gfn_start = gpa_to_gfn(gpa); >> + gfn_end = gfn_start + npages; >> + >> + mutex_lock(&kvm->lock); >> + >> + r = 1; >> + if (sev_resize_page_enc_bitmap(kvm, gfn_end)) > > ret = sev_resize_... > if (ret) > >> + goto unlock; >> + >> + if (enc) >> + __bitmap_set(sev->page_enc_bmap, gfn_start, gfn_end - gfn_start); >> + else >> + __bitmap_clear(sev->page_enc_bmap, gfn_start, gfn_end - gfn_start); >> + >> + r = 0; > > If you do the above, this is not needed. > Yes agreed. thanks
WARNING: multiple messages have this Message-ID (diff)
From: "Singh, Brijesh" <brijesh.singh@amd.com> To: "Lendacky, Thomas" <Thomas.Lendacky@amd.com>, "kvm@vger.kernel.org" <kvm@vger.kernel.org> Cc: "Singh, Brijesh" <brijesh.singh@amd.com>, "Radim Krčmář" <rkrcmar@redhat.com>, "Joerg Roedel" <joro@8bytes.org>, "x86@kernel.org" <x86@kernel.org>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "Ingo Molnar" <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>, "Paolo Bonzini" <pbonzini@redhat.com>, "Thomas Gleixner" <tglx@linutronix.de>, "Borislav Petkov" <bp@suse.de> Subject: Re: [Qemu-devel] [RFC PATCH v1 08/10] KVM: X86: Introduce KVM_HC_PAGE_ENC_STATUS hypercall Date: Fri, 3 May 2019 14:25:04 +0000 [thread overview] Message-ID: <0f120899-c4fb-724a-00f9-997c362efd37@amd.com> (raw) Message-ID: <20190503142504.1pf1LEo3MATyjgLd5e_ucSBn7ApP7m188G2co0_70Uc@z> (raw) In-Reply-To: <d31531fe-f01c-817b-06e5-f06b5968b266@amd.com> On 4/26/19 4:39 PM, Lendacky, Thomas wrote: > On 4/24/19 11:10 AM, Singh, Brijesh wrote: >> The hypercall can be used by the SEV guest to notify the page encryption > > This hyercall is used by the SEV guest to notify a change in the page... > >> status to the hypervisor. The hypercall should be invoked only when >> the encryption attribute is changed from encrypted -> decrypted and vice >> versa. By default all the guest pages should be considered encrypted. > > By default all guest page are considered > >> >> Cc: Thomas Gleixner <tglx@linutronix.de> >> Cc: Ingo Molnar <mingo@redhat.com> >> Cc: "H. Peter Anvin" <hpa@zytor.com> >> Cc: Paolo Bonzini <pbonzini@redhat.com> >> Cc: "Radim Krčmář" <rkrcmar@redhat.com> >> Cc: Joerg Roedel <joro@8bytes.org> >> Cc: Borislav Petkov <bp@suse.de> >> Cc: Tom Lendacky <thomas.lendacky@amd.com> >> Cc: x86@kernel.org >> Cc: kvm@vger.kernel.org >> Cc: linux-kernel@vger.kernel.org >> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> >> --- >> Documentation/virtual/kvm/hypercalls.txt | 14 +++++ >> arch/x86/include/asm/kvm_host.h | 2 + >> arch/x86/kvm/svm.c | 69 ++++++++++++++++++++++++ >> arch/x86/kvm/vmx/vmx.c | 1 + >> arch/x86/kvm/x86.c | 5 ++ >> include/uapi/linux/kvm_para.h | 1 + >> 6 files changed, 92 insertions(+) >> >> diff --git a/Documentation/virtual/kvm/hypercalls.txt b/Documentation/virtual/kvm/hypercalls.txt >> index da24c138c8d1..ecd44e488679 100644 >> --- a/Documentation/virtual/kvm/hypercalls.txt >> +++ b/Documentation/virtual/kvm/hypercalls.txt >> @@ -141,3 +141,17 @@ a0 corresponds to the APIC ID in the third argument (a2), bit 1 >> corresponds to the APIC ID a2+1, and so on. >> >> Returns the number of CPUs to which the IPIs were delivered successfully. >> + >> +7. KVM_HC_PAGE_ENC_STATUS >> +------------------------- >> +Architecture: x86 >> +Status: active >> +Purpose: Notify the encryption status changes in guest page table (SEV guest) >> + >> +a0: the guest physical address of the start page >> +a1: the number of pages >> +a2: set or clear the encryption attribute > > a2: encryption attribute > >> + >> + Where: >> + * 1: Encryption attribute is set >> + * 0: Encryption attribute is cleared >> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h >> index a9d03af34030..adb0ca035b97 100644 >> --- a/arch/x86/include/asm/kvm_host.h >> +++ b/arch/x86/include/asm/kvm_host.h >> @@ -1196,6 +1196,8 @@ struct kvm_x86_ops { >> uint16_t (*nested_get_evmcs_version)(struct kvm_vcpu *vcpu); >> >> bool (*need_emulation_on_page_fault)(struct kvm_vcpu *vcpu); >> + int (*page_enc_status_hc)(struct kvm *kvm, unsigned long gpa, >> + unsigned long sz, unsigned long mode); >> }; >> >> struct kvm_arch_async_pf { >> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c >> index 74b57ab742ad..f024f208b052 100644 >> --- a/arch/x86/kvm/svm.c >> +++ b/arch/x86/kvm/svm.c >> @@ -138,6 +138,8 @@ struct kvm_sev_info { >> int fd; /* SEV device fd */ >> unsigned long pages_locked; /* Number of pages locked */ >> struct list_head regions_list; /* List of registered regions */ >> + unsigned long *page_enc_bmap; >> + unsigned long page_enc_bmap_size; >> }; >> >> struct kvm_svm { >> @@ -1911,6 +1913,8 @@ static void sev_vm_destroy(struct kvm *kvm) >> >> sev_unbind_asid(kvm, sev->handle); >> sev_asid_free(kvm); >> + >> + kvfree(sev->page_enc_bmap); >> } >> >> static void avic_vm_destroy(struct kvm *kvm) >> @@ -7370,6 +7374,69 @@ static int sev_receive_finish(struct kvm *kvm, struct kvm_sev_cmd *argp) >> return ret; >> } >> >> +static int sev_resize_page_enc_bitmap(struct kvm *kvm, unsigned long new_size) >> +{ >> + struct kvm_sev_info *sev = &to_kvm_svm(kvm)->sev_info; >> + unsigned long *map; >> + unsigned long sz; >> + >> + if (sev->page_enc_bmap_size >= new_size) >> + return 0; >> + >> + sz = ALIGN(new_size, BITS_PER_LONG) / 8; >> + >> + if (sz > PAGE_SIZE) >> + map = vmalloc(sz); >> + else >> + map = kmalloc(sz, GFP_KERNEL); > > Any reason this can't always be vmalloc()? > Yes, we can use vmalloc() unconditionally. The bitmap size will be mostly greater than PAGE_SIZE hence the above is useless anyway. >> + >> + if (!map) { >> + pr_err_once("Failed to allocate decrypted bitmap size %lx\n", sz); >> + return 1; > > Should this be -ENOMEM? > >> + } >> + >> + /* mark the page encrypted (by default) */ >> + memset(map, 0xff, sz); >> + >> + bitmap_copy(map, sev->page_enc_bmap, sev->page_enc_bmap_size); >> + kvfree(sev->page_enc_bmap); >> + >> + sev->page_enc_bmap = map; >> + sev->page_enc_bmap_size = new_size; >> + >> + return 0; >> +} >> + >> +static int svm_page_enc_status_hc(struct kvm *kvm, unsigned long gpa, >> + unsigned long npages, unsigned long enc) >> +{ >> + struct kvm_sev_info *sev = &to_kvm_svm(kvm)->sev_info; >> + gfn_t gfn_start, gfn_end; >> + int r; > > int ret; ? "r" at first confused me. I will fix it in next rev. > >> + >> + if (!npages) >> + return 0; >> + >> + gfn_start = gpa_to_gfn(gpa); >> + gfn_end = gfn_start + npages; >> + >> + mutex_lock(&kvm->lock); >> + >> + r = 1; >> + if (sev_resize_page_enc_bitmap(kvm, gfn_end)) > > ret = sev_resize_... > if (ret) > >> + goto unlock; >> + >> + if (enc) >> + __bitmap_set(sev->page_enc_bmap, gfn_start, gfn_end - gfn_start); >> + else >> + __bitmap_clear(sev->page_enc_bmap, gfn_start, gfn_end - gfn_start); >> + >> + r = 0; > > If you do the above, this is not needed. > Yes agreed. thanks
next prev parent reply other threads:[~2019-05-03 14:25 UTC|newest] Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-04-24 16:09 [Qemu-devel] [RFC PATCH v1 00/10] Add AMD SEV guest live migration support Singh, Brijesh 2019-04-24 16:09 ` Singh, Brijesh 2019-04-24 16:09 ` [Qemu-devel] [RFC PATCH v1 01/10] KVM: SVM: Add KVM_SEV SEND_START command Singh, Brijesh 2019-04-24 16:09 ` Singh, Brijesh 2019-04-26 14:10 ` Borislav Petkov 2019-04-26 14:10 ` Borislav Petkov 2019-04-26 14:29 ` Singh, Brijesh 2019-04-26 14:29 ` Singh, Brijesh 2019-04-26 20:43 ` Borislav Petkov 2019-04-26 20:43 ` Borislav Petkov 2019-04-29 15:01 ` Singh, Brijesh 2019-04-29 15:01 ` Singh, Brijesh 2019-04-29 16:36 ` Borislav Petkov 2019-04-29 16:36 ` Borislav Petkov 2019-04-29 16:43 ` Singh, Brijesh 2019-04-29 16:43 ` Singh, Brijesh 2019-04-24 16:10 ` [Qemu-devel] [RFC PATCH v1 02/10] KVM: SVM: Add KVM_SEND_UPDATE_DATA command Singh, Brijesh 2019-04-24 16:10 ` Singh, Brijesh 2019-04-26 20:31 ` Lendacky, Thomas 2019-04-26 20:31 ` Lendacky, Thomas 2019-04-29 16:54 ` Singh, Brijesh 2019-04-29 16:54 ` Singh, Brijesh 2019-04-24 16:10 ` [Qemu-devel] [RFC PATCH v1 03/10] KVM: SVM: Add KVM_SEV_SEND_FINISH command Singh, Brijesh 2019-04-24 16:10 ` Singh, Brijesh 2019-04-24 16:10 ` [Qemu-devel] [RFC PATCH v1 04/10] KVM: SVM: Add support for KVM_SEV_RECEIVE_START command Singh, Brijesh 2019-04-24 16:10 ` Singh, Brijesh 2019-04-26 21:08 ` Lendacky, Thomas 2019-04-26 21:08 ` Lendacky, Thomas 2019-04-24 16:10 ` [Qemu-devel] [RFC PATCH v1 05/10] KVM: SVM: Add KVM_SEV_RECEIVE_UPDATE_DATA command Singh, Brijesh 2019-04-24 16:10 ` Singh, Brijesh 2019-04-26 21:11 ` Lendacky, Thomas 2019-04-26 21:11 ` Lendacky, Thomas 2019-04-24 16:10 ` [Qemu-devel] [RFC PATCH v1 06/10] KVM: SVM: Add KVM_SEV_RECEIVE_FINISH command Singh, Brijesh 2019-04-24 16:10 ` Singh, Brijesh 2019-04-26 21:11 ` Lendacky, Thomas 2019-04-26 21:11 ` Lendacky, Thomas 2019-04-24 16:10 ` [Qemu-devel] [RFC PATCH v1 07/10] KVM: x86: Add AMD SEV specific Hypercall3 Singh, Brijesh 2019-04-24 16:10 ` Singh, Brijesh 2019-04-24 16:10 ` [Qemu-devel] [RFC PATCH v1 08/10] KVM: X86: Introduce KVM_HC_PAGE_ENC_STATUS hypercall Singh, Brijesh 2019-04-24 16:10 ` Singh, Brijesh 2019-04-26 21:39 ` Lendacky, Thomas 2019-04-26 21:39 ` Lendacky, Thomas 2019-05-03 14:25 ` Singh, Brijesh [this message] 2019-05-03 14:25 ` Singh, Brijesh 2019-04-24 16:10 ` [Qemu-devel] [RFC PATCH v1 09/10] KVM: x86: Introduce KVM_GET_PAGE_ENC_BITMAP ioctl Singh, Brijesh 2019-04-24 16:10 ` Singh, Brijesh 2019-04-24 16:10 ` [Qemu-devel] [RFC PATCH v1 10/10] mm: x86: Invoke hypercall when page encryption status is changed Singh, Brijesh 2019-04-24 16:10 ` Singh, Brijesh 2019-04-24 19:15 ` [Qemu-devel] [RFC PATCH v1 00/10] Add AMD SEV guest live migration support Steve Rutherford 2019-04-24 19:15 ` Steve Rutherford via Qemu-devel 2019-04-24 21:32 ` Singh, Brijesh 2019-04-24 21:32 ` Singh, Brijesh 2019-04-25 0:18 ` Steve Rutherford 2019-04-25 0:18 ` Steve Rutherford via Qemu-devel 2019-04-25 2:15 ` Singh, Brijesh 2019-04-25 2:15 ` Singh, Brijesh
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=0f120899-c4fb-724a-00f9-997c362efd37@amd.com \ --to=brijesh.singh@amd.com \ --cc=Thomas.Lendacky@amd.com \ --cc=bp@suse.de \ --cc=hpa@zytor.com \ --cc=joro@8bytes.org \ --cc=kvm@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mingo@redhat.com \ --cc=pbonzini@redhat.com \ --cc=qemu-devel@nongnu.org \ --cc=rkrcmar@redhat.com \ --cc=tglx@linutronix.de \ --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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).