On 8/8/19 5:48 AM, Dr. David Alan Gilbert wrote:
> * Singh, Brijesh (brijesh.si...@amd.com) wrote:
>> On 8/7/19 6:06 AM, Dr. David Alan Gilbert wrote:
>>> * Singh, Brijesh (brijesh.si...@amd.com) wrote:
>>>> AMD SEV migration flow requires that target machine's
On 8/7/19 11:14 AM, Dr. David Alan Gilbert wrote:
> * Singh, Brijesh (brijesh.si...@amd.com) wrote:
>> To enable a memory encryption inside a VM, user must pass the object
>> name used for the encryption in command line parameter as shown below.
>>
>> # $(QEMU) \
>
On 8/7/19 6:06 AM, Dr. David Alan Gilbert wrote:
> * Singh, Brijesh (brijesh.si...@amd.com) wrote:
>> AMD SEV migration flow requires that target machine's public Diffie-Hellman
>> key (PDH) and certificate chain must be passed before initiating the guest
>> migration.
The SEV VMs have concept of private and shared memory. The private memory
is encrypted with guest-specific key, while shared memory may be encrypted
with hyperivosr key. The KVM_GET_PAGE_ENC_BITMAP can be used to get a
bitmap indicating whether the guest page is private or shared. A private
page mu
Reviewed-by: Dr. David Alan Gilbert
Signed-off-by: Brijesh Singh
---
target/i386/sev.c | 12
1 file changed, 12 deletions(-)
diff --git a/target/i386/sev.c b/target/i386/sev.c
index 9d643e720c..72b841a458 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -34,7 +34,6 @@
#de
When memory encryption is enabled, the guest memory will be encrypted with
the guest specific key. The patch introduces RAM_SAVE_FLAG_ENCRYPTED_PAGE
flag to distinguish the encrypted data from plaintext. Encrypted pages
may need special handling. The kvm_memcrypt_save_outgoing_page() is used
by the
When memory encryption is enabled in VM, the guest RAM will be encrypted
with the guest-specific key, to protect the confidentiality of data while
in transit we need to platform specific hooks to save or migrate the
guest RAM. The MemoryEncryptionOps introduced in this patch will be later
used by t
The sev_save_outgoing_page() provide the implementation to encrypt the
guest private pages during the transit. The routines uses the SEND_START
command to create the outgoing encryption context on the first call then
uses the SEND_UPDATE_DATA command to encrypt the data before writing it
to the soc
AMD SEV migration flow requires that target machine's public Diffie-Hellman
key (PDH) and certificate chain must be passed before initiating the guest
migration. User can use QMP 'migrate-set-parameters' to pass the certificate
chain. The certificate chain will be used while creating the outgoing
e
When memory encryption is enabled, the hypervisor maintains a page
encryption bitmap which is referred by hypervisor during migratoin to check
if page is private or shared. The bitmap is built during the VM bootup and
must be migrated to the target host so that hypervisor on target host can
use it
The sev_load_incoming_page() provide the implementation to read the
incoming guest private pages from the socket and load it into the guest
memory. The routines uses the RECEIVE_START command to create the
incoming encryption context on the first call then uses the
RECEIEVE_UPDATE_DATA command to l
The LAUNCH_START is used for creating an encryption context to encrypt
newly created guest, for an incoming guest the RECEIVE_START should be
used.
Reviewed-by: Dr. David Alan Gilbert
Signed-off-by: Brijesh Singh
---
target/i386/sev.c | 14 ++
1 file changed, 10 insertions(+), 4 del
The user provides the target machine's Platform Diffie-Hellman key (PDH)
and certificate chain before starting the SEV guest migration. Cache the
certificate chain as we need them while creating the outgoing context.
Signed-off-by: Brijesh Singh
---
accel/kvm/kvm-all.c| 12 +++
accel
Signed-off-by: Brijesh Singh
---
linux-headers/linux/kvm.h | 53 +++
1 file changed, 53 insertions(+)
diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
index c8423e760c..2b0a2a97b8 100644
--- a/linux-headers/linux/kvm.h
+++ b/linux-headers/lin
Signed-off-by: Brijesh Singh
---
docs/amd-memory-encryption.txt | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/docs/amd-memory-encryption.txt b/docs/amd-memory-encryption.txt
index 43bf3ee6a5..8822cadda1 100644
--- a/docs/amd-memory-encryption.txt
+++ b/docs/amd-memor
Signed-off-by: Brijesh Singh
---
docs/amd-memory-encryption.txt | 40 +-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/docs/amd-memory-encryption.txt b/docs/amd-memory-encryption.txt
index 8822cadda1..01d95089a8 100644
--- a/docs/amd-memory-encrypti
To enable a memory encryption inside a VM, user must pass the object
name used for the encryption in command line parameter as shown below.
# $(QEMU) \
-machine memory-encryption=
Add a helper machine_memory_encryption_enabled() which will return a bool
indicating whether the encryption object
AMD SEV encrypts the memory of VMs and because this encryption is done using
an address tweak, the hypervisor will not be able to simply copy ciphertext
between machines to migrate a VM. Instead the AMD SEV Key Management API
provides a set of functions which the hypervisor can use to package a
gue
On 7/24/19 2:42 PM, Alex Williamson wrote:
> On Wed, 24 Jul 2019 08:43:55 -0600
> Alex Williamson wrote:
>
>> On Wed, 24 Jul 2019 18:03:31 +0800
>> Peter Xu wrote:
>>
>>> On Wed, Jul 24, 2019 at 05:39:22AM -0400, Michael S. Tsirkin wrote:
On Wed, Jul 24, 2019 at 03:14:39PM +0800, Peter Xu
On 7/16/19 6:44 AM, Dr. David Alan Gilbert wrote:
> * Singh, Brijesh (brijesh.si...@amd.com) wrote:
>>
>>
>> On 7/11/19 2:05 PM, Dr. David Alan Gilbert wrote:
>>> * Singh, Brijesh (brijesh.si...@amd.com) wrote:
>>>> The SEV VMs have concept of pri
On 7/15/19 9:28 AM, Alex Williamson wrote:
> The commit referenced below skipped pinning ram device memory when
> ram blocks are added, we need to do the same when they're removed.
>
> Cc: Brijesh Singh
> Cc: Paolo Bonzini
> Fixes: cedc0ad539af ("target/i386: sev: Do not pin the ram device mem
On 7/12/19 4:27 AM, Dr. David Alan Gilbert wrote:
[snip]
>>>
>>> OK, that's our very last usable flag! Use it wisely!
>>>
>>
>> Hmm, maybe then I missed something. I thought the flag is 64-bit and
>> we have more room. Did I miss something ?
>
> The 64bit value written in the stream is
>(
On 7/12/19 6:30 AM, Dr. David Alan Gilbert wrote:
> * Singh, Brijesh (brijesh.si...@amd.com) wrote:
>> When memory encryption is enabled, the hypervisor maintains a page
>> encryption bitmap which is referred by hypervisor during migratoin to check
>> if page is private or
On 7/12/19 6:02 AM, Dr. David Alan Gilbert wrote:
> * Singh, Brijesh (brijesh.si...@amd.com) wrote:
>> The sev_load_incoming_page() provide the implementation to read the
>> incoming guest private pages from the socket and load it into the guest
>> memory. The routines u
On 7/12/19 5:43 AM, Dr. David Alan Gilbert wrote:
> * Singh, Brijesh (brijesh.si...@amd.com) wrote:
>> The sev_save_outgoing_page() provide the implementation to encrypt the
>> guest private pages during the transit. The routines uses the SEND_START
>> command to create th
On 7/12/19 5:09 AM, Daniel P. Berrangé wrote:
> On Fri, Jul 12, 2019 at 11:00:22AM +0100, Dr. David Alan Gilbert wrote:
>> * Singh, Brijesh (brijesh.si...@amd.com) wrote:
>>> The command can be used by the hypervisor to specify the target Platform
>>> Diffie-Hellma
On 7/11/19 2:05 PM, Dr. David Alan Gilbert wrote:
> * Singh, Brijesh (brijesh.si...@amd.com) wrote:
>> The SEV VMs have concept of private and shared memory. The private memory
>> is encrypted with guest-specific key, while shared memory may be encrypted
>> wit
On 7/11/19 1:06 PM, Dr. David Alan Gilbert wrote:
> * Singh, Brijesh (brijesh.si...@amd.com) wrote:
>> Signed-off-by: Brijesh Singh
>> ---
>> docs/amd-memory-encryption.txt | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/do
On 7/11/19 12:47 PM, Dr. David Alan Gilbert wrote:
> * Singh, Brijesh (brijesh.si...@amd.com) wrote:
>> When memory encryption is enabled in VM, the guest pages will be
>> encrypted with the guest-specific key, to protect the confidentiality
>> of data in transit. To suppo
On 7/11/19 4:59 AM, Dr. David Alan Gilbert wrote:
> * Singh, Brijesh (brijesh.si...@amd.com) wrote:
>> AMD SEV encrypts the memory of VMs and because this encryption is done using
>> an address tweak, the hypervisor will not be able to simply copy ciphertext
>> between mac
On 7/11/19 12:34 PM, Dr. David Alan Gilbert wrote:
> * Singh, Brijesh (brijesh.si...@amd.com) wrote:
>> When memory encryption is enabled, the guest memory will be encrypted with
>> the guest specific key. The patch introduces RAM_SAVE_FLAG_ENCRYPTED_PAGE
>> flag to dist
When memory encryption is enabled, the hypervisor maintains a page
encryption bitmap which is referred by hypervisor during migratoin to check
if page is private or shared. The bitmap is built during the VM bootup and
must be migrated to the target host so that hypervisor on target host can
use it
Encrypted VMs have concept of private and shared memory. The private
memory is encrypted with the guest-specific key, while shared memory
may be encrypted with hyperivosr key. The guest OS uses a hypercall
to notify the page encryption state to the hypervisor. The hypervisor
maintain a bitmap of pa
The sev_load_incoming_page() provide the implementation to read the
incoming guest private pages from the socket and load it into the guest
memory. The routines uses the RECEIVE_START command to create the
incoming encryption context on the first call then uses the
RECEIEVE_UPDATE_DATA command to l
The command can be used by the hypervisor to specify the target Platform
Diffie-Hellman key (PDH) and certificate chain before starting the SEV
guest migration. The values passed through the command will be used while
creating the outgoing encryption context.
Signed-off-by: Brijesh Singh
---
qap
The SEV VMs have concept of private and shared memory. The private memory
is encrypted with guest-specific key, while shared memory may be encrypted
with hyperivosr key. The KVM_GET_PAGE_ENC_BITMAP can be used to get a
bitmap indicating whether the guest page is private or shared. A private
page mu
Signed-off-by: Brijesh Singh
---
docs/amd-memory-encryption.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/docs/amd-memory-encryption.txt b/docs/amd-memory-encryption.txt
index 43bf3ee6a5..abb9a976f5 100644
--- a/docs/amd-memory-encryption.txt
+++ b/docs/amd-memory-encryp
Signed-off-by: Brijesh Singh
---
docs/amd-memory-encryption.txt | 42 +-
1 file changed, 41 insertions(+), 1 deletion(-)
diff --git a/docs/amd-memory-encryption.txt b/docs/amd-memory-encryption.txt
index abb9a976f5..374f4b0a94 100644
--- a/docs/amd-memory-encrypti
Signed-off-by: Brijesh Singh
---
target/i386/sev.c | 12
1 file changed, 12 deletions(-)
diff --git a/target/i386/sev.c b/target/i386/sev.c
index 93c6a90806..48336515a2 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -34,7 +34,6 @@
#define DEFAULT_SEV_DEVICE "/dev/se
The sev_save_outgoing_page() provide the implementation to encrypt the
guest private pages during the transit. The routines uses the SEND_START
command to create the outgoing encryption context on the first call then
uses the SEND_UPDATE_DATA command to encrypt the data before writing it
to the soc
Signed-off-by: Brijesh Singh
---
linux-headers/linux/kvm.h | 53 +++
1 file changed, 53 insertions(+)
diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
index c8423e760c..2b0a2a97b8 100644
--- a/linux-headers/linux/kvm.h
+++ b/linux-headers/lin
The LAUNCH_START is used for creating an encryption context to encrypt
newly created guest, for an incoming guest the RECEIVE_START should be
used.
Signed-off-by: Brijesh Singh
---
target/i386/sev.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/target/i386/s
When memory encryption is enabled, the guest memory will be encrypted with
the guest specific key. The patch introduces RAM_SAVE_FLAG_ENCRYPTED_PAGE
flag to distinguish the encrypted data from plaintext. Encrypted pages
may need special handling. The kvm_memcrypt_save_outgoing_page() is used
by the
When memory encryption is enabled in VM, the guest pages will be
encrypted with the guest-specific key, to protect the confidentiality
of data in transit. To support the live migration we need to use
platform specific hooks to access the guest memory.
The kvm_memcrypt_save_outgoing_page() can be u
AMD SEV encrypts the memory of VMs and because this encryption is done using
an address tweak, the hypervisor will not be able to simply copy ciphertext
between machines to migrate a VM. Instead the AMD SEV Key Management API
provides a set of functions which the hypervisor can use to package a
gue
On 6/20/19 2:13 PM, Eric Blake wrote:
> On 6/20/19 1:03 PM, Singh, Brijesh wrote:
>> The command can be used by the hypervisor to specify the target Platform
>> Diffie-Hellman key (PDH) and certificate chain before starting the SEV
>> guest migration. The values passed thr
The sev_load_incoming_page() provide the implementation to read the
incoming guest private pages from the socket and load it into the guest
memory. The routines uses the RECEIVE_START command to create the
incoming encryption context on the first call then uses the
RECEIEVE_UPDATE_DATA command to l
When memory encryption is enabled, the guest memory will be encrypted with
the guest specific key. The patch introduces RAM_SAVE_FLAG_ENCRYPTED_PAGE
flag to distinguish the encrypted data from plaintext. Encrypted pages
may need special handling. The kvm_memcrypt_save_outgoing_page() is used
by the
Signed-off-by: Brijesh Singh
---
linux-headers/linux/kvm.h | 53 +++
1 file changed, 53 insertions(+)
diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
index c8423e760c..2bdd6a908e 100644
--- a/linux-headers/linux/kvm.h
+++ b/linux-headers/lin
The sev_save_outgoing_page() provide the implementation to encrypt the
guest private pages during the transit. The routines uses the SEND_START
command to create the outgoing encryption context on the first call then
uses the SEND_UPDATE_DATA command to encrypt the data before writing it
to the soc
Signed-off-by: Brijesh Singh
---
docs/amd-memory-encryption.txt | 44 +-
1 file changed, 43 insertions(+), 1 deletion(-)
diff --git a/docs/amd-memory-encryption.txt b/docs/amd-memory-encryption.txt
index abb9a976f5..757e0d931a 100644
--- a/docs/amd-memory-encrypti
When memory encryption is enabled in VM, the guest pages will be
encrypted with the guest-specific key, to protect the confidentiality
of data in transit. To support the live migration we need to use
platform specific hooks to access the guest memory.
The kvm_memcrypt_save_outgoing_page() can be u
Signed-off-by: Brijesh Singh
---
target/i386/sev.c | 12
1 file changed, 12 deletions(-)
diff --git a/target/i386/sev.c b/target/i386/sev.c
index dc1e974d93..095ef4c729 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -34,7 +34,6 @@
#define DEFAULT_SEV_DEVICE "/dev/se
AMD SEV encrypts the memory of VMs and because this encryption is done using
an address tweak, the hypervisor will not be able to simply copy ciphertext
between machines to migrate a VM. Instead the AMD SEV Key Management API
provides a set of functions which the hypervisor can use to package a
gue
When memory encryption is enabled, the hypervisor maintains a page
encryption bitmap which is referred by hypervisor during migratoin to check
if page is private or shared. The bitmap is built during the VM bootup and
must be migrated to the target host so that hypervisor on target host can
use it
The command can be used by the hypervisor to specify the target Platform
Diffie-Hellman key (PDH) and certificate chain before starting the SEV
guest migration. The values passed through the command will be used while
creating the outgoing encryption context.
Signed-off-by: Brijesh Singh
---
qap
Signed-off-by: Brijesh Singh
---
docs/amd-memory-encryption.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/docs/amd-memory-encryption.txt b/docs/amd-memory-encryption.txt
index 43bf3ee6a5..abb9a976f5 100644
--- a/docs/amd-memory-encryption.txt
+++ b/docs/amd-memory-encryp
The LAUNCH_START is used for creating an encryption context to encrypt
newly created guest, for an incoming guest the RECEIVE_START should be
used.
Signed-off-by: Brijesh Singh
---
target/i386/sev.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/target/i386/s
The SEV VMs have concept of private and shared memory. The private memory
is encrypted with guest-specific key, while shared memory may be encrypted
with hyperivosr key. The KVM_GET_PAGE_ENC_BITMAP can be used to get a
bitmap indicating whether the guest page is private or shared. A private
page mu
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
On 4/26/19 3:31 PM, Lendacky, Thomas wrote:
...
>>
>> static unsigned int max_sev_asid;
>> static unsigned int min_sev_asid;
>> +static unsigned long me_mask;
>
> sev_me_mask ?
>
Agreed.
>> static unsigned long *sev_asid_bitmap;
>> #define __sme_page_pa(x) __sme_set(page_to_pfn(x)
On 4/29/19 11:36 AM, Borislav Petkov wrote:
> So what about this? Limiting to a sane length...
Sure, we have defined a SEV_FW_BLOB_MAX_SIZE and can use it to limit
the blob copy size. I will do this in next rev. thanks
-Brijesh
On 4/26/19 3:43 PM, Borislav Petkov wrote:
> On Fri, Apr 26, 2019 at 02:29:31PM +0000, Singh, Brijesh wrote:
>> Yes that's doable but I am afraid that caching the value may lead us to
>> wrong path and also divergence from the SEV API spec. The spec says the
>> re
On 4/26/19 9:10 AM, Borislav Petkov wrote:
> On Wed, Apr 24, 2019 at 04:09:59PM +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
On 4/24/19 7:18 PM, Steve Rutherford wrote:
> Do you mean MiB/s, MB/s or Mb/s? Since you are talking about network
> speeds, sometimes these get conflated.
It's megabits/sec. The QMP query-migration command shows the throughput
in Mbits/s. It includes PSP command execution and the network write.
On 4/24/19 2:15 PM, Steve Rutherford wrote:
> On Wed, Apr 24, 2019 at 9:10 AM Singh, Brijesh wrote:
>>
>> The series add support for AMD SEV guest live migration commands. To protect
>> the
>> confidentiality of an SEV protected guest memory while in transit we need
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
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 hypercall can be used by the SEV guest to notify 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 the guest pages should be considered encrypted.
Cc: Thomas Gle
The ioctl can be used to retrieve page encryption bitmap for a given
kvm memory slot.
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: linux-k
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 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: linux-ke
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: linux-ker...@vger.ker
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: Bor
The command is used to create encryption context for the incoming
SEV guest. The encryption context can be later unused 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 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
C
The series add support for AMD SEV guest live migration commands. To protect the
confidentiality of an SEV protected guest memory while in transit we need to
use the SEV commands defined in SEV API spec [1].
SEV guest VMs have the concept of private and shared memory. Private memory
is encrypted w
There are limited numbers of the SEV guests that can be run concurrently.
A management applications may need to know this limit so that it can place
SEV VMs on hosts which have suitable resources available.
Currently, this limit is not exposed to the application. Add a new
'sev-max-guest' field in
On 4/11/19 1:10 PM, Laszlo Ersek wrote:
> On 04/11/19 19:59, Singh, Brijesh wrote:
>> There are limited numbers of the SEV guests that can be run concurrently.
>> A management applications may need to know this limit so that it can place
>> SEV VMs on hosts which ha
On 4/11/19 1:05 PM, Daniel P. Berrangé wrote:
> On Thu, Apr 11, 2019 at 05:59:50PM +0000, Singh, Brijesh wrote:
>> There are limited numbers of the SEV guests that can be run concurrently.
>> A management applications may need to know this limit so that it can place
>> S
There are limited numbers of the SEV guests that can be run concurrently.
A management applications may need to know this limit so that it can place
SEV VMs on hosts which have suitable resources available.
Currently, this limit is not exposed to the application. Add a new
'sev-max-guest' field in
Thanks for adding Alex.
Adding Suravee.
On 3/29/19 11:49 AM, Alex Williamson wrote:
> [Cc +Brijesh]
>
> Hi Brijesh, will the change below require the IVRS to be updated to
> include aliases for all BDF ranges behind a conventional bridge? I
> think the Linux code handles this regardless of the
Hi Daniel,
On 3/15/19 7:18 AM, Daniel P. Berrangé wrote:
> On Fri, Jan 18, 2019 at 12:51:50PM +0000, Singh, Brijesh wrote:
>>
>> On 1/18/19 3:39 AM, Erik Skultety wrote:
>>> I proceeded with cloning [1] to systemd and creating an udev rule that I
>>> pla
Hi Paolo,
Any comment on this series. Currently, device pass-through is
broken for the SEV guests. I am wondering if we can queue the
patches.
thanks
Brijesh
On 2/4/19 4:23 PM, Singh, Brijesh wrote:
> Fix: https://bugzilla.redhat.com/show_bug.cgi?id=1667249
>
> Since v1:
> * che
Currently, a callback registered through the RAMBlock notifier
is not able to get the memory region type (i.e callback is not
able to use memory_region_is_ram_device function). This is
because mr->ram assignment happens _after_ the memory is allocated
whereas the callback is executed during allocat
Fix: https://bugzilla.redhat.com/show_bug.cgi?id=1667249
Since v1:
* check the error code from memory_region_from_host() before
accessing the mr.
Brijesh Singh (2):
memory: Fix the memory region type assignment order
target/i386: sev: Do not pin the ram device memory region
memory.c
The RAM device presents a memory region that should be handled
as an IO region and should not be pinned.
In the case of the vfio-pci, RAM device represents a MMIO BAR
and the memory region is not backed by pages hence
KVM_MEMORY_ENCRYPT_REG_REGION fails to lock the memory range.
Fixes: https://bu
On 2/4/19 11:59 AM, Alex Williamson wrote:
> On Thu, 17 Jan 2019 21:53:16 +
> "Singh, Brijesh" wrote:
>
>> The RAM device presents a memory region that should be handled
>> as an IO region and should not be pinned.
>>
>> In the case of the vfio-p
Hi Alex and Paolo,
Any comments on the patch.
thanks
On 1/17/19 3:53 PM, Singh, Brijesh wrote:
> Fix: https://bugzilla.redhat.com/show_bug.cgi?id=1667249
>
> Brijesh Singh (2):
>memory: Fix the memory region type assignment order
>target/i386: sev: Do not pin the ra
On 1/30/19 7:39 AM, Erik Skultety wrote:
though, we need a #ifdef check for existance of PR_CAP_AMBIENT
> An alternative question I've been playing ever since we exchanged the
> last few
> emails is that can't we wait until the ioctls are compared against
> permissions
n 23, 2019 at 01:10:42PM +, Daniel P. Berrangé wrote:
>>>>> On Wed, Jan 23, 2019 at 01:55:06PM +0100, Erik Skultety wrote:
>>>>>> On Fri, Jan 18, 2019 at 12:51:50PM +, Singh, Brijesh wrote:
>>>>>>>
>>>>>>> On 1/18/19 3:
On 1/18/19 3:39 AM, Erik Skultety wrote:
> Hi,
> this is a summary of a private discussion I've had with guys CC'd on this
> email
> about finding a solution to [1] - basically, the default permissions on
> /dev/sev (below) make it impossible to query for SEV platform capabilities,
> since by def
Currently, a callback registered through the RAMBlock notifier
is not able to get the memory region type (i.e callback is not
able to use memory_region_is_ram_device function). This is
because mr->ram assignment happens _after_ the memory is allocated
whereas the callback is executed during allocat
The RAM device presents a memory region that should be handled
as an IO region and should not be pinned.
In the case of the vfio-pci, RAM device represents a MMIO BAR
and the memory region is not backed by pages hence
KVM_MEMORY_ENCRYPT_REG_REGION fails to lock the memory range.
Fixes: https://bu
Fix: https://bugzilla.redhat.com/show_bug.cgi?id=1667249
Brijesh Singh (2):
memory: Fix the memory region type assignment order
target/i386: sev: Do not pin the ram device memory region
memory.c | 9 -
target/i386/sev.c | 11 +++
2 files changed, 19 insertions(+), 1
On 10/25/2018 07:59 PM, Michael S. Tsirkin wrote:
> On Thu, Oct 25, 2018 at 08:16:44PM +0100, Peter Maydell wrote:
>> On 25 October 2018 at 01:52, Michael S. Tsirkin wrote:
>>> The following changes since commit 13399aad4fa87b2878c49d02a5d3bafa6c966ba3:
>>>
>>>Merge remote-tracking branch 'r
Hi Michael, Paolo and Eduardo,
Any thoughts on the series ?
Thanks
Brijesh
On 10/1/18 12:44 PM, Singh, Brijesh wrote:
> This series adds the interrupt remapping support for amd-iommu device.
>
> IOMMU spec is available at: https://support.amd.com/TechDocs/48882_IOMMU.pdf
>
>
The vtd_generate_msi_message() in intel-iommu is used to construct a MSI
Message from IRQ. A similar function will be needed when we add interrupt
remapping support in amd-iommu. Moving the function in common file to
avoid the code duplication. Rename it to x86_iommu_irq_to_msi_message().
There is
Now that amd-iommu support interrupt remapping, enable the GASup in IVRS
table and GASup in extended feature register to indicate that IOMMU
support guest virtual APIC mode. GASup provides option to guest OS to
make use of 128-bit IRTE.
Note that the GAMSup is set to zero to indicate that amd-iomm
Interrupt remapping needs kernel-irqchip={off|split} on both Intel and AMD
platforms. Move the check in common place.
Signed-off-by: Brijesh Singh
Reviewed-by: Peter Xu
Cc: Peter Xu
Cc: "Michael S. Tsirkin"
Cc: Paolo Bonzini
Cc: Richard Henderson
Cc: Eduardo Habkost
Cc: Marcel Apfelbaum
Cc
1 - 100 of 131 matches
Mail list logo
