On 10/19/19 3:59 AM, David Rientjes wrote:
> On Thu, 17 Oct 2019, Kalra, Ashish wrote:
>
>> From: Ashish Kalra
>>
>> SEV INIT command loads the SEV related persistent data from NVS
>> and initializes the platform context. The firmware validates the
>> persistent state. If validation fails, the
On 8/29/19 11:26 AM, Borislav Petkov wrote:
> On Wed, Jul 10, 2019 at 08:13:10PM +0000, Singh, Brijesh wrote:
>> @@ -7767,7 +7808,8 @@ static struct kvm_x86_ops svm_x86_ops __ro_after_init
>> = {
>>
>> .need_emulation_on_page_fault = svm_n
On 8/22/19 7:02 AM, Borislav Petkov wrote:
> On Wed, Jul 10, 2019 at 08:13:01PM +0000, Singh, Brijesh wrote:
>> The command is used for encrypting the guest memory region using the
>> encryption
>> context created with KVM_SEV_SEND_START.
>>
>> Cc: Thomas Gleixn
On 8/22/19 5:08 AM, Borislav Petkov wrote:
> On Wed, Jul 10, 2019 at 08:13:00PM +0000, Singh, Brijesh wrote:
>> The command is used to create an outgoing SEV guest encryption context.
>>
>> Cc: Thomas Gleixner
>> Cc: Ingo Molnar
>> Cc: "H. Peter Anvin
Good point. I will add a check for it, something like
if (gfn_end <= gfn_start)
return -EINVAL;
>
> On Sun, Jul 21, 2019 at 1:57 PM David Rientjes wrote:
>>
>> On Wed, 10 Jul 2019, Singh, Brijesh wrote:
>>
>>> diff --git a/Documentation/virtual/kvm/hyperc
On 7/21/19 3:57 PM, David Rientjes wrote:
> On Wed, 10 Jul 2019, Singh, Brijesh wrote:
>
>> diff --git a/Documentation/virtual/kvm/hypercalls.txt
>> b/Documentation/virtual/kvm/hypercalls.txt
>> index da24c138c8d1..94f0611f4d88 100644
>> --- a/Documentation/virtu
The command finalize the guest receiving process and make the SEV guest
ready for the execution.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Joerg Roedel
Cc: Borislav Petkov
Cc: Tom Lendacky
Cc: x...@kernel.org
Cc: k...@vger.kernel.org
This hypercall is used by the SEV guest to notify a change in the page
encryption 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 guest pages are considered encrypted.
Cc: Thomas
The command is used for copying the incoming buffer into the
SEV guest memory space.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Joerg Roedel
Cc: Borislav Petkov
Cc: Tom Lendacky
Cc: x...@kernel.org
Cc: k...@vger.kernel.org
Cc:
Invoke a hypercall when a memory region is changed from encrypted ->
decrypted and vice versa. Hypervisor need to know the page encryption
status during the guest migration.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Joerg Roedel
Cc:
The command is used for encrypting the guest memory region using the encryption
context created with KVM_SEV_SEND_START.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Joerg Roedel
Cc: Borislav Petkov
Cc: Tom Lendacky
Cc: x...@kernel.org
The ioctl can be used to set page encryption bitmap for an
incoming guest.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Joerg Roedel
Cc: Borislav Petkov
Cc: Tom Lendacky
Cc: x...@kernel.org
Cc: k...@vger.kernel.org
Cc:
The ioctl can be used to retrieve page encryption bitmap for a given
gfn range.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Joerg Roedel
Cc: Borislav Petkov
Cc: Tom Lendacky
Cc: x...@kernel.org
Cc: k...@vger.kernel.org
Cc:
KVM hypercall framework relies on alternative framework to patch the
VMCALL -> VMMCALL on AMD platform. If a hypercall is made before
apply_alternative() is called then it defaults to VMCALL. The approach
works fine on non SEV guest. A VMCALL would causes #UD, and hypervisor
will be able to decode
The command is used to create an outgoing SEV guest encryption context.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Joerg Roedel
Cc: Borislav Petkov
Cc: Tom Lendacky
Cc: x...@kernel.org
Cc: k...@vger.kernel.org
Cc:
The command is used to create the encryption context for an incoming
SEV guest. The encryption context can be later used by the hypervisor
to import the incoming data into the SEV guest memory space.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
The command is used to finailize the encryption context created with
KVM_SEV_SEND_START command.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Joerg Roedel
Cc: Borislav Petkov
Cc: Tom Lendacky
Cc: x...@kernel.org
Cc: k...@vger.kernel.org
The command finalize the guest receiving process and make the SEV guest
ready for the execution.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Joerg Roedel
Cc: Borislav Petkov
Cc: Tom Lendacky
Cc: x...@kernel.org
Cc: k...@vger.kernel.org
KVM hypercall framework relies on alternative framework to patch the
VMCALL -> VMMCALL on AMD platform. If a hypercall is made before
apply_alternative() is called then it defaults to VMCALL. The approach
works fine on non SEV guest. A VMCALL would causes #UD, and hypervisor
will be able to decode
The command is used to finailize the encryption context created with
KVM_SEV_SEND_START command.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Joerg Roedel
Cc: Borislav Petkov
Cc: Tom Lendacky
Cc: x...@kernel.org
Cc: k...@vger.kernel.org
The command is used to create an outgoing SEV guest encryption context.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Joerg Roedel
Cc: Borislav Petkov
Cc: Tom Lendacky
Cc: x...@kernel.org
Cc: k...@vger.kernel.org
Cc:
The command is used for copying the incoming buffer into the
SEV guest memory space.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Joerg Roedel
Cc: Borislav Petkov
Cc: Tom Lendacky
Cc: x...@kernel.org
Cc: k...@vger.kernel.org
Cc:
The ioctl can be used to set page encryption bitmap for an
incoming guest.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Joerg Roedel
Cc: Borislav Petkov
Cc: Tom Lendacky
Cc: x...@kernel.org
Cc: k...@vger.kernel.org
Cc:
Invoke a hypercall when a memory region is changed from encrypted ->
decrypted and vice versa. Hypervisor need to know the page encryption
status during the guest migration.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Joerg Roedel
Cc:
The command is used to create the encryption context for an incoming
SEV guest. The encryption context can be later used by the hypervisor
to import the incoming data into the SEV guest memory space.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
This hypercall is used by the SEV guest to notify a change in the page
encryption 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 guest pages are considered encrypted.
Cc: Thomas
The ioctl can be used to retrieve page encryption bitmap for a given
gfn range.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Joerg Roedel
Cc: Borislav Petkov
Cc: Tom Lendacky
Cc: x...@kernel.org
Cc: k...@vger.kernel.org
Cc:
The command is used for encrypting the guest memory region using the encryption
context created with KVM_SEV_SEND_START.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Joerg Roedel
Cc: Borislav Petkov
Cc: Tom Lendacky
Cc: x...@kernel.org
Hi Boris,
On 4/17/19 12:24 PM, Dave Hansen wrote:
...
>
> The comment here is missing one key point:
> kernel_physical_mapping_init() can only be used to populate non-present
> entries. It kinda infers that from "Create...", but I really think we
> need to be explicit.
>
> Anyway, it's better
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 hypervis
The following commit 0a9fe8ca844d ("x86/mm: Validate
kernel_physical_mapping_init()
PTE population") triggers the below warning in the SEV guest.
WARNING: CPU: 0 PID: 0 at arch/x86/include/asm/pgalloc.h:87
phys_pmd_init+0x30d/0x386
Call Trace:
kernel_physical_mapping_init+0xce/0x259
On 4/15/19 11:14 AM, Peter Zijlstra wrote:
> On Mon, Apr 15, 2019 at 08:58:52AM -0700, Dave Hansen wrote:
>> On 4/15/19 7:55 AM, Singh, Brijesh wrote:
>>> static unsigned long __meminit
>>> phys_pte_init(pte_t *pte_page, unsigned long paddr, u
The following commit 0a9fe8ca844d ("x86/mm: Validate
kernel_physical_mapping_init()
PTE population") triggers the below warning in the SEV guest.
WARNING: CPU: 0 PID: 0 at arch/x86/include/asm/pgalloc.h:87
phys_pmd_init+0x30d/0x386
Call Trace:
kernel_physical_mapping_init+0xce/0x259
On 4/9/19 4:39 AM, Peter Zijlstra wrote:
> On Tue, Apr 09, 2019 at 10:40:31AM +0200, Peter Zijlstra wrote:
>> On Mon, Apr 08, 2019 at 07:11:21PM +0000, Singh, Brijesh wrote:
>>> The following commit 0a9fe8ca844d ("x86/mm: Validate
>>> kernel_physical_mapping_init
The following commit 0a9fe8ca844d ("x86/mm: Validate
kernel_physical_mapping_init()
PTE population") triggers the below warning in the SEV guest.
WARNING: CPU: 0 PID: 0 at arch/x86/include/asm/pgalloc.h:87
phys_pmd_init+0x30d/0x386
Call Trace:
kernel_physical_mapping_init+0xce/0x259
Hi Paolo and Radim,
On 2/1/19 10:47 AM, Singh, Brijesh wrote:
> svm.c is pretty huge, before we add more SEV specific commands (e.g SEV-ES,
> SEV-Migration etc) lets move the SEV command handling into a separate file.
> There is no logical changes in this series.
>
Any thoughts on
On 3/25/19 1:47 PM, David Rientjes wrote:
> This ensures that the address and length provided to DBG_DECRYPT and
> DBG_ENCRYPT do not cause an overflow.
>
> At the same time, pass the actual number of pages pinned in memory to
> sev_unpin_memory() as a cleanup.
>
> Reported-by: Cfir Cohen
>
On 3/19/19 5:19 PM, David Rientjes wrote:
> get_num_contig_pages() could potentially overflow int so make its type
> consistent with its usage.
>
> Reported-by: Cfir Cohen
> Signed-off-by: David Rientjes
> ---
> arch/x86/kvm/svm.c | 10 +-
> 1 file changed, 5 insertions(+), 5
On 2/14/19 3:08 PM, Nathaniel McCallum wrote:
> I've been working on wrapping various SEV kernel APIs for userspace
> consumption. There does not appear to be any privilege separation for
> these commands: you can run them all or none of them. This is less
> than ideal because it means that a
On 2/21/19 10:37 PM, Herbert Xu wrote:
> On Thu, Feb 14, 2019 at 07:33:29PM +0000, Singh, Brijesh wrote:
>>
>>
>> On 2/14/19 10:57 AM, Nathaniel McCallum wrote:
>>> I'm a little concerned that this immediately disables SEV_GET_ID.
>>> IMHO, we should contin
he case and it can
> probably be worked around on the server side.
>
> On Wed, Feb 13, 2019 at 1:24 PM Singh, Brijesh wrote:
>>
>> The current definition and implementation of the SEV_GET_ID command
>> does not provide the length of the unique ID returned by the firmware.
>&
The current definition and implementation of the SEV_GET_ID command
does not provide the length of the unique ID returned by the firmware.
As per the firmware specification, the firmware may return an ID
length that is not restricted to 64 bytes as assumed by the SEV_GET_ID
command.
Introduce the
On 2/1/19 2:21 PM, Jim Mattson wrote:
> On Mon, Dec 4, 2017 at 5:07 PM Brijesh Singh wrote:
>>
>> On AMD platforms, under certain conditions insn_len may be zero on #NPF.
>> This can happen if a guest gets a page-fault on data access but the HW
>> table walker is not able to read the
On 2/1/19 12:20 PM, Sean Christopherson wrote:
> On Fri, Feb 01, 2019 at 04:47:12PM +0000, Singh, Brijesh wrote:
>> svm.c is pretty huge, before we add more SEV specific commands (e.g SEV-ES,
>> SEV-Migration etc) lets move the SEV command handling into a separate file.
>>
svm.c was pretty huge, and the recent addition of SEV feature
grew it further. Before we add more SEV command handling lets split
the SEV bits into a separate file. The sev.c will be compiled only
when CONFIG_KVM_AMD_SEV is selected.
Signed-off-by: Brijesh Singh
Cc: Borislav Petkov
Cc: Paolo
Some of the structure will be used by sev.c in next patch, lets
move the common structure definition in svm.h so that both the
sev.c and svm.c can use it.
Signed-off-by: Brijesh Singh
Cc: Borislav Petkov
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Joerg Roedel
Cc: Tom Lendacky
---
svm.c is pretty huge, before we add more SEV specific commands (e.g SEV-ES,
SEV-Migration etc) lets move the SEV command handling into a separate file.
There is no logical changes in this series.
The patch is based on motivation from this thread:
A kexec reboot may leave the firmware in INIT or WORKING state.
Currently, we issue PLATFORM_INIT command during the probe without
checking the current state. The PLATFORM_INIT command fails if the
FW is already in INIT state. Lets check the current state, if FW
is not in UNINIT state then
On 1/14/19 12:20 PM, Michael S. Tsirkin wrote:
> On Mon, Jan 14, 2019 at 08:41:37PM +0800, Jason Wang wrote:
>>
>> On 2019/1/14 下午5:50, Christoph Hellwig wrote:
>>> On Mon, Jan 14, 2019 at 05:41:56PM +0800, Jason Wang wrote:
On 2019/1/11 下午5:15, Joerg Roedel wrote:
> On Fri, Jan 11,
On 1/2/19 2:56 PM, David Rientjes wrote:
> By code inspection, it was found that multiple calls to KVM_SEV_INIT
> could deplete asid bits and overwrite kvm_sev_info's regions_list.
>
> Multiple calls to KVM_SVM_INIT is not likely to occur with QEMU, but this
> should likely be fixed anyway.
>
On 10/08/2018 06:27 AM, Paolo Bonzini wrote:
> On 06/10/2018 22:43, Guenter Roeck wrote:
>>>
> Maybe this works as well? I haven't tested it yet:
>
I am sure there are many possible solutions. I would personally
prefer one
that enforces KVM_AMD=m with CRYPTO_DEV_CCP_DD=m,
On 10/08/2018 06:27 AM, Paolo Bonzini wrote:
> On 06/10/2018 22:43, Guenter Roeck wrote:
>>>
> Maybe this works as well? I haven't tested it yet:
>
I am sure there are many possible solutions. I would personally
prefer one
that enforces KVM_AMD=m with CRYPTO_DEV_CCP_DD=m,
52 matches
Mail list logo
