qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Dov Murik <dovmurik@linux.ibm.com>
To: qemu-devel@nongnu.org
Cc: Tom Lendacky <thomas.lendacky@amd.com>,
	Ashish Kalra <ashish.kalra@amd.com>,
	Brijesh Singh <brijesh.singh@amd.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Steve Rutherford <srutherford@google.com>,
	James Bottomley <jejb@linux.ibm.com>,
	Juan Quintela <quintela@redhat.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	Dov Murik <dovmurik@linux.ibm.com>,
	Hubertus Franke <frankeh@us.ibm.com>,
	Tobin Feldman-Fitzthum <tobin@linux.ibm.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: [RFC PATCH v2 02/12] migration: Add helpers to load confidential RAM
Date: Mon, 23 Aug 2021 10:16:26 -0400	[thread overview]
Message-ID: <20210823141636.65975-3-dovmurik@linux.ibm.com> (raw)
In-Reply-To: <20210823141636.65975-1-dovmurik@linux.ibm.com>

QEMU cannot write directly to the memory of memory-encrypted guests;
this breaks normal RAM-load in the migration target.  Instead, QEMU
asks a migration helper running on an auxiliary vcpu in the guest to
restore encrypted pages as they were received from the source to a
specific GPA.

The migration helper running inside the guest can safely decrypt the
pages arrived from the source and load them into their proper location
in the guest's memory.

Loading pages uses the same shared (unencrypted) pages which both QEMU
and the guest can read from and write to.

Signed-off-by: Dov Murik <dovmurik@linux.ibm.com>
---
 migration/confidential-ram.h |  2 ++
 migration/confidential-ram.c | 37 ++++++++++++++++++++++++++++++++++++
 migration/trace-events       |  1 +
 3 files changed, 40 insertions(+)

diff --git a/migration/confidential-ram.h b/migration/confidential-ram.h
index 0d49718d31..ebe4073bce 100644
--- a/migration/confidential-ram.h
+++ b/migration/confidential-ram.h
@@ -14,4 +14,6 @@ void cgs_mh_cleanup(void);
 int cgs_mh_save_encrypted_page(QEMUFile *f, ram_addr_t src_gpa, uint32_t size,
                                uint64_t *bytes_sent);
 
+int cgs_mh_load_encrypted_page(QEMUFile *f, ram_addr_t dest_gpa);
+
 #endif
diff --git a/migration/confidential-ram.c b/migration/confidential-ram.c
index 65a588e7f6..053ecea1d4 100644
--- a/migration/confidential-ram.c
+++ b/migration/confidential-ram.c
@@ -182,3 +182,40 @@ int cgs_mh_save_encrypted_page(QEMUFile *f, ram_addr_t src_gpa, uint32_t size,
 
     return ret;
 }
+
+int cgs_mh_load_encrypted_page(QEMUFile *f, ram_addr_t dest_gpa)
+{
+    int ret = 1;
+    uint32_t page_hdr_len, enc_page_len;
+
+    init_cgs_mig_helper_if_needed();
+
+    assert((dest_gpa & TARGET_PAGE_MASK) == dest_gpa);
+
+    /* Read page header */
+    page_hdr_len = qemu_get_be32(f);
+    if (page_hdr_len > 1024) {
+        error_report("confidential-ram: page header is too large (%d bytes) "
+                     "when loading gpa 0x%" PRIx64, page_hdr_len, dest_gpa);
+        return -EINVAL;
+    }
+    cmhs.io_page_hdr->len = page_hdr_len;
+    qemu_get_buffer(f, cmhs.io_page_hdr->data, page_hdr_len);
+
+    /* Read encrypted page */
+    enc_page_len = qemu_get_be32(f);
+    if (enc_page_len != TARGET_PAGE_SIZE) {
+        error_report("confidential-ram: encrypted page is too large (%d bytes) "
+                     "when loading gpa 0x%" PRIx64, enc_page_len, dest_gpa);
+        return -EINVAL;
+    }
+    qemu_get_buffer(f, cmhs.io_page, enc_page_len);
+
+    trace_encrypted_ram_load_page(page_hdr_len, enc_page_len, dest_gpa);
+    ret = send_command_to_cgs_mig_helper(CGS_MIG_HELPER_CMD_DECRYPT, dest_gpa);
+    if (ret) {
+        error_report("confidential-ram: failed loading page at gpa "
+                     "0x%" PRIx64 ": ret=%d", dest_gpa, ret);
+    }
+    return ret;
+}
diff --git a/migration/trace-events b/migration/trace-events
index 3d442a767f..5a6b5c8230 100644
--- a/migration/trace-events
+++ b/migration/trace-events
@@ -346,4 +346,5 @@ migration_pagecache_init(int64_t max_num_items) "Setting cache buckets to %" PRI
 migration_pagecache_insert(void) "Error allocating page"
 
 # confidential-ram.c
+encrypted_ram_load_page(uint32_t hdr_len, uint32_t trans_len, uint64_t gpa) "hdr_len: %u, trans_len: %u, gpa: 0x%" PRIx64
 encrypted_ram_save_page(uint32_t size, uint64_t gpa) "size: %u, gpa: 0x%" PRIx64
-- 
2.20.1



  parent reply	other threads:[~2021-08-23 14:18 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-23 14:16 [RFC PATCH v2 00/12] Confidential guest-assisted live migration Dov Murik
2021-08-23 14:16 ` [RFC PATCH v2 01/12] migration: Add helpers to save confidential RAM Dov Murik
2021-08-23 14:16 ` Dov Murik [this message]
2021-08-23 14:16 ` [RFC PATCH v2 03/12] migration: Introduce gpa_inside_migration_helper_shared_area Dov Murik
2021-08-23 14:16 ` [RFC PATCH v2 04/12] migration: Save confidential guest RAM using migration helper Dov Murik
2021-08-23 14:16 ` [RFC PATCH v2 05/12] migration: Load " Dov Murik
2021-08-23 14:16 ` [RFC PATCH v2 06/12] migration: Skip ROM, non-RAM, and vga.vram memory region during RAM migration Dov Murik
2021-08-23 14:16 ` [RFC PATCH v2 07/12] i386/kvm: Exclude mirror vcpu in kvm_synchronize_all_tsc Dov Murik
2021-08-23 14:16 ` [RFC PATCH v2 08/12] migration: Allow resetting the mirror vcpu to the MH entry point Dov Murik
2021-08-23 14:16 ` [RFC PATCH v2 09/12] migration: Add QMP command start-migration-handler Dov Murik
2021-08-23 14:16 ` [RFC PATCH v2 10/12] migration: Add start-migrate-incoming QMP command Dov Murik
2021-08-23 14:16 ` [RFC PATCH v2 11/12] hw/isa/lpc_ich9: Allow updating an already-running VM Dov Murik
2021-08-23 14:16 ` [RFC PATCH v2 12/12] docs: Add confidential guest live migration documentation Dov Murik
2023-09-05  9:46 ` [RFC PATCH v2 00/12] Confidential guest-assisted live migration Shameerali Kolothum Thodi via

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=20210823141636.65975-3-dovmurik@linux.ibm.com \
    --to=dovmurik@linux.ibm.com \
    --cc=ashish.kalra@amd.com \
    --cc=brijesh.singh@amd.com \
    --cc=dgilbert@redhat.com \
    --cc=frankeh@us.ibm.com \
    --cc=jejb@linux.ibm.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=srutherford@google.com \
    --cc=thomas.lendacky@amd.com \
    --cc=tobin@linux.ibm.com \
    /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 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).