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
>
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
On 9/28/18 12:46 AM, Peter Xu wrote:
> On Thu, Sep 27, 2018 at 04:45:55PM +0000, Singh, Brijesh wrote:
>> Currently, the amdvi_validate_dte() assumes that a valid DTE will
>> always have V=1. This is not true. The V=1 means that bit[127:1] are
>> valid. A valid DTE can h
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
Register the interrupt remapping callback and read/write ops for the
amd-iommu-ir memory region.
amd-iommu-ir is set to higher priority to ensure that this region won't
be masked out by other memory regions.
Signed-off-by: Brijesh Singh
Cc: Peter Xu
Cc: "Michael S. Tsirkin"
Cc: Paolo Bonzini
Currently, the amdvi_validate_dte() assumes that a valid DTE will
always have V=1. This is not true. The V=1 means that bit[127:1] are
valid. A valid DTE can have IV=1 and V=0 (i.e address translation
disabled and interrupt remapping enabled)
Remove the V=1 check from amdvi_validate_dte(), make
This series adds the interrupt remapping support for amd-iommu device.
IOMMU spec is available at: https://support.amd.com/TechDocs/48882_IOMMU.pdf
To enable the interrupt remap use below qemu cli
# $QEMU \
-device amd-iommu,intremap=on
I have tested FC-28 and Ubuntu 18.04 guest.
Linux
To be consistent with intel-iommu:
- rename the address space to use '_' instead of '-'
- update the memory region relationships
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
Emulate the interrupt remapping support when guest virtual APIC is
not enabled.
For more info Refer: AMD IOMMU spec Rev 3.0 - section 2.2.5.1
When VAPIC is not enabled, it uses interrupt remapping as defined in
Table 20 and Figure 15 from IOMMU spec.
Signed-off-by: Brijesh Singh
Cc: Peter Xu
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
When interrupt remapping is enabled, add a special IVHD device
(type IOAPIC).
Signed-off-by: Brijesh Singh
Acked-by: Peter Xu
Cc: Peter Xu
Cc: "Michael S. Tsirkin"
Cc: Paolo Bonzini
Cc: Richard Henderson
Cc: Eduardo Habkost
Cc: Marcel Apfelbaum
Cc: Tom Lendacky
Cc: Suravee Suthikulpanit
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
This series adds the interrupt remapping support for amd-iommu device.
IOMMU spec is available at: https://support.amd.com/TechDocs/48882_IOMMU.pdf
To enable the interrupt remap use below qemu cli
# $QEMU \
-device amd-iommu,intremap=on
I have tested FC-28 and Ubuntu 18.04 guest.
Linux
To be consistent with intel-iommu:
- rename the address space to use '_' instead of '-'
- update the memory region relationships
Signed-off-by: Brijesh Singh
Cc: Peter Xu
Cc: "Michael S. Tsirkin"
Cc: Paolo Bonzini
Cc: Richard Henderson
Cc: Eduardo Habkost
Cc: Marcel Apfelbaum
Cc: Tom
When interrupt remapping is enabled, add a special IVHD device
(type IOAPIC).
Signed-off-by: Brijesh Singh
Cc: Peter Xu
Cc: "Michael S. Tsirkin"
Cc: Paolo Bonzini
Cc: Richard Henderson
Cc: Eduardo Habkost
Cc: Marcel Apfelbaum
Cc: Tom Lendacky
Cc: Suravee Suthikulpanit
---
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
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
Currently, the amdvi_validate_dte() assumes that a valid DTE will
always have V=1. This is not true. The V=1 means that bit[127:1] are
valid. A valid DTE can have IV=1 and V=0 (i.e address translation
disabled and interrupt remapping enabled)
Remove the V=1 check from amdvi_validate_dte(), make
Emulate the interrupt remapping support when guest virtual APIC is
not enabled.
For more info Refer: AMD IOMMU spec Rev 3.0 - section 2.2.5.1
When VAPIC is not enabled, it uses interrupt remapping as defined in
Table 20 and Figure 15 from IOMMU spec.
Signed-off-by: Brijesh Singh
Cc: Peter Xu
Register the interrupt remapping callback and read/write ops for the
amd-iommu-ir memory region.
amd-iommu-ir is set to higher priority to ensure that this region won't
be masked out by other memory regions.
Signed-off-by: Brijesh Singh
Cc: Peter Xu
Cc: "Michael S. Tsirkin"
Cc: Paolo Bonzini
On 9/25/18 1:17 AM, Peter Xu wrote:
> On Fri, Sep 21, 2018 at 02:25:37PM +0000, Singh, Brijesh wrote:
>> Currently, the amdvi_validate_dte() assumes that a valid DTE will
>> always have V=1. This is not true. The V=1 means that bit[127:1] are
>> valid. A valid DTE can h
On 9/25/18 1:36 AM, Peter Xu wrote:
> On Fri, Sep 21, 2018 at 02:25:40PM +0000, Singh, Brijesh wrote:
>> Emulate the interrupt remapping support when guest virtual APIC is
>> not enabled.
>>
>> For more info Refer: AMD IOMMU spec Rev 3.0 - section 2.2.5.1
>>
>
On 9/25/18 1:57 AM, Peter Xu wrote:
> On Fri, Sep 21, 2018 at 02:25:42PM +0000, Singh, Brijesh wrote:
>
> [...]
>
>> +static int amdvi_int_remap_ga(AMDVIState *iommu,
>> + MSIMessage *origin,
>> +
This series adds the interrupt remapping support for amd-iommu device.
IOMMU spec is available at: https://support.amd.com/TechDocs/48882_IOMMU.pdf
To enable the interrupt remap use below qemu cli
# $QEMU \
-device amd-iommu,intremap=on
I have tested FC-28 and Ubuntu 18.04 guest.
Linux
When interrupt remapping is enabled, add a special IVHD device
(type IOAPIC).
Signed-off-by: Brijesh Singh
Cc: Peter Xu
Cc: "Michael S. Tsirkin"
Cc: Paolo Bonzini
Cc: Richard Henderson
Cc: Eduardo Habkost
Cc: Marcel Apfelbaum
Cc: Tom Lendacky
Cc: Suravee Suthikulpanit
---
Currently, the amdvi_validate_dte() assumes that a valid DTE will
always have V=1. This is not true. The V=1 means that bit[127:1] are
valid. A valid DTE can have IV=1 and V=0 (i.e address translation
disabled and interrupt remapping enabled)
Remove the V=1 check from amdvi_validate_dte(), make
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
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
To be consistent with intel-iommu:
- rename the address space to use '_' instead of '-'
- update the memory region relationships
Signed-off-by: Brijesh Singh
Cc: Peter Xu
Cc: "Michael S. Tsirkin"
Cc: Paolo Bonzini
Cc: Richard Henderson
Cc: Eduardo Habkost
Cc: Marcel Apfelbaum
Cc: Tom
Register the interrupt remapping callback and read/write ops for the
amd-iommu-ir memory region.
amd-iommu-ir is set to higher priority to ensure that this region won't
be masked out by other memory regions.
Signed-off-by: Brijesh Singh
Cc: Peter Xu
Cc: "Michael S. Tsirkin"
Cc: Paolo Bonzini
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
Emulate the interrupt remapping support when guest virtual APIC is
not enabled.
For more info Refer: AMD IOMMU spec Rev 3.0 - section 2.2.5.1
When VAPIC is not enabled, it uses interrupt remapping as defined in
Table 20 and Figure 15 from IOMMU spec.
Signed-off-by: Brijesh Singh
Cc: Peter Xu
On 9/28/18 1:08 AM, Peter Xu wrote:
> On Thu, Sep 27, 2018 at 04:45:59PM +0000, Singh, Brijesh wrote:
>
> [...]
>
>> +/* validate that we are configure with intremap=on */
>> +if (!X86_IOMMU_DEVICE(iommu)->intr_supported) {
>> +error_repor
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(+),
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:
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
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
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/
On 09/17/2018 10:53 PM, Peter Xu wrote:
[...]
>> IMHO we should not be using error_report_once() here. It's possible that
>> guest OS have DTE[IV]=1 but has not programmed the interrupt
>> remapping entries or have deactivated the remapping. I see that Linux
>> OS does it all the time and in
Small correction
On 09/18/2018 03:27 PM, Singh, Brijesh wrote:>
> So far non of the guests were enabling the interrupt remap features
> even when it was available. As I explained in previous patches (see
> patch 6), Linux guest looks for a special IOAPIC device in IVHD befor
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
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
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
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
>
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
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:
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 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
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
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
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
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
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
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
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
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
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
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 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
---
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
+++
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
+++
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
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
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
---
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 passe
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
>> returne
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)
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 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 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
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
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
---
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
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
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
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
+++
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
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
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
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
+++
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
---
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
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
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
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/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 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
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
>>
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/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: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 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 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
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
1 - 100 of 131 matches
Mail list logo
