* [PATCH v12 00/28] x86: Secure Encrypted Virtualization (AMD)
@ 2018-03-08 12:48 ` Brijesh Singh
0 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:48 UTC (permalink / raw)
To: qemu-devel
Cc: Peter Maydell, Brijesh Singh, kvm, Michael S. Tsirkin,
Stefan Hajnoczi, Alexander Graf, Edgar E. Iglesias,
Markus Armbruster, Bruce Rogers, Christian Borntraeger,
Marcel Apfelbaum, Borislav Petkov, Thomas Lendacky,
Eduardo Habkost, Richard Henderson, Dr. David Alan Gilbert,
Alistair Francis, Cornelia Huck, Peter Crosthwaite,
Paolo Bonzini
This patch series provides support for AMD's new Secure Encrypted
Virtualization (SEV) feature.
SEV is an extension to the AMD-V architecture which supports running
multiple VMs under the control of a hypervisor. The SEV feature allows
the memory contents of a virtual machine (VM) to be transparently encrypted
with a key unique to the guest VM. The memory controller contains a
high performance encryption engine which can be programmed with multiple
keys for use by a different VMs in the system. The programming and
management of these keys is handled by the AMD Secure Processor firmware
which exposes a commands for these tasks.
The KVM SEV patch series introduced a new ioctl (KVM_MEMORY_ENCRYPTION_OP)
which is used by qemu to issue the SEV commands to assist performing
common hypervisor activities such as a launching, running, snapshooting,
migration and debugging guests.
The following links provide additional details:
AMD Memory Encryption whitepaper:
http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf
AMD64 Architecture Programmer's Manual:
http://support.amd.com/TechDocs/24593.pdf
SME is section 7.10
SEV is section 15.34
Secure Encrypted Virutualization Key Management:
http://support.amd.com/TechDocs/55766_SEV-KM API_Specification.pdf
KVM Forum slides:
http://www.linux-kvm.org/images/7/74/02x08A-Thomas_Lendacky-AMDs_Virtualizatoin_Memory_Encryption_Technology.pdf
Video of the KVM Forum Talk:
https://www.youtube.com/watch?v=RcvQ1xN55Ew
---
The complete patch series is available :
https://github.com/codomania/qemu/tree/v12
Using these patches we have succesfully booted and tested a guest both with and
without SEV enabled.
TODO:
* Add SEV guest migration support
* Add SEV guest snapshot and restore support
Changes since v11:
- fix build failure seen with mingw32
Changes since v10:
- rebase to latest qemu
- minor fixes reported during review
Changes since v9:
- move sev specific header definition in target/i386/sev_i386.h
- add new QMP query-sev-capabilities - the command will be used by libvirt
to query the SEV capabilities information.
- move sev specific QMP command implementation in target/i386/monitor.c. The
sev commands are disabled for non x86 architecture
- update 'info sev' command to display human readiable format for policy
- use g_new0 to allocate to structure memory
- update qemu-options.hx to include cbitspos and reduced-phys-bit field
Changes since v8:
- update 'query-sev' command to use enum type for SEV state.
- populate memory encryption cpuid when only SEV is enabled.
Changes since v7:
- move sev.c from accel/kvm to target/i386
- update query-sev-launch-measure to return error when measurement is not available
- update flatview_read to use slow path when attrs.debug=1 is set
- fix the buffer overflow
- use '-' when adding new member in SevInfo QMP structure
Changes since v6:
- add support to specify cbitpos in sev-guest object
- add 'info sev' HMP command
- add 'query-sev' and 'query-launch-measure' QMP commands
- rework the logic to query the memory encryption mask when walking
guest pagetable for debug
Changes since v5:
- drop MEMTXTATTRS_DEBUG macro, caller now specify attrs.debug=1 when needed.
- drop DPRINTF and use trace points to output the debug messages
Changes since v4:
- extend sev-guest object to add new properties 'dh-cert-file', 'session-file' etc.
- emit SEV_MEASUREMENT event when measurement is available
- add migration blocker
- add memory encryption cpuid support
- rebase the series with recent qemu tree
Changes since v3:
- update to newer SEV spec (0.12 -> 0.14)
- update to newer KVM RFC and use KVM_MEMORY_ENCRYPTION_OP ioctl instead
of KVM_ISSUE_SEV.
- add support to encrypt plfash
Changes since v2:
- rename ram_ops to ram_debug_ops
- use '-' rather than '_' when adding new member in KvmInfo struct
- update sev object to use link properties when referencing other objects
- use ldq_phys_debug in tlb_info_64 and mem_info_64.
- remove sev-guest-policy object, we will revisit it after basic SEV
guest support is merged.
- remove kernel API from doc and add SEV guest LAUNCH model. The doc will
be updated as we integerate the remaining SEV APIs.
Changes since v1:
- Added Documentation
- Added security-policy object.
- Drop sev config parsing support and create new objects to get/set SEV
specific parameters
- Added sev-guest-info object.
- Added sev-launch-info object.
- Added kvm_memory_encrytion_* APIs. The idea behind this was to allow adding
a non SEV memory encrytion object without modifying interfaces.
- Drop patch to load OS image at fixed location.
- updated LAUNCH_FINISH command structure. Now the structure contains
just 'measurement' field. Other fields are not used and will also be removed
from newer SEV firmware API spec.
Brijesh Singh (28):
memattrs: add debug attribute
exec: add ram_debug_ops support
exec: add debug version of physical memory read and write API
monitor/i386: use debug APIs when accessing guest memory
machine: add -memory-encryption property
kvm: update kvm.h to include memory encryption ioctls
docs: add AMD Secure Encrypted Virtualization (SEV)
target/i386: add Secure Encrypted Virtulization (SEV) object
qmp: add query-sev command
include: add psp-sev.h header file
sev/i386: add command to initialize the memory encryption context
sev/i386: register the guest memory range which may contain encrypted
data
kvm: introduce memory encryption APIs
hmp: add 'info sev' command
sev/i386: add command to create launch memory encryption context
sev/i386: add command to encrypt guest memory region
target/i386: encrypt bios rom
sev/i386: add support to LAUNCH_MEASURE command
sev/i386: finalize the SEV guest launch flow
hw/i386: set ram_debug_ops when memory encryption is enabled
sev/i386: add debug encrypt and decrypt commands
target/i386: clear C-bit when walking SEV guest page table
qmp: add query-sev-launch-measure command
sev/i386: add migration blocker
cpu/i386: populate CPUID 0x8000_001F when SEV is active
qmp: add query-sev-capabilities command
sev/i386: add sev_get_capabilities()
tests/qmp-test: blacklist sev specific qmp commands
accel/kvm/kvm-all.c | 49 +++
accel/stubs/kvm-stub.c | 14 +
cpus.c | 2 +-
disas.c | 2 +-
docs/amd-memory-encryption.txt | 109 ++++++
exec.c | 83 +++-
hmp-commands-info.hx | 16 +
hmp.h | 1 +
hw/core/machine.c | 22 ++
hw/i386/pc.c | 9 +
hw/i386/pc_sysfw.c | 19 +
include/exec/cpu-common.h | 15 +
include/exec/memattrs.h | 2 +
include/exec/memory.h | 30 +-
include/hw/boards.h | 1 +
include/sysemu/kvm.h | 25 ++
include/sysemu/sev.h | 22 ++
linux-headers/linux/kvm.h | 90 +++++
linux-headers/linux/psp-sev.h | 142 +++++++
monitor.c | 27 +-
qapi/misc.json | 147 +++++++
qemu-options.hx | 49 ++-
stubs/Makefile.objs | 1 +
stubs/sev.c | 30 ++
target/i386/Makefile.objs | 4 +-
target/i386/cpu.c | 13 +
target/i386/helper.c | 31 +-
target/i386/monitor.c | 193 ++++++---
target/i386/sev-stub.c | 51 +++
target/i386/sev.c | 868 +++++++++++++++++++++++++++++++++++++++++
target/i386/sev_i386.h | 88 +++++
target/i386/trace-events | 11 +
tests/qmp-test.c | 5 +
33 files changed, 2086 insertions(+), 85 deletions(-)
create mode 100644 docs/amd-memory-encryption.txt
create mode 100644 include/sysemu/sev.h
create mode 100644 linux-headers/linux/psp-sev.h
create mode 100644 stubs/sev.c
create mode 100644 target/i386/sev-stub.c
create mode 100644 target/i386/sev.c
create mode 100644 target/i386/sev_i386.h
--
2.14.3
^ permalink raw reply [flat|nested] 114+ messages in thread
* [Qemu-devel] [PATCH v12 00/28] x86: Secure Encrypted Virtualization (AMD)
@ 2018-03-08 12:48 ` Brijesh Singh
0 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:48 UTC (permalink / raw)
To: qemu-devel
Cc: Alistair Francis, Christian Borntraeger, Cornelia Huck,
Daniel P . Berrange, Dr. David Alan Gilbert, Michael S. Tsirkin,
Edgar E. Iglesias, Eduardo Habkost, Eric Blake, kvm,
Marcel Apfelbaum, Markus Armbruster, Paolo Bonzini,
Peter Crosthwaite, Peter Maydell, Richard Henderson,
Stefan Hajnoczi, Thomas Lendacky, Borislav Petkov,
Alexander Graf, Bruce Rogers, Brijesh Singh
This patch series provides support for AMD's new Secure Encrypted
Virtualization (SEV) feature.
SEV is an extension to the AMD-V architecture which supports running
multiple VMs under the control of a hypervisor. The SEV feature allows
the memory contents of a virtual machine (VM) to be transparently encrypted
with a key unique to the guest VM. The memory controller contains a
high performance encryption engine which can be programmed with multiple
keys for use by a different VMs in the system. The programming and
management of these keys is handled by the AMD Secure Processor firmware
which exposes a commands for these tasks.
The KVM SEV patch series introduced a new ioctl (KVM_MEMORY_ENCRYPTION_OP)
which is used by qemu to issue the SEV commands to assist performing
common hypervisor activities such as a launching, running, snapshooting,
migration and debugging guests.
The following links provide additional details:
AMD Memory Encryption whitepaper:
http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf
AMD64 Architecture Programmer's Manual:
http://support.amd.com/TechDocs/24593.pdf
SME is section 7.10
SEV is section 15.34
Secure Encrypted Virutualization Key Management:
http://support.amd.com/TechDocs/55766_SEV-KM API_Specification.pdf
KVM Forum slides:
http://www.linux-kvm.org/images/7/74/02x08A-Thomas_Lendacky-AMDs_Virtualizatoin_Memory_Encryption_Technology.pdf
Video of the KVM Forum Talk:
https://www.youtube.com/watch?v=RcvQ1xN55Ew
---
The complete patch series is available :
https://github.com/codomania/qemu/tree/v12
Using these patches we have succesfully booted and tested a guest both with and
without SEV enabled.
TODO:
* Add SEV guest migration support
* Add SEV guest snapshot and restore support
Changes since v11:
- fix build failure seen with mingw32
Changes since v10:
- rebase to latest qemu
- minor fixes reported during review
Changes since v9:
- move sev specific header definition in target/i386/sev_i386.h
- add new QMP query-sev-capabilities - the command will be used by libvirt
to query the SEV capabilities information.
- move sev specific QMP command implementation in target/i386/monitor.c. The
sev commands are disabled for non x86 architecture
- update 'info sev' command to display human readiable format for policy
- use g_new0 to allocate to structure memory
- update qemu-options.hx to include cbitspos and reduced-phys-bit field
Changes since v8:
- update 'query-sev' command to use enum type for SEV state.
- populate memory encryption cpuid when only SEV is enabled.
Changes since v7:
- move sev.c from accel/kvm to target/i386
- update query-sev-launch-measure to return error when measurement is not available
- update flatview_read to use slow path when attrs.debug=1 is set
- fix the buffer overflow
- use '-' when adding new member in SevInfo QMP structure
Changes since v6:
- add support to specify cbitpos in sev-guest object
- add 'info sev' HMP command
- add 'query-sev' and 'query-launch-measure' QMP commands
- rework the logic to query the memory encryption mask when walking
guest pagetable for debug
Changes since v5:
- drop MEMTXTATTRS_DEBUG macro, caller now specify attrs.debug=1 when needed.
- drop DPRINTF and use trace points to output the debug messages
Changes since v4:
- extend sev-guest object to add new properties 'dh-cert-file', 'session-file' etc.
- emit SEV_MEASUREMENT event when measurement is available
- add migration blocker
- add memory encryption cpuid support
- rebase the series with recent qemu tree
Changes since v3:
- update to newer SEV spec (0.12 -> 0.14)
- update to newer KVM RFC and use KVM_MEMORY_ENCRYPTION_OP ioctl instead
of KVM_ISSUE_SEV.
- add support to encrypt plfash
Changes since v2:
- rename ram_ops to ram_debug_ops
- use '-' rather than '_' when adding new member in KvmInfo struct
- update sev object to use link properties when referencing other objects
- use ldq_phys_debug in tlb_info_64 and mem_info_64.
- remove sev-guest-policy object, we will revisit it after basic SEV
guest support is merged.
- remove kernel API from doc and add SEV guest LAUNCH model. The doc will
be updated as we integerate the remaining SEV APIs.
Changes since v1:
- Added Documentation
- Added security-policy object.
- Drop sev config parsing support and create new objects to get/set SEV
specific parameters
- Added sev-guest-info object.
- Added sev-launch-info object.
- Added kvm_memory_encrytion_* APIs. The idea behind this was to allow adding
a non SEV memory encrytion object without modifying interfaces.
- Drop patch to load OS image at fixed location.
- updated LAUNCH_FINISH command structure. Now the structure contains
just 'measurement' field. Other fields are not used and will also be removed
from newer SEV firmware API spec.
Brijesh Singh (28):
memattrs: add debug attribute
exec: add ram_debug_ops support
exec: add debug version of physical memory read and write API
monitor/i386: use debug APIs when accessing guest memory
machine: add -memory-encryption property
kvm: update kvm.h to include memory encryption ioctls
docs: add AMD Secure Encrypted Virtualization (SEV)
target/i386: add Secure Encrypted Virtulization (SEV) object
qmp: add query-sev command
include: add psp-sev.h header file
sev/i386: add command to initialize the memory encryption context
sev/i386: register the guest memory range which may contain encrypted
data
kvm: introduce memory encryption APIs
hmp: add 'info sev' command
sev/i386: add command to create launch memory encryption context
sev/i386: add command to encrypt guest memory region
target/i386: encrypt bios rom
sev/i386: add support to LAUNCH_MEASURE command
sev/i386: finalize the SEV guest launch flow
hw/i386: set ram_debug_ops when memory encryption is enabled
sev/i386: add debug encrypt and decrypt commands
target/i386: clear C-bit when walking SEV guest page table
qmp: add query-sev-launch-measure command
sev/i386: add migration blocker
cpu/i386: populate CPUID 0x8000_001F when SEV is active
qmp: add query-sev-capabilities command
sev/i386: add sev_get_capabilities()
tests/qmp-test: blacklist sev specific qmp commands
accel/kvm/kvm-all.c | 49 +++
accel/stubs/kvm-stub.c | 14 +
cpus.c | 2 +-
disas.c | 2 +-
docs/amd-memory-encryption.txt | 109 ++++++
exec.c | 83 +++-
hmp-commands-info.hx | 16 +
hmp.h | 1 +
hw/core/machine.c | 22 ++
hw/i386/pc.c | 9 +
hw/i386/pc_sysfw.c | 19 +
include/exec/cpu-common.h | 15 +
include/exec/memattrs.h | 2 +
include/exec/memory.h | 30 +-
include/hw/boards.h | 1 +
include/sysemu/kvm.h | 25 ++
include/sysemu/sev.h | 22 ++
linux-headers/linux/kvm.h | 90 +++++
linux-headers/linux/psp-sev.h | 142 +++++++
monitor.c | 27 +-
qapi/misc.json | 147 +++++++
qemu-options.hx | 49 ++-
stubs/Makefile.objs | 1 +
stubs/sev.c | 30 ++
target/i386/Makefile.objs | 4 +-
target/i386/cpu.c | 13 +
target/i386/helper.c | 31 +-
target/i386/monitor.c | 193 ++++++---
target/i386/sev-stub.c | 51 +++
target/i386/sev.c | 868 +++++++++++++++++++++++++++++++++++++++++
target/i386/sev_i386.h | 88 +++++
target/i386/trace-events | 11 +
tests/qmp-test.c | 5 +
33 files changed, 2086 insertions(+), 85 deletions(-)
create mode 100644 docs/amd-memory-encryption.txt
create mode 100644 include/sysemu/sev.h
create mode 100644 linux-headers/linux/psp-sev.h
create mode 100644 stubs/sev.c
create mode 100644 target/i386/sev-stub.c
create mode 100644 target/i386/sev.c
create mode 100644 target/i386/sev_i386.h
--
2.14.3
^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH v12 01/28] memattrs: add debug attribute
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
@ 2018-03-08 12:48 ` Brijesh Singh
-1 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:48 UTC (permalink / raw)
To: qemu-devel
Cc: Peter Maydell, Brijesh Singh, kvm, Michael S. Tsirkin,
Stefan Hajnoczi, Alexander Graf, Edgar E. Iglesias,
Markus Armbruster, Bruce Rogers, Christian Borntraeger,
Marcel Apfelbaum, Borislav Petkov, Thomas Lendacky,
Eduardo Habkost, Richard Henderson, Dr. David Alan Gilbert,
Alistair Francis, Cornelia Huck, Peter Crosthwaite,
Paolo Bonzini
Extend the MemTxAttrs to include 'debug' flag. The flag can be used as
general indicator that operation was triggered by the debugger.
Later in the patch series we set the debug=1 when issuing a memory access
from the gdbstub or HMP commands. This patch is prerequisite to support
debugging the encrypted guest. If we see request with debug=1 then we
will need to use encryption APIs to access the guest memory.
Cc: Alistair Francis <alistair.francis@xilinx.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: "Edgar E. Iglesias" <edgar.iglesias@xilinx.com>
Cc: Richard Henderson <richard.henderson@linaro.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: "Edgar E. Iglesias" <edgar.iglesias@xilinx.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
include/exec/memattrs.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/exec/memattrs.h b/include/exec/memattrs.h
index d4a16420984b..08099e4f7e72 100644
--- a/include/exec/memattrs.h
+++ b/include/exec/memattrs.h
@@ -37,6 +37,8 @@ typedef struct MemTxAttrs {
unsigned int user:1;
/* Requester ID (for MSI for example) */
unsigned int requester_id:16;
+ /* Memory access request from the debugger */
+ unsigned int debug:1;
} MemTxAttrs;
/* Bus masters which don't specify any attributes will get this,
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [Qemu-devel] [PATCH v12 01/28] memattrs: add debug attribute
@ 2018-03-08 12:48 ` Brijesh Singh
0 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:48 UTC (permalink / raw)
To: qemu-devel
Cc: Alistair Francis, Christian Borntraeger, Cornelia Huck,
Daniel P . Berrange, Dr. David Alan Gilbert, Michael S. Tsirkin,
Edgar E. Iglesias, Eduardo Habkost, Eric Blake, kvm,
Marcel Apfelbaum, Markus Armbruster, Paolo Bonzini,
Peter Crosthwaite, Peter Maydell, Richard Henderson,
Stefan Hajnoczi, Thomas Lendacky, Borislav Petkov,
Alexander Graf, Bruce Rogers, Brijesh Singh
Extend the MemTxAttrs to include 'debug' flag. The flag can be used as
general indicator that operation was triggered by the debugger.
Later in the patch series we set the debug=1 when issuing a memory access
from the gdbstub or HMP commands. This patch is prerequisite to support
debugging the encrypted guest. If we see request with debug=1 then we
will need to use encryption APIs to access the guest memory.
Cc: Alistair Francis <alistair.francis@xilinx.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: "Edgar E. Iglesias" <edgar.iglesias@xilinx.com>
Cc: Richard Henderson <richard.henderson@linaro.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: "Edgar E. Iglesias" <edgar.iglesias@xilinx.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
include/exec/memattrs.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/exec/memattrs.h b/include/exec/memattrs.h
index d4a16420984b..08099e4f7e72 100644
--- a/include/exec/memattrs.h
+++ b/include/exec/memattrs.h
@@ -37,6 +37,8 @@ typedef struct MemTxAttrs {
unsigned int user:1;
/* Requester ID (for MSI for example) */
unsigned int requester_id:16;
+ /* Memory access request from the debugger */
+ unsigned int debug:1;
} MemTxAttrs;
/* Bus masters which don't specify any attributes will get this,
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH v12 02/28] exec: add ram_debug_ops support
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
@ 2018-03-08 12:48 ` Brijesh Singh
-1 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:48 UTC (permalink / raw)
To: qemu-devel
Cc: Peter Maydell, Brijesh Singh, kvm, Michael S. Tsirkin,
Stefan Hajnoczi, Alexander Graf, Edgar E. Iglesias,
Markus Armbruster, Bruce Rogers, Christian Borntraeger,
Marcel Apfelbaum, Borislav Petkov, Thomas Lendacky,
Eduardo Habkost, Richard Henderson, Dr. David Alan Gilbert,
Alistair Francis, Cornelia Huck, Richard Henderson,
Peter Crosthwaite, Paolo Bonzini
Currently, the guest memory access for the debug purpose is performed
using the memcpy(). Lets extend the 'struct MemoryRegion' to include
ram_debug_ops callbacks. The ram_debug_ops can be used to override
memcpy() with something else.
The feature can be used by encrypted guest -- which can register
callbacks to override memcpy() with memory encryption/decryption APIs.
a typical usage:
mem_read(uint8_t *dst, uint8_t *src, uint32_t len, MemTxAttrs *attrs);
mem_write(uint8_t *dst, uint8_t *src, uint32_t len, MemTxAttrs *attrs);
MemoryRegionRAMReadWriteOps ops;
ops.read = mem_read;
ops.write = mem_write;
memory_region_init_ram(mem, NULL, "memory", size, NULL);
memory_region_set_ram_debug_ops(mem, ops);
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Peter Crosthwaite <crosthwaite.peter@gmail.com>
Cc: Richard Henderson <rth@twiddle.net>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
exec.c | 43 ++++++++++++++++++++++++++++++++-----------
include/exec/memory.h | 30 +++++++++++++++++++++++++++++-
2 files changed, 61 insertions(+), 12 deletions(-)
diff --git a/exec.c b/exec.c
index 604f03c535bc..f69371d30e14 100644
--- a/exec.c
+++ b/exec.c
@@ -3056,7 +3056,11 @@ static MemTxResult flatview_write_continue(FlatView *fv, hwaddr addr,
} else {
/* RAM case */
ptr = qemu_ram_ptr_length(mr->ram_block, addr1, &l, false);
- memcpy(ptr, buf, l);
+ if (attrs.debug && mr->ram_debug_ops) {
+ mr->ram_debug_ops->write(ptr, buf, l, attrs);
+ } else {
+ memcpy(ptr, buf, l);
+ }
invalidate_and_set_dirty(mr, addr1, l);
}
@@ -3144,7 +3148,11 @@ MemTxResult flatview_read_continue(FlatView *fv, hwaddr addr,
} else {
/* RAM case */
ptr = qemu_ram_ptr_length(mr->ram_block, addr1, &l, false);
- memcpy(buf, ptr, l);
+ if (attrs.debug && mr->ram_debug_ops) {
+ mr->ram_debug_ops->read(buf, ptr, l, attrs);
+ } else {
+ memcpy(buf, ptr, l);
+ }
}
if (release_lock) {
@@ -3237,7 +3245,8 @@ enum write_rom_type {
};
static inline void cpu_physical_memory_write_rom_internal(AddressSpace *as,
- hwaddr addr, const uint8_t *buf, int len, enum write_rom_type type)
+ hwaddr addr, const uint8_t *buf, int len, MemTxAttrs attrs,
+ enum write_rom_type type)
{
hwaddr l;
uint8_t *ptr;
@@ -3257,7 +3266,11 @@ static inline void cpu_physical_memory_write_rom_internal(AddressSpace *as,
ptr = qemu_map_ram_ptr(mr->ram_block, addr1);
switch (type) {
case WRITE_DATA:
- memcpy(ptr, buf, l);
+ if (mr->ram_debug_ops) {
+ mr->ram_debug_ops->write(ptr, buf, l, attrs);
+ } else {
+ memcpy(ptr, buf, l);
+ }
invalidate_and_set_dirty(mr, addr1, l);
break;
case FLUSH_CACHE:
@@ -3276,7 +3289,9 @@ static inline void cpu_physical_memory_write_rom_internal(AddressSpace *as,
void cpu_physical_memory_write_rom(AddressSpace *as, hwaddr addr,
const uint8_t *buf, int len)
{
- cpu_physical_memory_write_rom_internal(as, addr, buf, len, WRITE_DATA);
+ cpu_physical_memory_write_rom_internal(as, addr, buf, len,
+ MEMTXATTRS_UNSPECIFIED,
+ WRITE_DATA);
}
void cpu_flush_icache_range(hwaddr start, int len)
@@ -3291,8 +3306,9 @@ void cpu_flush_icache_range(hwaddr start, int len)
return;
}
- cpu_physical_memory_write_rom_internal(&address_space_memory,
- start, NULL, len, FLUSH_CACHE);
+ cpu_physical_memory_write_rom_internal(&address_space_memory, start, NULL,
+ len, MEMTXATTRS_UNSPECIFIED,
+ FLUSH_CACHE);
}
typedef struct {
@@ -3612,6 +3628,10 @@ int cpu_memory_rw_debug(CPUState *cpu, target_ulong addr,
page = addr & TARGET_PAGE_MASK;
phys_addr = cpu_get_phys_page_attrs_debug(cpu, page, &attrs);
asidx = cpu_asidx_from_attrs(cpu, attrs);
+
+ /* set debug attrs to indicate memory access is from the debugger */
+ attrs.debug = 1;
+
/* if no physical page mapped, return an error */
if (phys_addr == -1)
return -1;
@@ -3620,13 +3640,14 @@ int cpu_memory_rw_debug(CPUState *cpu, target_ulong addr,
l = len;
phys_addr += (addr & ~TARGET_PAGE_MASK);
if (is_write) {
- cpu_physical_memory_write_rom(cpu->cpu_ases[asidx].as,
- phys_addr, buf, l);
+ cpu_physical_memory_write_rom_internal(cpu->cpu_ases[asidx].as,
+ phys_addr, buf, l, attrs,
+ WRITE_DATA);
} else {
address_space_rw(cpu->cpu_ases[asidx].as, phys_addr,
- MEMTXATTRS_UNSPECIFIED,
- buf, l, 0);
+ attrs, buf, l, 0);
}
+
len -= l;
buf += l;
addr += l;
diff --git a/include/exec/memory.h b/include/exec/memory.h
index 31eae0a64062..875d39a125c6 100644
--- a/include/exec/memory.h
+++ b/include/exec/memory.h
@@ -223,6 +223,18 @@ typedef struct IOMMUMemoryRegionClass {
typedef struct CoalescedMemoryRange CoalescedMemoryRange;
typedef struct MemoryRegionIoeventfd MemoryRegionIoeventfd;
+/* Memory Region RAM debug callback */
+typedef struct MemoryRegionRAMReadWriteOps MemoryRegionRAMReadWriteOps;
+
+struct MemoryRegionRAMReadWriteOps {
+ /* Write data into guest memory */
+ int (*write) (uint8_t *dest, const uint8_t *src,
+ uint32_t len, MemTxAttrs attrs);
+ /* Read data from guest memory */
+ int (*read) (uint8_t *dest, const uint8_t *src,
+ uint32_t len, MemTxAttrs attrs);
+};
+
struct MemoryRegion {
Object parent_obj;
@@ -262,6 +274,7 @@ struct MemoryRegion {
const char *name;
unsigned ioeventfd_nb;
MemoryRegionIoeventfd *ioeventfds;
+ const MemoryRegionRAMReadWriteOps *ram_debug_ops;
};
struct IOMMUMemoryRegion {
@@ -675,6 +688,21 @@ void memory_region_init_rom_device_nomigrate(MemoryRegion *mr,
uint64_t size,
Error **errp);
+/**
+ * memory_region_set_ram_debug_ops: Set debug access ops for a given memory
+ * region.
+ *
+ * @mr: the #MemoryRegion to be initialized
+ * @ops: a function that will be used for when accessing @target region during
+ * debug
+ */
+static inline void
+memory_region_set_ram_debug_ops(MemoryRegion *mr,
+ const MemoryRegionRAMReadWriteOps *ops)
+{
+ mr->ram_debug_ops = ops;
+}
+
/**
* memory_region_init_reservation: Initialize a memory region that reserves
* I/O space.
@@ -1959,7 +1987,7 @@ MemTxResult address_space_read(AddressSpace *as, hwaddr addr,
MemoryRegion *mr;
FlatView *fv;
- if (__builtin_constant_p(len)) {
+ if (__builtin_constant_p(len) && !attrs.debug) {
if (len) {
rcu_read_lock();
fv = address_space_to_flatview(as);
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [Qemu-devel] [PATCH v12 02/28] exec: add ram_debug_ops support
@ 2018-03-08 12:48 ` Brijesh Singh
0 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:48 UTC (permalink / raw)
To: qemu-devel
Cc: Alistair Francis, Christian Borntraeger, Cornelia Huck,
Daniel P . Berrange, Dr. David Alan Gilbert, Michael S. Tsirkin,
Edgar E. Iglesias, Eduardo Habkost, Eric Blake, kvm,
Marcel Apfelbaum, Markus Armbruster, Paolo Bonzini,
Peter Crosthwaite, Peter Maydell, Richard Henderson,
Stefan Hajnoczi, Thomas Lendacky, Borislav Petkov,
Alexander Graf, Bruce Rogers, Brijesh Singh, Richard Henderson
Currently, the guest memory access for the debug purpose is performed
using the memcpy(). Lets extend the 'struct MemoryRegion' to include
ram_debug_ops callbacks. The ram_debug_ops can be used to override
memcpy() with something else.
The feature can be used by encrypted guest -- which can register
callbacks to override memcpy() with memory encryption/decryption APIs.
a typical usage:
mem_read(uint8_t *dst, uint8_t *src, uint32_t len, MemTxAttrs *attrs);
mem_write(uint8_t *dst, uint8_t *src, uint32_t len, MemTxAttrs *attrs);
MemoryRegionRAMReadWriteOps ops;
ops.read = mem_read;
ops.write = mem_write;
memory_region_init_ram(mem, NULL, "memory", size, NULL);
memory_region_set_ram_debug_ops(mem, ops);
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Peter Crosthwaite <crosthwaite.peter@gmail.com>
Cc: Richard Henderson <rth@twiddle.net>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
exec.c | 43 ++++++++++++++++++++++++++++++++-----------
include/exec/memory.h | 30 +++++++++++++++++++++++++++++-
2 files changed, 61 insertions(+), 12 deletions(-)
diff --git a/exec.c b/exec.c
index 604f03c535bc..f69371d30e14 100644
--- a/exec.c
+++ b/exec.c
@@ -3056,7 +3056,11 @@ static MemTxResult flatview_write_continue(FlatView *fv, hwaddr addr,
} else {
/* RAM case */
ptr = qemu_ram_ptr_length(mr->ram_block, addr1, &l, false);
- memcpy(ptr, buf, l);
+ if (attrs.debug && mr->ram_debug_ops) {
+ mr->ram_debug_ops->write(ptr, buf, l, attrs);
+ } else {
+ memcpy(ptr, buf, l);
+ }
invalidate_and_set_dirty(mr, addr1, l);
}
@@ -3144,7 +3148,11 @@ MemTxResult flatview_read_continue(FlatView *fv, hwaddr addr,
} else {
/* RAM case */
ptr = qemu_ram_ptr_length(mr->ram_block, addr1, &l, false);
- memcpy(buf, ptr, l);
+ if (attrs.debug && mr->ram_debug_ops) {
+ mr->ram_debug_ops->read(buf, ptr, l, attrs);
+ } else {
+ memcpy(buf, ptr, l);
+ }
}
if (release_lock) {
@@ -3237,7 +3245,8 @@ enum write_rom_type {
};
static inline void cpu_physical_memory_write_rom_internal(AddressSpace *as,
- hwaddr addr, const uint8_t *buf, int len, enum write_rom_type type)
+ hwaddr addr, const uint8_t *buf, int len, MemTxAttrs attrs,
+ enum write_rom_type type)
{
hwaddr l;
uint8_t *ptr;
@@ -3257,7 +3266,11 @@ static inline void cpu_physical_memory_write_rom_internal(AddressSpace *as,
ptr = qemu_map_ram_ptr(mr->ram_block, addr1);
switch (type) {
case WRITE_DATA:
- memcpy(ptr, buf, l);
+ if (mr->ram_debug_ops) {
+ mr->ram_debug_ops->write(ptr, buf, l, attrs);
+ } else {
+ memcpy(ptr, buf, l);
+ }
invalidate_and_set_dirty(mr, addr1, l);
break;
case FLUSH_CACHE:
@@ -3276,7 +3289,9 @@ static inline void cpu_physical_memory_write_rom_internal(AddressSpace *as,
void cpu_physical_memory_write_rom(AddressSpace *as, hwaddr addr,
const uint8_t *buf, int len)
{
- cpu_physical_memory_write_rom_internal(as, addr, buf, len, WRITE_DATA);
+ cpu_physical_memory_write_rom_internal(as, addr, buf, len,
+ MEMTXATTRS_UNSPECIFIED,
+ WRITE_DATA);
}
void cpu_flush_icache_range(hwaddr start, int len)
@@ -3291,8 +3306,9 @@ void cpu_flush_icache_range(hwaddr start, int len)
return;
}
- cpu_physical_memory_write_rom_internal(&address_space_memory,
- start, NULL, len, FLUSH_CACHE);
+ cpu_physical_memory_write_rom_internal(&address_space_memory, start, NULL,
+ len, MEMTXATTRS_UNSPECIFIED,
+ FLUSH_CACHE);
}
typedef struct {
@@ -3612,6 +3628,10 @@ int cpu_memory_rw_debug(CPUState *cpu, target_ulong addr,
page = addr & TARGET_PAGE_MASK;
phys_addr = cpu_get_phys_page_attrs_debug(cpu, page, &attrs);
asidx = cpu_asidx_from_attrs(cpu, attrs);
+
+ /* set debug attrs to indicate memory access is from the debugger */
+ attrs.debug = 1;
+
/* if no physical page mapped, return an error */
if (phys_addr == -1)
return -1;
@@ -3620,13 +3640,14 @@ int cpu_memory_rw_debug(CPUState *cpu, target_ulong addr,
l = len;
phys_addr += (addr & ~TARGET_PAGE_MASK);
if (is_write) {
- cpu_physical_memory_write_rom(cpu->cpu_ases[asidx].as,
- phys_addr, buf, l);
+ cpu_physical_memory_write_rom_internal(cpu->cpu_ases[asidx].as,
+ phys_addr, buf, l, attrs,
+ WRITE_DATA);
} else {
address_space_rw(cpu->cpu_ases[asidx].as, phys_addr,
- MEMTXATTRS_UNSPECIFIED,
- buf, l, 0);
+ attrs, buf, l, 0);
}
+
len -= l;
buf += l;
addr += l;
diff --git a/include/exec/memory.h b/include/exec/memory.h
index 31eae0a64062..875d39a125c6 100644
--- a/include/exec/memory.h
+++ b/include/exec/memory.h
@@ -223,6 +223,18 @@ typedef struct IOMMUMemoryRegionClass {
typedef struct CoalescedMemoryRange CoalescedMemoryRange;
typedef struct MemoryRegionIoeventfd MemoryRegionIoeventfd;
+/* Memory Region RAM debug callback */
+typedef struct MemoryRegionRAMReadWriteOps MemoryRegionRAMReadWriteOps;
+
+struct MemoryRegionRAMReadWriteOps {
+ /* Write data into guest memory */
+ int (*write) (uint8_t *dest, const uint8_t *src,
+ uint32_t len, MemTxAttrs attrs);
+ /* Read data from guest memory */
+ int (*read) (uint8_t *dest, const uint8_t *src,
+ uint32_t len, MemTxAttrs attrs);
+};
+
struct MemoryRegion {
Object parent_obj;
@@ -262,6 +274,7 @@ struct MemoryRegion {
const char *name;
unsigned ioeventfd_nb;
MemoryRegionIoeventfd *ioeventfds;
+ const MemoryRegionRAMReadWriteOps *ram_debug_ops;
};
struct IOMMUMemoryRegion {
@@ -675,6 +688,21 @@ void memory_region_init_rom_device_nomigrate(MemoryRegion *mr,
uint64_t size,
Error **errp);
+/**
+ * memory_region_set_ram_debug_ops: Set debug access ops for a given memory
+ * region.
+ *
+ * @mr: the #MemoryRegion to be initialized
+ * @ops: a function that will be used for when accessing @target region during
+ * debug
+ */
+static inline void
+memory_region_set_ram_debug_ops(MemoryRegion *mr,
+ const MemoryRegionRAMReadWriteOps *ops)
+{
+ mr->ram_debug_ops = ops;
+}
+
/**
* memory_region_init_reservation: Initialize a memory region that reserves
* I/O space.
@@ -1959,7 +1987,7 @@ MemTxResult address_space_read(AddressSpace *as, hwaddr addr,
MemoryRegion *mr;
FlatView *fv;
- if (__builtin_constant_p(len)) {
+ if (__builtin_constant_p(len) && !attrs.debug) {
if (len) {
rcu_read_lock();
fv = address_space_to_flatview(as);
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH v12 03/28] exec: add debug version of physical memory read and write API
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
@ 2018-03-08 12:48 ` Brijesh Singh
-1 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:48 UTC (permalink / raw)
To: qemu-devel
Cc: Peter Maydell, Brijesh Singh, kvm, Michael S. Tsirkin,
Stefan Hajnoczi, Alexander Graf, Edgar E. Iglesias,
Markus Armbruster, Bruce Rogers, Christian Borntraeger,
Marcel Apfelbaum, Borislav Petkov, Thomas Lendacky,
Eduardo Habkost, Richard Henderson, Dr. David Alan Gilbert,
Alistair Francis, Cornelia Huck, Richard Henderson,
Peter Crosthwaite, Paolo Bonzini
Adds the following new APIs
- cpu_physical_memory_read_debug
- cpu_physical_memory_write_debug
- cpu_physical_memory_rw_debug
- ldl_phys_debug
- ldq_phys_debug
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Peter Crosthwaite <crosthwaite.peter@gmail.com>
Cc: Richard Henderson <rth@twiddle.net>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
---
exec.c | 40 ++++++++++++++++++++++++++++++++++++++++
include/exec/cpu-common.h | 15 +++++++++++++++
2 files changed, 55 insertions(+)
diff --git a/exec.c b/exec.c
index f69371d30e14..ca81a2f3244f 100644
--- a/exec.c
+++ b/exec.c
@@ -3612,6 +3612,46 @@ void address_space_cache_destroy(MemoryRegionCache *cache)
#define RCU_READ_UNLOCK() rcu_read_unlock()
#include "memory_ldst.inc.c"
+uint32_t ldl_phys_debug(CPUState *cpu, hwaddr addr)
+{
+ MemTxAttrs attrs;
+ int asidx = cpu_asidx_from_attrs(cpu, attrs);
+ uint32_t val;
+
+ /* set debug attrs to indicate memory access is from the debugger */
+ attrs.debug = 1;
+
+ address_space_rw(cpu->cpu_ases[asidx].as, addr, attrs,
+ (void *) &val, 4, 0);
+
+ return tswap32(val);
+}
+
+uint64_t ldq_phys_debug(CPUState *cpu, hwaddr addr)
+{
+ MemTxAttrs attrs;
+ int asidx = cpu_asidx_from_attrs(cpu, attrs);
+ uint64_t val;
+
+ /* set debug attrs to indicate memory access is from the debugger */
+ attrs.debug = 1;
+
+ address_space_rw(cpu->cpu_ases[asidx].as, addr, attrs,
+ (void *) &val, 8, 0);
+ return val;
+}
+
+void cpu_physical_memory_rw_debug(hwaddr addr, uint8_t *buf,
+ int len, int is_write)
+{
+ MemTxAttrs attrs;
+
+ /* set debug attrs to indicate memory access is from the debugger */
+ attrs.debug = 1;
+
+ address_space_rw(&address_space_memory, addr, attrs, buf, len, is_write);
+}
+
/* virtual memory access for debug (includes writing to ROM) */
int cpu_memory_rw_debug(CPUState *cpu, target_ulong addr,
uint8_t *buf, int len, int is_write)
diff --git a/include/exec/cpu-common.h b/include/exec/cpu-common.h
index 74341b19d26a..fa01385d4f1b 100644
--- a/include/exec/cpu-common.h
+++ b/include/exec/cpu-common.h
@@ -77,11 +77,26 @@ size_t qemu_ram_pagesize_largest(void);
void cpu_physical_memory_rw(hwaddr addr, uint8_t *buf,
int len, int is_write);
+void cpu_physical_memory_rw_debug(hwaddr addr, uint8_t *buf,
+ int len, int is_write);
static inline void cpu_physical_memory_read(hwaddr addr,
void *buf, int len)
{
cpu_physical_memory_rw(addr, buf, len, 0);
}
+static inline void cpu_physical_memory_read_debug(hwaddr addr,
+ void *buf, int len)
+{
+ cpu_physical_memory_rw_debug(addr, buf, len, 0);
+}
+static inline void cpu_physical_memory_write_debug(hwaddr addr,
+ const void *buf, int len)
+{
+ cpu_physical_memory_rw_debug(addr, (void *)buf, len, 1);
+}
+uint32_t ldl_phys_debug(CPUState *cpu, hwaddr addr);
+uint64_t ldq_phys_debug(CPUState *cpu, hwaddr addr);
+
static inline void cpu_physical_memory_write(hwaddr addr,
const void *buf, int len)
{
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [Qemu-devel] [PATCH v12 03/28] exec: add debug version of physical memory read and write API
@ 2018-03-08 12:48 ` Brijesh Singh
0 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:48 UTC (permalink / raw)
To: qemu-devel
Cc: Alistair Francis, Christian Borntraeger, Cornelia Huck,
Daniel P . Berrange, Dr. David Alan Gilbert, Michael S. Tsirkin,
Edgar E. Iglesias, Eduardo Habkost, Eric Blake, kvm,
Marcel Apfelbaum, Markus Armbruster, Paolo Bonzini,
Peter Crosthwaite, Peter Maydell, Richard Henderson,
Stefan Hajnoczi, Thomas Lendacky, Borislav Petkov,
Alexander Graf, Bruce Rogers, Brijesh Singh, Richard Henderson
Adds the following new APIs
- cpu_physical_memory_read_debug
- cpu_physical_memory_write_debug
- cpu_physical_memory_rw_debug
- ldl_phys_debug
- ldq_phys_debug
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Peter Crosthwaite <crosthwaite.peter@gmail.com>
Cc: Richard Henderson <rth@twiddle.net>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
---
exec.c | 40 ++++++++++++++++++++++++++++++++++++++++
include/exec/cpu-common.h | 15 +++++++++++++++
2 files changed, 55 insertions(+)
diff --git a/exec.c b/exec.c
index f69371d30e14..ca81a2f3244f 100644
--- a/exec.c
+++ b/exec.c
@@ -3612,6 +3612,46 @@ void address_space_cache_destroy(MemoryRegionCache *cache)
#define RCU_READ_UNLOCK() rcu_read_unlock()
#include "memory_ldst.inc.c"
+uint32_t ldl_phys_debug(CPUState *cpu, hwaddr addr)
+{
+ MemTxAttrs attrs;
+ int asidx = cpu_asidx_from_attrs(cpu, attrs);
+ uint32_t val;
+
+ /* set debug attrs to indicate memory access is from the debugger */
+ attrs.debug = 1;
+
+ address_space_rw(cpu->cpu_ases[asidx].as, addr, attrs,
+ (void *) &val, 4, 0);
+
+ return tswap32(val);
+}
+
+uint64_t ldq_phys_debug(CPUState *cpu, hwaddr addr)
+{
+ MemTxAttrs attrs;
+ int asidx = cpu_asidx_from_attrs(cpu, attrs);
+ uint64_t val;
+
+ /* set debug attrs to indicate memory access is from the debugger */
+ attrs.debug = 1;
+
+ address_space_rw(cpu->cpu_ases[asidx].as, addr, attrs,
+ (void *) &val, 8, 0);
+ return val;
+}
+
+void cpu_physical_memory_rw_debug(hwaddr addr, uint8_t *buf,
+ int len, int is_write)
+{
+ MemTxAttrs attrs;
+
+ /* set debug attrs to indicate memory access is from the debugger */
+ attrs.debug = 1;
+
+ address_space_rw(&address_space_memory, addr, attrs, buf, len, is_write);
+}
+
/* virtual memory access for debug (includes writing to ROM) */
int cpu_memory_rw_debug(CPUState *cpu, target_ulong addr,
uint8_t *buf, int len, int is_write)
diff --git a/include/exec/cpu-common.h b/include/exec/cpu-common.h
index 74341b19d26a..fa01385d4f1b 100644
--- a/include/exec/cpu-common.h
+++ b/include/exec/cpu-common.h
@@ -77,11 +77,26 @@ size_t qemu_ram_pagesize_largest(void);
void cpu_physical_memory_rw(hwaddr addr, uint8_t *buf,
int len, int is_write);
+void cpu_physical_memory_rw_debug(hwaddr addr, uint8_t *buf,
+ int len, int is_write);
static inline void cpu_physical_memory_read(hwaddr addr,
void *buf, int len)
{
cpu_physical_memory_rw(addr, buf, len, 0);
}
+static inline void cpu_physical_memory_read_debug(hwaddr addr,
+ void *buf, int len)
+{
+ cpu_physical_memory_rw_debug(addr, buf, len, 0);
+}
+static inline void cpu_physical_memory_write_debug(hwaddr addr,
+ const void *buf, int len)
+{
+ cpu_physical_memory_rw_debug(addr, (void *)buf, len, 1);
+}
+uint32_t ldl_phys_debug(CPUState *cpu, hwaddr addr);
+uint64_t ldq_phys_debug(CPUState *cpu, hwaddr addr);
+
static inline void cpu_physical_memory_write(hwaddr addr,
const void *buf, int len)
{
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH v12 04/28] monitor/i386: use debug APIs when accessing guest memory
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
@ 2018-03-08 12:48 ` Brijesh Singh
-1 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:48 UTC (permalink / raw)
To: qemu-devel
Cc: Peter Maydell, Brijesh Singh, kvm, Michael S. Tsirkin,
Stefan Hajnoczi, Alexander Graf, Edgar E. Iglesias,
Markus Armbruster, Bruce Rogers, Christian Borntraeger,
Marcel Apfelbaum, Borislav Petkov, Thomas Lendacky,
Eduardo Habkost, Richard Henderson, Dr. David Alan Gilbert,
Alistair Francis, Cornelia Huck, Richard Henderson,
Peter Crosthwaite, Paolo Bonzini
Updates HMP commands to use the debug version of APIs when accessing the
guest memory.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Peter Crosthwaite <crosthwaite.peter@gmail.com>
Cc: Richard Henderson <rth@twiddle.net>
Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: Markus Armbruster <armbru@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
cpus.c | 2 +-
disas.c | 2 +-
monitor.c | 6 +++---
target/i386/helper.c | 14 ++++++------
target/i386/monitor.c | 60 +++++++++++++++++++++++++++------------------------
5 files changed, 44 insertions(+), 40 deletions(-)
diff --git a/cpus.c b/cpus.c
index 9bcff7d63c12..0dd506bcfee3 100644
--- a/cpus.c
+++ b/cpus.c
@@ -2255,7 +2255,7 @@ void qmp_pmemsave(int64_t addr, int64_t size, const char *filename,
l = sizeof(buf);
if (l > size)
l = size;
- cpu_physical_memory_read(addr, buf, l);
+ cpu_physical_memory_read_debug(addr, buf, l);
if (fwrite(buf, 1, l, f) != l) {
error_setg(errp, QERR_IO_ERROR);
goto exit;
diff --git a/disas.c b/disas.c
index d4ad1089efb3..fcedbf263302 100644
--- a/disas.c
+++ b/disas.c
@@ -586,7 +586,7 @@ static int
physical_read_memory(bfd_vma memaddr, bfd_byte *myaddr, int length,
struct disassemble_info *info)
{
- cpu_physical_memory_read(memaddr, myaddr, length);
+ cpu_physical_memory_read_debug(memaddr, myaddr, length);
return 0;
}
diff --git a/monitor.c b/monitor.c
index a4417f26cde3..3f4ba902266b 100644
--- a/monitor.c
+++ b/monitor.c
@@ -1368,7 +1368,7 @@ static void memory_dump(Monitor *mon, int count, int format, int wsize,
if (l > line_size)
l = line_size;
if (is_physical) {
- cpu_physical_memory_read(addr, buf, l);
+ cpu_physical_memory_read_debug(addr, buf, l);
} else {
if (cpu_memory_rw_debug(cs, addr, buf, l, 0) < 0) {
monitor_printf(mon, " Cannot access memory\n");
@@ -1574,8 +1574,8 @@ static void hmp_sum(Monitor *mon, const QDict *qdict)
sum = 0;
for(addr = start; addr < (start + size); addr++) {
- uint8_t val = address_space_ldub(&address_space_memory, addr,
- MEMTXATTRS_UNSPECIFIED, NULL);
+ uint8_t val;
+ cpu_physical_memory_read_debug(addr, &val, 1);
/* BSD sum algorithm ('sum' Unix command) */
sum = (sum >> 1) | (sum << 15);
sum += val;
diff --git a/target/i386/helper.c b/target/i386/helper.c
index 9fba146b7fb0..58fb6eec562a 100644
--- a/target/i386/helper.c
+++ b/target/i386/helper.c
@@ -757,7 +757,7 @@ hwaddr x86_cpu_get_phys_page_debug(CPUState *cs, vaddr addr)
if (la57) {
pml5e_addr = ((env->cr[3] & ~0xfff) +
(((addr >> 48) & 0x1ff) << 3)) & a20_mask;
- pml5e = x86_ldq_phys(cs, pml5e_addr);
+ pml5e = ldq_phys_debug(cs, pml5e_addr);
if (!(pml5e & PG_PRESENT_MASK)) {
return -1;
}
@@ -767,7 +767,7 @@ hwaddr x86_cpu_get_phys_page_debug(CPUState *cs, vaddr addr)
pml4e_addr = ((pml5e & PG_ADDRESS_MASK) +
(((addr >> 39) & 0x1ff) << 3)) & a20_mask;
- pml4e = x86_ldq_phys(cs, pml4e_addr);
+ pml4e = ldq_phys_debug(cs, pml4e_addr);
if (!(pml4e & PG_PRESENT_MASK)) {
return -1;
}
@@ -788,14 +788,14 @@ hwaddr x86_cpu_get_phys_page_debug(CPUState *cs, vaddr addr)
{
pdpe_addr = ((env->cr[3] & ~0x1f) + ((addr >> 27) & 0x18)) &
a20_mask;
- pdpe = x86_ldq_phys(cs, pdpe_addr);
+ pdpe = ldq_phys_debug(cs, pdpe_addr);
if (!(pdpe & PG_PRESENT_MASK))
return -1;
}
pde_addr = ((pdpe & PG_ADDRESS_MASK) +
(((addr >> 21) & 0x1ff) << 3)) & a20_mask;
- pde = x86_ldq_phys(cs, pde_addr);
+ pde = ldq_phys_debug(cs, pde_addr);
if (!(pde & PG_PRESENT_MASK)) {
return -1;
}
@@ -808,7 +808,7 @@ hwaddr x86_cpu_get_phys_page_debug(CPUState *cs, vaddr addr)
pte_addr = ((pde & PG_ADDRESS_MASK) +
(((addr >> 12) & 0x1ff) << 3)) & a20_mask;
page_size = 4096;
- pte = x86_ldq_phys(cs, pte_addr);
+ pte = ldq_phys_debug(cs, pte_addr);
}
if (!(pte & PG_PRESENT_MASK)) {
return -1;
@@ -818,7 +818,7 @@ hwaddr x86_cpu_get_phys_page_debug(CPUState *cs, vaddr addr)
/* page directory entry */
pde_addr = ((env->cr[3] & ~0xfff) + ((addr >> 20) & 0xffc)) & a20_mask;
- pde = x86_ldl_phys(cs, pde_addr);
+ pde = ldl_phys_debug(cs, pde_addr);
if (!(pde & PG_PRESENT_MASK))
return -1;
if ((pde & PG_PSE_MASK) && (env->cr[4] & CR4_PSE_MASK)) {
@@ -827,7 +827,7 @@ hwaddr x86_cpu_get_phys_page_debug(CPUState *cs, vaddr addr)
} else {
/* page directory entry */
pte_addr = ((pde & ~0xfff) + ((addr >> 10) & 0xffc)) & a20_mask;
- pte = x86_ldl_phys(cs, pte_addr);
+ pte = ldl_phys_debug(cs, pte_addr);
if (!(pte & PG_PRESENT_MASK)) {
return -1;
}
diff --git a/target/i386/monitor.c b/target/i386/monitor.c
index 75429129fde0..55ea10deb8ef 100644
--- a/target/i386/monitor.c
+++ b/target/i386/monitor.c
@@ -68,7 +68,7 @@ static void tlb_info_32(Monitor *mon, CPUArchState *env)
pgd = env->cr[3] & ~0xfff;
for(l1 = 0; l1 < 1024; l1++) {
- cpu_physical_memory_read(pgd + l1 * 4, &pde, 4);
+ cpu_physical_memory_read_debug(pgd + l1 * 4, &pde, 4);
pde = le32_to_cpu(pde);
if (pde & PG_PRESENT_MASK) {
if ((pde & PG_PSE_MASK) && (env->cr[4] & CR4_PSE_MASK)) {
@@ -76,7 +76,8 @@ static void tlb_info_32(Monitor *mon, CPUArchState *env)
print_pte(mon, env, (l1 << 22), pde, ~((1 << 21) - 1));
} else {
for(l2 = 0; l2 < 1024; l2++) {
- cpu_physical_memory_read((pde & ~0xfff) + l2 * 4, &pte, 4);
+ cpu_physical_memory_read_debug((pde & ~0xfff) + l2 * 4,
+ &pte, 4);
pte = le32_to_cpu(pte);
if (pte & PG_PRESENT_MASK) {
print_pte(mon, env, (l1 << 22) + (l2 << 12),
@@ -97,12 +98,12 @@ static void tlb_info_pae32(Monitor *mon, CPUArchState *env)
pdp_addr = env->cr[3] & ~0x1f;
for (l1 = 0; l1 < 4; l1++) {
- cpu_physical_memory_read(pdp_addr + l1 * 8, &pdpe, 8);
+ cpu_physical_memory_read_debug(pdp_addr + l1 * 8, &pdpe, 8);
pdpe = le64_to_cpu(pdpe);
if (pdpe & PG_PRESENT_MASK) {
pd_addr = pdpe & 0x3fffffffff000ULL;
for (l2 = 0; l2 < 512; l2++) {
- cpu_physical_memory_read(pd_addr + l2 * 8, &pde, 8);
+ cpu_physical_memory_read_debug(pd_addr + l2 * 8, &pde, 8);
pde = le64_to_cpu(pde);
if (pde & PG_PRESENT_MASK) {
if (pde & PG_PSE_MASK) {
@@ -112,7 +113,8 @@ static void tlb_info_pae32(Monitor *mon, CPUArchState *env)
} else {
pt_addr = pde & 0x3fffffffff000ULL;
for (l3 = 0; l3 < 512; l3++) {
- cpu_physical_memory_read(pt_addr + l3 * 8, &pte, 8);
+ cpu_physical_memory_read_debug(pt_addr + l3 * 8,
+ &pte, 8);
pte = le64_to_cpu(pte);
if (pte & PG_PRESENT_MASK) {
print_pte(mon, env, (l1 << 30) + (l2 << 21)
@@ -137,7 +139,7 @@ static void tlb_info_la48(Monitor *mon, CPUArchState *env,
uint64_t pdp_addr, pd_addr, pt_addr;
for (l1 = 0; l1 < 512; l1++) {
- cpu_physical_memory_read(pml4_addr + l1 * 8, &pml4e, 8);
+ cpu_physical_memory_read_debug(pml4_addr + l1 * 8, &pml4e, 8);
pml4e = le64_to_cpu(pml4e);
if (!(pml4e & PG_PRESENT_MASK)) {
continue;
@@ -145,7 +147,7 @@ static void tlb_info_la48(Monitor *mon, CPUArchState *env,
pdp_addr = pml4e & 0x3fffffffff000ULL;
for (l2 = 0; l2 < 512; l2++) {
- cpu_physical_memory_read(pdp_addr + l2 * 8, &pdpe, 8);
+ cpu_physical_memory_read_debug(pdp_addr + l2 * 8, &pdpe, 8);
pdpe = le64_to_cpu(pdpe);
if (!(pdpe & PG_PRESENT_MASK)) {
continue;
@@ -160,7 +162,7 @@ static void tlb_info_la48(Monitor *mon, CPUArchState *env,
pd_addr = pdpe & 0x3fffffffff000ULL;
for (l3 = 0; l3 < 512; l3++) {
- cpu_physical_memory_read(pd_addr + l3 * 8, &pde, 8);
+ cpu_physical_memory_read_debug(pd_addr + l3 * 8, &pde, 8);
pde = le64_to_cpu(pde);
if (!(pde & PG_PRESENT_MASK)) {
continue;
@@ -175,9 +177,7 @@ static void tlb_info_la48(Monitor *mon, CPUArchState *env,
pt_addr = pde & 0x3fffffffff000ULL;
for (l4 = 0; l4 < 512; l4++) {
- cpu_physical_memory_read(pt_addr
- + l4 * 8,
- &pte, 8);
+ cpu_physical_memory_read_debug(pt_addr + l4 * 8, &pte, 8);
pte = le64_to_cpu(pte);
if (pte & PG_PRESENT_MASK) {
print_pte(mon, env, (l0 << 48) + (l1 << 39) +
@@ -198,7 +198,7 @@ static void tlb_info_la57(Monitor *mon, CPUArchState *env)
pml5_addr = env->cr[3] & 0x3fffffffff000ULL;
for (l0 = 0; l0 < 512; l0++) {
- cpu_physical_memory_read(pml5_addr + l0 * 8, &pml5e, 8);
+ cpu_physical_memory_read_debug(pml5_addr + l0 * 8, &pml5e, 8);
pml5e = le64_to_cpu(pml5e);
if (pml5e & PG_PRESENT_MASK) {
tlb_info_la48(mon, env, l0, pml5e & 0x3fffffffff000ULL);
@@ -273,7 +273,7 @@ static void mem_info_32(Monitor *mon, CPUArchState *env)
last_prot = 0;
start = -1;
for(l1 = 0; l1 < 1024; l1++) {
- cpu_physical_memory_read(pgd + l1 * 4, &pde, 4);
+ cpu_physical_memory_read_debug(pgd + l1 * 4, &pde, 4);
pde = le32_to_cpu(pde);
end = l1 << 22;
if (pde & PG_PRESENT_MASK) {
@@ -282,7 +282,8 @@ static void mem_info_32(Monitor *mon, CPUArchState *env)
mem_print(mon, &start, &last_prot, end, prot);
} else {
for(l2 = 0; l2 < 1024; l2++) {
- cpu_physical_memory_read((pde & ~0xfff) + l2 * 4, &pte, 4);
+ cpu_physical_memory_read_debug((pde & ~0xfff) + l2 * 4,
+ &pte, 4);
pte = le32_to_cpu(pte);
end = (l1 << 22) + (l2 << 12);
if (pte & PG_PRESENT_MASK) {
@@ -315,13 +316,13 @@ static void mem_info_pae32(Monitor *mon, CPUArchState *env)
last_prot = 0;
start = -1;
for (l1 = 0; l1 < 4; l1++) {
- cpu_physical_memory_read(pdp_addr + l1 * 8, &pdpe, 8);
+ cpu_physical_memory_read_debug(pdp_addr + l1 * 8, &pdpe, 8);
pdpe = le64_to_cpu(pdpe);
end = l1 << 30;
if (pdpe & PG_PRESENT_MASK) {
pd_addr = pdpe & 0x3fffffffff000ULL;
for (l2 = 0; l2 < 512; l2++) {
- cpu_physical_memory_read(pd_addr + l2 * 8, &pde, 8);
+ cpu_physical_memory_read_debug(pd_addr + l2 * 8, &pde, 8);
pde = le64_to_cpu(pde);
end = (l1 << 30) + (l2 << 21);
if (pde & PG_PRESENT_MASK) {
@@ -332,7 +333,8 @@ static void mem_info_pae32(Monitor *mon, CPUArchState *env)
} else {
pt_addr = pde & 0x3fffffffff000ULL;
for (l3 = 0; l3 < 512; l3++) {
- cpu_physical_memory_read(pt_addr + l3 * 8, &pte, 8);
+ cpu_physical_memory_read_debug(pt_addr + l3 * 8,
+ &pte, 8);
pte = le64_to_cpu(pte);
end = (l1 << 30) + (l2 << 21) + (l3 << 12);
if (pte & PG_PRESENT_MASK) {
@@ -371,13 +373,13 @@ static void mem_info_la48(Monitor *mon, CPUArchState *env)
last_prot = 0;
start = -1;
for (l1 = 0; l1 < 512; l1++) {
- cpu_physical_memory_read(pml4_addr + l1 * 8, &pml4e, 8);
+ cpu_physical_memory_read_debug(pml4_addr + l1 * 8, &pml4e, 8);
pml4e = le64_to_cpu(pml4e);
end = l1 << 39;
if (pml4e & PG_PRESENT_MASK) {
pdp_addr = pml4e & 0x3fffffffff000ULL;
for (l2 = 0; l2 < 512; l2++) {
- cpu_physical_memory_read(pdp_addr + l2 * 8, &pdpe, 8);
+ cpu_physical_memory_read_debug(pdp_addr + l2 * 8, &pdpe, 8);
pdpe = le64_to_cpu(pdpe);
end = (l1 << 39) + (l2 << 30);
if (pdpe & PG_PRESENT_MASK) {
@@ -389,7 +391,8 @@ static void mem_info_la48(Monitor *mon, CPUArchState *env)
} else {
pd_addr = pdpe & 0x3fffffffff000ULL;
for (l3 = 0; l3 < 512; l3++) {
- cpu_physical_memory_read(pd_addr + l3 * 8, &pde, 8);
+ cpu_physical_memory_read_debug(pd_addr + l3 * 8,
+ &pde, 8);
pde = le64_to_cpu(pde);
end = (l1 << 39) + (l2 << 30) + (l3 << 21);
if (pde & PG_PRESENT_MASK) {
@@ -401,9 +404,9 @@ static void mem_info_la48(Monitor *mon, CPUArchState *env)
} else {
pt_addr = pde & 0x3fffffffff000ULL;
for (l4 = 0; l4 < 512; l4++) {
- cpu_physical_memory_read(pt_addr
- + l4 * 8,
- &pte, 8);
+ cpu_physical_memory_read_debug(pt_addr
+ + l4 * 8,
+ &pte, 8);
pte = le64_to_cpu(pte);
end = (l1 << 39) + (l2 << 30) +
(l3 << 21) + (l4 << 12);
@@ -448,7 +451,7 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env)
last_prot = 0;
start = -1;
for (l0 = 0; l0 < 512; l0++) {
- cpu_physical_memory_read(pml5_addr + l0 * 8, &pml5e, 8);
+ cpu_physical_memory_read_debug(pml5_addr + l0 * 8, &pml5e, 8);
pml5e = le64_to_cpu(pml5e);
end = l0 << 48;
if (!(pml5e & PG_PRESENT_MASK)) {
@@ -459,7 +462,7 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env)
pml4_addr = pml5e & 0x3fffffffff000ULL;
for (l1 = 0; l1 < 512; l1++) {
- cpu_physical_memory_read(pml4_addr + l1 * 8, &pml4e, 8);
+ cpu_physical_memory_read_debug(pml4_addr + l1 * 8, &pml4e, 8);
pml4e = le64_to_cpu(pml4e);
end = (l0 << 48) + (l1 << 39);
if (!(pml4e & PG_PRESENT_MASK)) {
@@ -470,7 +473,7 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env)
pdp_addr = pml4e & 0x3fffffffff000ULL;
for (l2 = 0; l2 < 512; l2++) {
- cpu_physical_memory_read(pdp_addr + l2 * 8, &pdpe, 8);
+ cpu_physical_memory_read_debug(pdp_addr + l2 * 8, &pdpe, 8);
pdpe = le64_to_cpu(pdpe);
end = (l0 << 48) + (l1 << 39) + (l2 << 30);
if (pdpe & PG_PRESENT_MASK) {
@@ -489,7 +492,7 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env)
pd_addr = pdpe & 0x3fffffffff000ULL;
for (l3 = 0; l3 < 512; l3++) {
- cpu_physical_memory_read(pd_addr + l3 * 8, &pde, 8);
+ cpu_physical_memory_read_debug(pd_addr + l3 * 8, &pde, 8);
pde = le64_to_cpu(pde);
end = (l0 << 48) + (l1 << 39) + (l2 << 30) + (l3 << 21);
if (pde & PG_PRESENT_MASK) {
@@ -508,7 +511,8 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env)
pt_addr = pde & 0x3fffffffff000ULL;
for (l4 = 0; l4 < 512; l4++) {
- cpu_physical_memory_read(pt_addr + l4 * 8, &pte, 8);
+ cpu_physical_memory_read_debug(pt_addr + l4 * 8,
+ &pte, 8);
pte = le64_to_cpu(pte);
end = (l0 << 48) + (l1 << 39) + (l2 << 30) +
(l3 << 21) + (l4 << 12);
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [Qemu-devel] [PATCH v12 04/28] monitor/i386: use debug APIs when accessing guest memory
@ 2018-03-08 12:48 ` Brijesh Singh
0 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:48 UTC (permalink / raw)
To: qemu-devel
Cc: Alistair Francis, Christian Borntraeger, Cornelia Huck,
Daniel P . Berrange, Dr. David Alan Gilbert, Michael S. Tsirkin,
Edgar E. Iglesias, Eduardo Habkost, Eric Blake, kvm,
Marcel Apfelbaum, Markus Armbruster, Paolo Bonzini,
Peter Crosthwaite, Peter Maydell, Richard Henderson,
Stefan Hajnoczi, Thomas Lendacky, Borislav Petkov,
Alexander Graf, Bruce Rogers, Brijesh Singh, Richard Henderson
Updates HMP commands to use the debug version of APIs when accessing the
guest memory.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Peter Crosthwaite <crosthwaite.peter@gmail.com>
Cc: Richard Henderson <rth@twiddle.net>
Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: Markus Armbruster <armbru@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
cpus.c | 2 +-
disas.c | 2 +-
monitor.c | 6 +++---
target/i386/helper.c | 14 ++++++------
target/i386/monitor.c | 60 +++++++++++++++++++++++++++------------------------
5 files changed, 44 insertions(+), 40 deletions(-)
diff --git a/cpus.c b/cpus.c
index 9bcff7d63c12..0dd506bcfee3 100644
--- a/cpus.c
+++ b/cpus.c
@@ -2255,7 +2255,7 @@ void qmp_pmemsave(int64_t addr, int64_t size, const char *filename,
l = sizeof(buf);
if (l > size)
l = size;
- cpu_physical_memory_read(addr, buf, l);
+ cpu_physical_memory_read_debug(addr, buf, l);
if (fwrite(buf, 1, l, f) != l) {
error_setg(errp, QERR_IO_ERROR);
goto exit;
diff --git a/disas.c b/disas.c
index d4ad1089efb3..fcedbf263302 100644
--- a/disas.c
+++ b/disas.c
@@ -586,7 +586,7 @@ static int
physical_read_memory(bfd_vma memaddr, bfd_byte *myaddr, int length,
struct disassemble_info *info)
{
- cpu_physical_memory_read(memaddr, myaddr, length);
+ cpu_physical_memory_read_debug(memaddr, myaddr, length);
return 0;
}
diff --git a/monitor.c b/monitor.c
index a4417f26cde3..3f4ba902266b 100644
--- a/monitor.c
+++ b/monitor.c
@@ -1368,7 +1368,7 @@ static void memory_dump(Monitor *mon, int count, int format, int wsize,
if (l > line_size)
l = line_size;
if (is_physical) {
- cpu_physical_memory_read(addr, buf, l);
+ cpu_physical_memory_read_debug(addr, buf, l);
} else {
if (cpu_memory_rw_debug(cs, addr, buf, l, 0) < 0) {
monitor_printf(mon, " Cannot access memory\n");
@@ -1574,8 +1574,8 @@ static void hmp_sum(Monitor *mon, const QDict *qdict)
sum = 0;
for(addr = start; addr < (start + size); addr++) {
- uint8_t val = address_space_ldub(&address_space_memory, addr,
- MEMTXATTRS_UNSPECIFIED, NULL);
+ uint8_t val;
+ cpu_physical_memory_read_debug(addr, &val, 1);
/* BSD sum algorithm ('sum' Unix command) */
sum = (sum >> 1) | (sum << 15);
sum += val;
diff --git a/target/i386/helper.c b/target/i386/helper.c
index 9fba146b7fb0..58fb6eec562a 100644
--- a/target/i386/helper.c
+++ b/target/i386/helper.c
@@ -757,7 +757,7 @@ hwaddr x86_cpu_get_phys_page_debug(CPUState *cs, vaddr addr)
if (la57) {
pml5e_addr = ((env->cr[3] & ~0xfff) +
(((addr >> 48) & 0x1ff) << 3)) & a20_mask;
- pml5e = x86_ldq_phys(cs, pml5e_addr);
+ pml5e = ldq_phys_debug(cs, pml5e_addr);
if (!(pml5e & PG_PRESENT_MASK)) {
return -1;
}
@@ -767,7 +767,7 @@ hwaddr x86_cpu_get_phys_page_debug(CPUState *cs, vaddr addr)
pml4e_addr = ((pml5e & PG_ADDRESS_MASK) +
(((addr >> 39) & 0x1ff) << 3)) & a20_mask;
- pml4e = x86_ldq_phys(cs, pml4e_addr);
+ pml4e = ldq_phys_debug(cs, pml4e_addr);
if (!(pml4e & PG_PRESENT_MASK)) {
return -1;
}
@@ -788,14 +788,14 @@ hwaddr x86_cpu_get_phys_page_debug(CPUState *cs, vaddr addr)
{
pdpe_addr = ((env->cr[3] & ~0x1f) + ((addr >> 27) & 0x18)) &
a20_mask;
- pdpe = x86_ldq_phys(cs, pdpe_addr);
+ pdpe = ldq_phys_debug(cs, pdpe_addr);
if (!(pdpe & PG_PRESENT_MASK))
return -1;
}
pde_addr = ((pdpe & PG_ADDRESS_MASK) +
(((addr >> 21) & 0x1ff) << 3)) & a20_mask;
- pde = x86_ldq_phys(cs, pde_addr);
+ pde = ldq_phys_debug(cs, pde_addr);
if (!(pde & PG_PRESENT_MASK)) {
return -1;
}
@@ -808,7 +808,7 @@ hwaddr x86_cpu_get_phys_page_debug(CPUState *cs, vaddr addr)
pte_addr = ((pde & PG_ADDRESS_MASK) +
(((addr >> 12) & 0x1ff) << 3)) & a20_mask;
page_size = 4096;
- pte = x86_ldq_phys(cs, pte_addr);
+ pte = ldq_phys_debug(cs, pte_addr);
}
if (!(pte & PG_PRESENT_MASK)) {
return -1;
@@ -818,7 +818,7 @@ hwaddr x86_cpu_get_phys_page_debug(CPUState *cs, vaddr addr)
/* page directory entry */
pde_addr = ((env->cr[3] & ~0xfff) + ((addr >> 20) & 0xffc)) & a20_mask;
- pde = x86_ldl_phys(cs, pde_addr);
+ pde = ldl_phys_debug(cs, pde_addr);
if (!(pde & PG_PRESENT_MASK))
return -1;
if ((pde & PG_PSE_MASK) && (env->cr[4] & CR4_PSE_MASK)) {
@@ -827,7 +827,7 @@ hwaddr x86_cpu_get_phys_page_debug(CPUState *cs, vaddr addr)
} else {
/* page directory entry */
pte_addr = ((pde & ~0xfff) + ((addr >> 10) & 0xffc)) & a20_mask;
- pte = x86_ldl_phys(cs, pte_addr);
+ pte = ldl_phys_debug(cs, pte_addr);
if (!(pte & PG_PRESENT_MASK)) {
return -1;
}
diff --git a/target/i386/monitor.c b/target/i386/monitor.c
index 75429129fde0..55ea10deb8ef 100644
--- a/target/i386/monitor.c
+++ b/target/i386/monitor.c
@@ -68,7 +68,7 @@ static void tlb_info_32(Monitor *mon, CPUArchState *env)
pgd = env->cr[3] & ~0xfff;
for(l1 = 0; l1 < 1024; l1++) {
- cpu_physical_memory_read(pgd + l1 * 4, &pde, 4);
+ cpu_physical_memory_read_debug(pgd + l1 * 4, &pde, 4);
pde = le32_to_cpu(pde);
if (pde & PG_PRESENT_MASK) {
if ((pde & PG_PSE_MASK) && (env->cr[4] & CR4_PSE_MASK)) {
@@ -76,7 +76,8 @@ static void tlb_info_32(Monitor *mon, CPUArchState *env)
print_pte(mon, env, (l1 << 22), pde, ~((1 << 21) - 1));
} else {
for(l2 = 0; l2 < 1024; l2++) {
- cpu_physical_memory_read((pde & ~0xfff) + l2 * 4, &pte, 4);
+ cpu_physical_memory_read_debug((pde & ~0xfff) + l2 * 4,
+ &pte, 4);
pte = le32_to_cpu(pte);
if (pte & PG_PRESENT_MASK) {
print_pte(mon, env, (l1 << 22) + (l2 << 12),
@@ -97,12 +98,12 @@ static void tlb_info_pae32(Monitor *mon, CPUArchState *env)
pdp_addr = env->cr[3] & ~0x1f;
for (l1 = 0; l1 < 4; l1++) {
- cpu_physical_memory_read(pdp_addr + l1 * 8, &pdpe, 8);
+ cpu_physical_memory_read_debug(pdp_addr + l1 * 8, &pdpe, 8);
pdpe = le64_to_cpu(pdpe);
if (pdpe & PG_PRESENT_MASK) {
pd_addr = pdpe & 0x3fffffffff000ULL;
for (l2 = 0; l2 < 512; l2++) {
- cpu_physical_memory_read(pd_addr + l2 * 8, &pde, 8);
+ cpu_physical_memory_read_debug(pd_addr + l2 * 8, &pde, 8);
pde = le64_to_cpu(pde);
if (pde & PG_PRESENT_MASK) {
if (pde & PG_PSE_MASK) {
@@ -112,7 +113,8 @@ static void tlb_info_pae32(Monitor *mon, CPUArchState *env)
} else {
pt_addr = pde & 0x3fffffffff000ULL;
for (l3 = 0; l3 < 512; l3++) {
- cpu_physical_memory_read(pt_addr + l3 * 8, &pte, 8);
+ cpu_physical_memory_read_debug(pt_addr + l3 * 8,
+ &pte, 8);
pte = le64_to_cpu(pte);
if (pte & PG_PRESENT_MASK) {
print_pte(mon, env, (l1 << 30) + (l2 << 21)
@@ -137,7 +139,7 @@ static void tlb_info_la48(Monitor *mon, CPUArchState *env,
uint64_t pdp_addr, pd_addr, pt_addr;
for (l1 = 0; l1 < 512; l1++) {
- cpu_physical_memory_read(pml4_addr + l1 * 8, &pml4e, 8);
+ cpu_physical_memory_read_debug(pml4_addr + l1 * 8, &pml4e, 8);
pml4e = le64_to_cpu(pml4e);
if (!(pml4e & PG_PRESENT_MASK)) {
continue;
@@ -145,7 +147,7 @@ static void tlb_info_la48(Monitor *mon, CPUArchState *env,
pdp_addr = pml4e & 0x3fffffffff000ULL;
for (l2 = 0; l2 < 512; l2++) {
- cpu_physical_memory_read(pdp_addr + l2 * 8, &pdpe, 8);
+ cpu_physical_memory_read_debug(pdp_addr + l2 * 8, &pdpe, 8);
pdpe = le64_to_cpu(pdpe);
if (!(pdpe & PG_PRESENT_MASK)) {
continue;
@@ -160,7 +162,7 @@ static void tlb_info_la48(Monitor *mon, CPUArchState *env,
pd_addr = pdpe & 0x3fffffffff000ULL;
for (l3 = 0; l3 < 512; l3++) {
- cpu_physical_memory_read(pd_addr + l3 * 8, &pde, 8);
+ cpu_physical_memory_read_debug(pd_addr + l3 * 8, &pde, 8);
pde = le64_to_cpu(pde);
if (!(pde & PG_PRESENT_MASK)) {
continue;
@@ -175,9 +177,7 @@ static void tlb_info_la48(Monitor *mon, CPUArchState *env,
pt_addr = pde & 0x3fffffffff000ULL;
for (l4 = 0; l4 < 512; l4++) {
- cpu_physical_memory_read(pt_addr
- + l4 * 8,
- &pte, 8);
+ cpu_physical_memory_read_debug(pt_addr + l4 * 8, &pte, 8);
pte = le64_to_cpu(pte);
if (pte & PG_PRESENT_MASK) {
print_pte(mon, env, (l0 << 48) + (l1 << 39) +
@@ -198,7 +198,7 @@ static void tlb_info_la57(Monitor *mon, CPUArchState *env)
pml5_addr = env->cr[3] & 0x3fffffffff000ULL;
for (l0 = 0; l0 < 512; l0++) {
- cpu_physical_memory_read(pml5_addr + l0 * 8, &pml5e, 8);
+ cpu_physical_memory_read_debug(pml5_addr + l0 * 8, &pml5e, 8);
pml5e = le64_to_cpu(pml5e);
if (pml5e & PG_PRESENT_MASK) {
tlb_info_la48(mon, env, l0, pml5e & 0x3fffffffff000ULL);
@@ -273,7 +273,7 @@ static void mem_info_32(Monitor *mon, CPUArchState *env)
last_prot = 0;
start = -1;
for(l1 = 0; l1 < 1024; l1++) {
- cpu_physical_memory_read(pgd + l1 * 4, &pde, 4);
+ cpu_physical_memory_read_debug(pgd + l1 * 4, &pde, 4);
pde = le32_to_cpu(pde);
end = l1 << 22;
if (pde & PG_PRESENT_MASK) {
@@ -282,7 +282,8 @@ static void mem_info_32(Monitor *mon, CPUArchState *env)
mem_print(mon, &start, &last_prot, end, prot);
} else {
for(l2 = 0; l2 < 1024; l2++) {
- cpu_physical_memory_read((pde & ~0xfff) + l2 * 4, &pte, 4);
+ cpu_physical_memory_read_debug((pde & ~0xfff) + l2 * 4,
+ &pte, 4);
pte = le32_to_cpu(pte);
end = (l1 << 22) + (l2 << 12);
if (pte & PG_PRESENT_MASK) {
@@ -315,13 +316,13 @@ static void mem_info_pae32(Monitor *mon, CPUArchState *env)
last_prot = 0;
start = -1;
for (l1 = 0; l1 < 4; l1++) {
- cpu_physical_memory_read(pdp_addr + l1 * 8, &pdpe, 8);
+ cpu_physical_memory_read_debug(pdp_addr + l1 * 8, &pdpe, 8);
pdpe = le64_to_cpu(pdpe);
end = l1 << 30;
if (pdpe & PG_PRESENT_MASK) {
pd_addr = pdpe & 0x3fffffffff000ULL;
for (l2 = 0; l2 < 512; l2++) {
- cpu_physical_memory_read(pd_addr + l2 * 8, &pde, 8);
+ cpu_physical_memory_read_debug(pd_addr + l2 * 8, &pde, 8);
pde = le64_to_cpu(pde);
end = (l1 << 30) + (l2 << 21);
if (pde & PG_PRESENT_MASK) {
@@ -332,7 +333,8 @@ static void mem_info_pae32(Monitor *mon, CPUArchState *env)
} else {
pt_addr = pde & 0x3fffffffff000ULL;
for (l3 = 0; l3 < 512; l3++) {
- cpu_physical_memory_read(pt_addr + l3 * 8, &pte, 8);
+ cpu_physical_memory_read_debug(pt_addr + l3 * 8,
+ &pte, 8);
pte = le64_to_cpu(pte);
end = (l1 << 30) + (l2 << 21) + (l3 << 12);
if (pte & PG_PRESENT_MASK) {
@@ -371,13 +373,13 @@ static void mem_info_la48(Monitor *mon, CPUArchState *env)
last_prot = 0;
start = -1;
for (l1 = 0; l1 < 512; l1++) {
- cpu_physical_memory_read(pml4_addr + l1 * 8, &pml4e, 8);
+ cpu_physical_memory_read_debug(pml4_addr + l1 * 8, &pml4e, 8);
pml4e = le64_to_cpu(pml4e);
end = l1 << 39;
if (pml4e & PG_PRESENT_MASK) {
pdp_addr = pml4e & 0x3fffffffff000ULL;
for (l2 = 0; l2 < 512; l2++) {
- cpu_physical_memory_read(pdp_addr + l2 * 8, &pdpe, 8);
+ cpu_physical_memory_read_debug(pdp_addr + l2 * 8, &pdpe, 8);
pdpe = le64_to_cpu(pdpe);
end = (l1 << 39) + (l2 << 30);
if (pdpe & PG_PRESENT_MASK) {
@@ -389,7 +391,8 @@ static void mem_info_la48(Monitor *mon, CPUArchState *env)
} else {
pd_addr = pdpe & 0x3fffffffff000ULL;
for (l3 = 0; l3 < 512; l3++) {
- cpu_physical_memory_read(pd_addr + l3 * 8, &pde, 8);
+ cpu_physical_memory_read_debug(pd_addr + l3 * 8,
+ &pde, 8);
pde = le64_to_cpu(pde);
end = (l1 << 39) + (l2 << 30) + (l3 << 21);
if (pde & PG_PRESENT_MASK) {
@@ -401,9 +404,9 @@ static void mem_info_la48(Monitor *mon, CPUArchState *env)
} else {
pt_addr = pde & 0x3fffffffff000ULL;
for (l4 = 0; l4 < 512; l4++) {
- cpu_physical_memory_read(pt_addr
- + l4 * 8,
- &pte, 8);
+ cpu_physical_memory_read_debug(pt_addr
+ + l4 * 8,
+ &pte, 8);
pte = le64_to_cpu(pte);
end = (l1 << 39) + (l2 << 30) +
(l3 << 21) + (l4 << 12);
@@ -448,7 +451,7 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env)
last_prot = 0;
start = -1;
for (l0 = 0; l0 < 512; l0++) {
- cpu_physical_memory_read(pml5_addr + l0 * 8, &pml5e, 8);
+ cpu_physical_memory_read_debug(pml5_addr + l0 * 8, &pml5e, 8);
pml5e = le64_to_cpu(pml5e);
end = l0 << 48;
if (!(pml5e & PG_PRESENT_MASK)) {
@@ -459,7 +462,7 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env)
pml4_addr = pml5e & 0x3fffffffff000ULL;
for (l1 = 0; l1 < 512; l1++) {
- cpu_physical_memory_read(pml4_addr + l1 * 8, &pml4e, 8);
+ cpu_physical_memory_read_debug(pml4_addr + l1 * 8, &pml4e, 8);
pml4e = le64_to_cpu(pml4e);
end = (l0 << 48) + (l1 << 39);
if (!(pml4e & PG_PRESENT_MASK)) {
@@ -470,7 +473,7 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env)
pdp_addr = pml4e & 0x3fffffffff000ULL;
for (l2 = 0; l2 < 512; l2++) {
- cpu_physical_memory_read(pdp_addr + l2 * 8, &pdpe, 8);
+ cpu_physical_memory_read_debug(pdp_addr + l2 * 8, &pdpe, 8);
pdpe = le64_to_cpu(pdpe);
end = (l0 << 48) + (l1 << 39) + (l2 << 30);
if (pdpe & PG_PRESENT_MASK) {
@@ -489,7 +492,7 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env)
pd_addr = pdpe & 0x3fffffffff000ULL;
for (l3 = 0; l3 < 512; l3++) {
- cpu_physical_memory_read(pd_addr + l3 * 8, &pde, 8);
+ cpu_physical_memory_read_debug(pd_addr + l3 * 8, &pde, 8);
pde = le64_to_cpu(pde);
end = (l0 << 48) + (l1 << 39) + (l2 << 30) + (l3 << 21);
if (pde & PG_PRESENT_MASK) {
@@ -508,7 +511,8 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env)
pt_addr = pde & 0x3fffffffff000ULL;
for (l4 = 0; l4 < 512; l4++) {
- cpu_physical_memory_read(pt_addr + l4 * 8, &pte, 8);
+ cpu_physical_memory_read_debug(pt_addr + l4 * 8,
+ &pte, 8);
pte = le64_to_cpu(pte);
end = (l0 << 48) + (l1 << 39) + (l2 << 30) +
(l3 << 21) + (l4 << 12);
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH v12 05/28] machine: add -memory-encryption property
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
@ 2018-03-08 12:48 ` Brijesh Singh
-1 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:48 UTC (permalink / raw)
To: qemu-devel
Cc: Peter Maydell, Brijesh Singh, kvm, Michael S. Tsirkin,
Stefan Hajnoczi, Alexander Graf, Edgar E. Iglesias,
Markus Armbruster, Bruce Rogers, Christian Borntraeger,
Marcel Apfelbaum, Borislav Petkov, Thomas Lendacky,
Eduardo Habkost, Richard Henderson, Dr. David Alan Gilbert,
Alistair Francis, Cornelia Huck, Peter Crosthwaite,
Paolo Bonzini
When CPU supports memory encryption feature, the property can be used to
specify the encryption object to use when launching an encrypted guest.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Cc: Stefan Hajnoczi <stefanha@gmail.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
hw/core/machine.c | 22 ++++++++++++++++++++++
include/hw/boards.h | 1 +
qemu-options.hx | 5 ++++-
3 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/hw/core/machine.c b/hw/core/machine.c
index 5e2bbcdacedb..2040177664d5 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -334,6 +334,22 @@ static bool machine_get_enforce_config_section(Object *obj, Error **errp)
return ms->enforce_config_section;
}
+static char *machine_get_memory_encryption(Object *obj, Error **errp)
+{
+ MachineState *ms = MACHINE(obj);
+
+ return g_strdup(ms->memory_encryption);
+}
+
+static void machine_set_memory_encryption(Object *obj, const char *value,
+ Error **errp)
+{
+ MachineState *ms = MACHINE(obj);
+
+ g_free(ms->memory_encryption);
+ ms->memory_encryption = g_strdup(value);
+}
+
void machine_class_allow_dynamic_sysbus_dev(MachineClass *mc, const char *type)
{
strList *item = g_new0(strList, 1);
@@ -612,6 +628,12 @@ static void machine_class_init(ObjectClass *oc, void *data)
&error_abort);
object_class_property_set_description(oc, "enforce-config-section",
"Set on to enforce configuration section migration", &error_abort);
+
+ object_class_property_add_str(oc, "memory-encryption",
+ machine_get_memory_encryption, machine_set_memory_encryption,
+ &error_abort);
+ object_class_property_set_description(oc, "memory-encryption",
+ "Set memory encyption object to use", &error_abort);
}
static void machine_class_base_init(ObjectClass *oc, void *data)
diff --git a/include/hw/boards.h b/include/hw/boards.h
index efb0a9edfdf1..8ce9a7a21d3d 100644
--- a/include/hw/boards.h
+++ b/include/hw/boards.h
@@ -243,6 +243,7 @@ struct MachineState {
bool suppress_vmdesc;
bool enforce_config_section;
bool enable_graphics;
+ char *memory_encryption;
ram_addr_t ram_size;
ram_addr_t maxram_size;
diff --git a/qemu-options.hx b/qemu-options.hx
index 6585058c6cde..4c280142c52c 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -43,7 +43,8 @@ DEF("machine", HAS_ARG, QEMU_OPTION_machine, \
" suppress-vmdesc=on|off disables self-describing migration (default=off)\n"
" nvdimm=on|off controls NVDIMM support (default=off)\n"
" enforce-config-section=on|off enforce configuration section migration (default=off)\n"
- " s390-squash-mcss=on|off (deprecated) controls support for squashing into default css (default=off)\n",
+ " s390-squash-mcss=on|off (deprecated) controls support for squashing into default css (default=off)\n"
+ " memory-encryption=@var{} memory encryption object to use (default=none)\n",
QEMU_ARCH_ALL)
STEXI
@item -machine [type=]@var{name}[,prop=@var{value}[,...]]
@@ -110,6 +111,8 @@ code to send configuration section even if the machine-type sets the
@option{migration.send-configuration} property to @var{off}.
NOTE: this parameter is deprecated. Please use @option{-global}
@option{migration.send-configuration}=@var{on|off} instead.
+@item memory-encryption=@var{}
+Memory encryption object to use. The default is none.
@end table
ETEXI
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [Qemu-devel] [PATCH v12 05/28] machine: add -memory-encryption property
@ 2018-03-08 12:48 ` Brijesh Singh
0 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:48 UTC (permalink / raw)
To: qemu-devel
Cc: Alistair Francis, Christian Borntraeger, Cornelia Huck,
Daniel P . Berrange, Dr. David Alan Gilbert, Michael S. Tsirkin,
Edgar E. Iglesias, Eduardo Habkost, Eric Blake, kvm,
Marcel Apfelbaum, Markus Armbruster, Paolo Bonzini,
Peter Crosthwaite, Peter Maydell, Richard Henderson,
Stefan Hajnoczi, Thomas Lendacky, Borislav Petkov,
Alexander Graf, Bruce Rogers, Brijesh Singh
When CPU supports memory encryption feature, the property can be used to
specify the encryption object to use when launching an encrypted guest.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Cc: Stefan Hajnoczi <stefanha@gmail.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
hw/core/machine.c | 22 ++++++++++++++++++++++
include/hw/boards.h | 1 +
qemu-options.hx | 5 ++++-
3 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/hw/core/machine.c b/hw/core/machine.c
index 5e2bbcdacedb..2040177664d5 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -334,6 +334,22 @@ static bool machine_get_enforce_config_section(Object *obj, Error **errp)
return ms->enforce_config_section;
}
+static char *machine_get_memory_encryption(Object *obj, Error **errp)
+{
+ MachineState *ms = MACHINE(obj);
+
+ return g_strdup(ms->memory_encryption);
+}
+
+static void machine_set_memory_encryption(Object *obj, const char *value,
+ Error **errp)
+{
+ MachineState *ms = MACHINE(obj);
+
+ g_free(ms->memory_encryption);
+ ms->memory_encryption = g_strdup(value);
+}
+
void machine_class_allow_dynamic_sysbus_dev(MachineClass *mc, const char *type)
{
strList *item = g_new0(strList, 1);
@@ -612,6 +628,12 @@ static void machine_class_init(ObjectClass *oc, void *data)
&error_abort);
object_class_property_set_description(oc, "enforce-config-section",
"Set on to enforce configuration section migration", &error_abort);
+
+ object_class_property_add_str(oc, "memory-encryption",
+ machine_get_memory_encryption, machine_set_memory_encryption,
+ &error_abort);
+ object_class_property_set_description(oc, "memory-encryption",
+ "Set memory encyption object to use", &error_abort);
}
static void machine_class_base_init(ObjectClass *oc, void *data)
diff --git a/include/hw/boards.h b/include/hw/boards.h
index efb0a9edfdf1..8ce9a7a21d3d 100644
--- a/include/hw/boards.h
+++ b/include/hw/boards.h
@@ -243,6 +243,7 @@ struct MachineState {
bool suppress_vmdesc;
bool enforce_config_section;
bool enable_graphics;
+ char *memory_encryption;
ram_addr_t ram_size;
ram_addr_t maxram_size;
diff --git a/qemu-options.hx b/qemu-options.hx
index 6585058c6cde..4c280142c52c 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -43,7 +43,8 @@ DEF("machine", HAS_ARG, QEMU_OPTION_machine, \
" suppress-vmdesc=on|off disables self-describing migration (default=off)\n"
" nvdimm=on|off controls NVDIMM support (default=off)\n"
" enforce-config-section=on|off enforce configuration section migration (default=off)\n"
- " s390-squash-mcss=on|off (deprecated) controls support for squashing into default css (default=off)\n",
+ " s390-squash-mcss=on|off (deprecated) controls support for squashing into default css (default=off)\n"
+ " memory-encryption=@var{} memory encryption object to use (default=none)\n",
QEMU_ARCH_ALL)
STEXI
@item -machine [type=]@var{name}[,prop=@var{value}[,...]]
@@ -110,6 +111,8 @@ code to send configuration section even if the machine-type sets the
@option{migration.send-configuration} property to @var{off}.
NOTE: this parameter is deprecated. Please use @option{-global}
@option{migration.send-configuration}=@var{on|off} instead.
+@item memory-encryption=@var{}
+Memory encryption object to use. The default is none.
@end table
ETEXI
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH v12 06/28] kvm: update kvm.h to include memory encryption ioctls
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
@ 2018-03-08 12:48 ` Brijesh Singh
-1 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:48 UTC (permalink / raw)
To: qemu-devel
Cc: Peter Maydell, Brijesh Singh, kvm, Michael S. Tsirkin,
Stefan Hajnoczi, Alexander Graf, Edgar E. Iglesias,
Markus Armbruster, Bruce Rogers, Christian Borntraeger,
Marcel Apfelbaum, Borislav Petkov, Thomas Lendacky,
Eduardo Habkost, Richard Henderson, Dr. David Alan Gilbert,
Alistair Francis, Cornelia Huck, Peter Crosthwaite,
Paolo Bonzini
Updates kmv.h to include memory encryption ioctls and SEV commands.
Cc: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Cornelia Huck <cornelia.huck@de.ibm.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
| 90 +++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 90 insertions(+)
--git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
index d92c9b2f0ed2..aed22309950d 100644
--- a/linux-headers/linux/kvm.h
+++ b/linux-headers/linux/kvm.h
@@ -1362,6 +1362,96 @@ struct kvm_s390_ucas_mapping {
/* Available with KVM_CAP_S390_CMMA_MIGRATION */
#define KVM_S390_GET_CMMA_BITS _IOWR(KVMIO, 0xb8, struct kvm_s390_cmma_log)
#define KVM_S390_SET_CMMA_BITS _IOW(KVMIO, 0xb9, struct kvm_s390_cmma_log)
+/* Memory Encryption Commands */
+#define KVM_MEMORY_ENCRYPT_OP _IOWR(KVMIO, 0xba, unsigned long)
+
+struct kvm_enc_region {
+ __u64 addr;
+ __u64 size;
+};
+
+#define KVM_MEMORY_ENCRYPT_REG_REGION _IOR(KVMIO, 0xbb, struct kvm_enc_region)
+#define KVM_MEMORY_ENCRYPT_UNREG_REGION _IOR(KVMIO, 0xbc, struct kvm_enc_region)
+
+/* Secure Encrypted Virtualization command */
+enum sev_cmd_id {
+ /* Guest initialization commands */
+ KVM_SEV_INIT = 0,
+ KVM_SEV_ES_INIT,
+ /* Guest launch commands */
+ KVM_SEV_LAUNCH_START,
+ KVM_SEV_LAUNCH_UPDATE_DATA,
+ KVM_SEV_LAUNCH_UPDATE_VMSA,
+ KVM_SEV_LAUNCH_SECRET,
+ KVM_SEV_LAUNCH_MEASURE,
+ KVM_SEV_LAUNCH_FINISH,
+ /* Guest migration commands (outgoing) */
+ KVM_SEV_SEND_START,
+ KVM_SEV_SEND_UPDATE_DATA,
+ KVM_SEV_SEND_UPDATE_VMSA,
+ KVM_SEV_SEND_FINISH,
+ /* Guest migration commands (incoming) */
+ KVM_SEV_RECEIVE_START,
+ KVM_SEV_RECEIVE_UPDATE_DATA,
+ KVM_SEV_RECEIVE_UPDATE_VMSA,
+ KVM_SEV_RECEIVE_FINISH,
+ /* Guest status and debug commands */
+ KVM_SEV_GUEST_STATUS,
+ KVM_SEV_DBG_DECRYPT,
+ KVM_SEV_DBG_ENCRYPT,
+ /* Guest certificates commands */
+ KVM_SEV_CERT_EXPORT,
+
+ KVM_SEV_NR_MAX,
+};
+
+struct kvm_sev_cmd {
+ __u32 id;
+ __u64 data;
+ __u32 error;
+ __u32 sev_fd;
+};
+
+struct kvm_sev_launch_start {
+ __u32 handle;
+ __u32 policy;
+ __u64 dh_uaddr;
+ __u32 dh_len;
+ __u64 session_uaddr;
+ __u32 session_len;
+};
+
+struct kvm_sev_launch_update_data {
+ __u64 uaddr;
+ __u32 len;
+};
+
+
+struct kvm_sev_launch_secret {
+ __u64 hdr_uaddr;
+ __u32 hdr_len;
+ __u64 guest_uaddr;
+ __u32 guest_len;
+ __u64 trans_uaddr;
+ __u32 trans_len;
+};
+
+struct kvm_sev_launch_measure {
+ __u64 uaddr;
+ __u32 len;
+};
+
+struct kvm_sev_guest_status {
+ __u32 handle;
+ __u32 policy;
+ __u32 state;
+};
+
+struct kvm_sev_dbg {
+ __u64 src_uaddr;
+ __u64 dst_uaddr;
+ __u32 len;
+};
#define KVM_DEV_ASSIGN_ENABLE_IOMMU (1 << 0)
#define KVM_DEV_ASSIGN_PCI_2_3 (1 << 1)
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [Qemu-devel] [PATCH v12 06/28] kvm: update kvm.h to include memory encryption ioctls
@ 2018-03-08 12:48 ` Brijesh Singh
0 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:48 UTC (permalink / raw)
To: qemu-devel
Cc: Alistair Francis, Christian Borntraeger, Cornelia Huck,
Daniel P . Berrange, Dr. David Alan Gilbert, Michael S. Tsirkin,
Edgar E. Iglesias, Eduardo Habkost, Eric Blake, kvm,
Marcel Apfelbaum, Markus Armbruster, Paolo Bonzini,
Peter Crosthwaite, Peter Maydell, Richard Henderson,
Stefan Hajnoczi, Thomas Lendacky, Borislav Petkov,
Alexander Graf, Bruce Rogers, Brijesh Singh
Updates kmv.h to include memory encryption ioctls and SEV commands.
Cc: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Cornelia Huck <cornelia.huck@de.ibm.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
| 90 +++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 90 insertions(+)
--git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
index d92c9b2f0ed2..aed22309950d 100644
--- a/linux-headers/linux/kvm.h
+++ b/linux-headers/linux/kvm.h
@@ -1362,6 +1362,96 @@ struct kvm_s390_ucas_mapping {
/* Available with KVM_CAP_S390_CMMA_MIGRATION */
#define KVM_S390_GET_CMMA_BITS _IOWR(KVMIO, 0xb8, struct kvm_s390_cmma_log)
#define KVM_S390_SET_CMMA_BITS _IOW(KVMIO, 0xb9, struct kvm_s390_cmma_log)
+/* Memory Encryption Commands */
+#define KVM_MEMORY_ENCRYPT_OP _IOWR(KVMIO, 0xba, unsigned long)
+
+struct kvm_enc_region {
+ __u64 addr;
+ __u64 size;
+};
+
+#define KVM_MEMORY_ENCRYPT_REG_REGION _IOR(KVMIO, 0xbb, struct kvm_enc_region)
+#define KVM_MEMORY_ENCRYPT_UNREG_REGION _IOR(KVMIO, 0xbc, struct kvm_enc_region)
+
+/* Secure Encrypted Virtualization command */
+enum sev_cmd_id {
+ /* Guest initialization commands */
+ KVM_SEV_INIT = 0,
+ KVM_SEV_ES_INIT,
+ /* Guest launch commands */
+ KVM_SEV_LAUNCH_START,
+ KVM_SEV_LAUNCH_UPDATE_DATA,
+ KVM_SEV_LAUNCH_UPDATE_VMSA,
+ KVM_SEV_LAUNCH_SECRET,
+ KVM_SEV_LAUNCH_MEASURE,
+ KVM_SEV_LAUNCH_FINISH,
+ /* Guest migration commands (outgoing) */
+ KVM_SEV_SEND_START,
+ KVM_SEV_SEND_UPDATE_DATA,
+ KVM_SEV_SEND_UPDATE_VMSA,
+ KVM_SEV_SEND_FINISH,
+ /* Guest migration commands (incoming) */
+ KVM_SEV_RECEIVE_START,
+ KVM_SEV_RECEIVE_UPDATE_DATA,
+ KVM_SEV_RECEIVE_UPDATE_VMSA,
+ KVM_SEV_RECEIVE_FINISH,
+ /* Guest status and debug commands */
+ KVM_SEV_GUEST_STATUS,
+ KVM_SEV_DBG_DECRYPT,
+ KVM_SEV_DBG_ENCRYPT,
+ /* Guest certificates commands */
+ KVM_SEV_CERT_EXPORT,
+
+ KVM_SEV_NR_MAX,
+};
+
+struct kvm_sev_cmd {
+ __u32 id;
+ __u64 data;
+ __u32 error;
+ __u32 sev_fd;
+};
+
+struct kvm_sev_launch_start {
+ __u32 handle;
+ __u32 policy;
+ __u64 dh_uaddr;
+ __u32 dh_len;
+ __u64 session_uaddr;
+ __u32 session_len;
+};
+
+struct kvm_sev_launch_update_data {
+ __u64 uaddr;
+ __u32 len;
+};
+
+
+struct kvm_sev_launch_secret {
+ __u64 hdr_uaddr;
+ __u32 hdr_len;
+ __u64 guest_uaddr;
+ __u32 guest_len;
+ __u64 trans_uaddr;
+ __u32 trans_len;
+};
+
+struct kvm_sev_launch_measure {
+ __u64 uaddr;
+ __u32 len;
+};
+
+struct kvm_sev_guest_status {
+ __u32 handle;
+ __u32 policy;
+ __u32 state;
+};
+
+struct kvm_sev_dbg {
+ __u64 src_uaddr;
+ __u64 dst_uaddr;
+ __u32 len;
+};
#define KVM_DEV_ASSIGN_ENABLE_IOMMU (1 << 0)
#define KVM_DEV_ASSIGN_PCI_2_3 (1 << 1)
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH v12 07/28] docs: add AMD Secure Encrypted Virtualization (SEV)
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
@ 2018-03-08 12:48 ` Brijesh Singh
-1 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:48 UTC (permalink / raw)
To: qemu-devel
Cc: Peter Maydell, Brijesh Singh, kvm, Michael S. Tsirkin,
Stefan Hajnoczi, Alexander Graf, Edgar E. Iglesias,
Markus Armbruster, Bruce Rogers, Christian Borntraeger,
Marcel Apfelbaum, Borislav Petkov, Thomas Lendacky,
Eduardo Habkost, Richard Henderson, Dr. David Alan Gilbert,
Alistair Francis, Cornelia Huck, Peter Crosthwaite,
Paolo Bonzini
Create a documentation entry to describe the AMD Secure Encrypted
Virtualization (SEV) feature.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
docs/amd-memory-encryption.txt | 92 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 92 insertions(+)
create mode 100644 docs/amd-memory-encryption.txt
diff --git a/docs/amd-memory-encryption.txt b/docs/amd-memory-encryption.txt
new file mode 100644
index 000000000000..72a92b6c6353
--- /dev/null
+++ b/docs/amd-memory-encryption.txt
@@ -0,0 +1,92 @@
+Secure Encrypted Virtualization (SEV) is a feature found on AMD processors.
+
+SEV is an extension to the AMD-V architecture which supports running encrypted
+virtual machine (VMs) under the control of KVM. Encrypted VMs have their pages
+(code and data) secured such that only the guest itself has access to the
+unencrypted version. Each encrypted VM is associated with a unique encryption
+key; if its data is accessed to a different entity using a different key the
+encrypted guests data will be incorrectly decrypted, leading to unintelligible
+data.
+
+The key management of this feature is handled by separate processor known as
+AMD secure processor (AMD-SP) which is present in AMD SOCs. Firmware running
+inside the AMD-SP provide commands to support common VM lifecycle. This
+includes commands for launching, snapshotting, migrating and debugging the
+encrypted guest. Those SEV command can be issued via KVM_MEMORY_ENCRYPT_OP
+ioctls.
+
+Launching
+---------
+Boot images (such as bios) must be encrypted before guest can be booted.
+MEMORY_ENCRYPT_OP ioctl provides commands to encrypt the images :LAUNCH_START,
+LAUNCH_UPDATE_DATA, LAUNCH_MEASURE and LAUNCH_FINISH. These four commands
+together generate a fresh memory encryption key for the VM, encrypt the boot
+images and provide a measurement than can be used as an attestation of the
+successful launch.
+
+LAUNCH_START is called first to create a cryptographic launch context within
+the firmware. To create this context, guest owner must provides guest policy,
+its public Diffie-Hellman key (PDH) and session parameters. These inputs
+should be treated as binary blob and must be passed as-is to the SEV firmware.
+
+The guest policy is passed as plaintext and hypervisor may able to read it
+but should not modify it (any modification of the policy bits will result
+in bad measurement). The guest policy is a 4-byte data structure containing
+several flags that restricts what can be done on running SEV guest.
+See KM Spec section 3 and 6.2 for more details.
+
+Guest owners provided DH certificate and session parameters will be used to
+establish a cryptographic session with the guest owner to negotiate keys used
+for the attestation.
+
+LAUNCH_UPDATE_DATA encrypts the memory region using the cryptographic context
+created via LAUNCH_START command. If required, this command can be called
+multiple times to encrypt different memory regions. The command also calculates
+the measurement of the memory contents as it encrypts.
+
+LAUNCH_MEASURE command can be used to retrieve the measurement of encrypted
+memory. This measurement is a signature of the memory contents that can be
+sent to the guest owner as an attestation that the memory was encrypted
+correctly by the firmware. The guest owner may wait to provide the guest
+confidential information until it can verify the attestation measurement.
+Since the guest owner knows the initial contents of the guest at boot, the
+attestation measurement can be verified by comparing it to what the guest owner
+expects.
+
+LAUNCH_FINISH command finalizes the guest launch and destroy's the cryptographic
+context.
+
+See SEV KM API Spec [1] 'Launching a guest' usage flow (Appendix A) for the
+complete flow chart.
+
+Debugging
+-----------
+Since memory contents of SEV guest is encrypted hence hypervisor access to the
+guest memory will get a cipher text. If guest policy allows debugging, then
+hypervisor can use DEBUG_DECRYPT and DEBUG_ENCRYPT commands access the guest
+memory region for debug purposes.
+
+Snapshot/Restore
+-----------------
+TODO
+
+Live Migration
+----------------
+TODO
+
+References
+-----------------
+
+AMD Memory Encryption whitepaper:
+http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf
+
+Secure Encrypted Virutualization Key Management:
+[1] http://support.amd.com/TechDocs/55766_SEV-KM API_Specification.pdf
+
+KVM Forum slides:
+http://www.linux-kvm.org/images/7/74/02x08A-Thomas_Lendacky-AMDs_Virtualizatoin_Memory_Encryption_Technology.pdf
+
+AMD64 Architecture Programmer's Manual:
+ http://support.amd.com/TechDocs/24593.pdf
+ SME is section 7.10
+ SEV is section 15.34
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [Qemu-devel] [PATCH v12 07/28] docs: add AMD Secure Encrypted Virtualization (SEV)
@ 2018-03-08 12:48 ` Brijesh Singh
0 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:48 UTC (permalink / raw)
To: qemu-devel
Cc: Alistair Francis, Christian Borntraeger, Cornelia Huck,
Daniel P . Berrange, Dr. David Alan Gilbert, Michael S. Tsirkin,
Edgar E. Iglesias, Eduardo Habkost, Eric Blake, kvm,
Marcel Apfelbaum, Markus Armbruster, Paolo Bonzini,
Peter Crosthwaite, Peter Maydell, Richard Henderson,
Stefan Hajnoczi, Thomas Lendacky, Borislav Petkov,
Alexander Graf, Bruce Rogers, Brijesh Singh
Create a documentation entry to describe the AMD Secure Encrypted
Virtualization (SEV) feature.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
docs/amd-memory-encryption.txt | 92 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 92 insertions(+)
create mode 100644 docs/amd-memory-encryption.txt
diff --git a/docs/amd-memory-encryption.txt b/docs/amd-memory-encryption.txt
new file mode 100644
index 000000000000..72a92b6c6353
--- /dev/null
+++ b/docs/amd-memory-encryption.txt
@@ -0,0 +1,92 @@
+Secure Encrypted Virtualization (SEV) is a feature found on AMD processors.
+
+SEV is an extension to the AMD-V architecture which supports running encrypted
+virtual machine (VMs) under the control of KVM. Encrypted VMs have their pages
+(code and data) secured such that only the guest itself has access to the
+unencrypted version. Each encrypted VM is associated with a unique encryption
+key; if its data is accessed to a different entity using a different key the
+encrypted guests data will be incorrectly decrypted, leading to unintelligible
+data.
+
+The key management of this feature is handled by separate processor known as
+AMD secure processor (AMD-SP) which is present in AMD SOCs. Firmware running
+inside the AMD-SP provide commands to support common VM lifecycle. This
+includes commands for launching, snapshotting, migrating and debugging the
+encrypted guest. Those SEV command can be issued via KVM_MEMORY_ENCRYPT_OP
+ioctls.
+
+Launching
+---------
+Boot images (such as bios) must be encrypted before guest can be booted.
+MEMORY_ENCRYPT_OP ioctl provides commands to encrypt the images :LAUNCH_START,
+LAUNCH_UPDATE_DATA, LAUNCH_MEASURE and LAUNCH_FINISH. These four commands
+together generate a fresh memory encryption key for the VM, encrypt the boot
+images and provide a measurement than can be used as an attestation of the
+successful launch.
+
+LAUNCH_START is called first to create a cryptographic launch context within
+the firmware. To create this context, guest owner must provides guest policy,
+its public Diffie-Hellman key (PDH) and session parameters. These inputs
+should be treated as binary blob and must be passed as-is to the SEV firmware.
+
+The guest policy is passed as plaintext and hypervisor may able to read it
+but should not modify it (any modification of the policy bits will result
+in bad measurement). The guest policy is a 4-byte data structure containing
+several flags that restricts what can be done on running SEV guest.
+See KM Spec section 3 and 6.2 for more details.
+
+Guest owners provided DH certificate and session parameters will be used to
+establish a cryptographic session with the guest owner to negotiate keys used
+for the attestation.
+
+LAUNCH_UPDATE_DATA encrypts the memory region using the cryptographic context
+created via LAUNCH_START command. If required, this command can be called
+multiple times to encrypt different memory regions. The command also calculates
+the measurement of the memory contents as it encrypts.
+
+LAUNCH_MEASURE command can be used to retrieve the measurement of encrypted
+memory. This measurement is a signature of the memory contents that can be
+sent to the guest owner as an attestation that the memory was encrypted
+correctly by the firmware. The guest owner may wait to provide the guest
+confidential information until it can verify the attestation measurement.
+Since the guest owner knows the initial contents of the guest at boot, the
+attestation measurement can be verified by comparing it to what the guest owner
+expects.
+
+LAUNCH_FINISH command finalizes the guest launch and destroy's the cryptographic
+context.
+
+See SEV KM API Spec [1] 'Launching a guest' usage flow (Appendix A) for the
+complete flow chart.
+
+Debugging
+-----------
+Since memory contents of SEV guest is encrypted hence hypervisor access to the
+guest memory will get a cipher text. If guest policy allows debugging, then
+hypervisor can use DEBUG_DECRYPT and DEBUG_ENCRYPT commands access the guest
+memory region for debug purposes.
+
+Snapshot/Restore
+-----------------
+TODO
+
+Live Migration
+----------------
+TODO
+
+References
+-----------------
+
+AMD Memory Encryption whitepaper:
+http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf
+
+Secure Encrypted Virutualization Key Management:
+[1] http://support.amd.com/TechDocs/55766_SEV-KM API_Specification.pdf
+
+KVM Forum slides:
+http://www.linux-kvm.org/images/7/74/02x08A-Thomas_Lendacky-AMDs_Virtualizatoin_Memory_Encryption_Technology.pdf
+
+AMD64 Architecture Programmer's Manual:
+ http://support.amd.com/TechDocs/24593.pdf
+ SME is section 7.10
+ SEV is section 15.34
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH v12 08/28] target/i386: add Secure Encrypted Virtulization (SEV) object
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
@ 2018-03-08 12:48 ` Brijesh Singh
-1 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:48 UTC (permalink / raw)
To: qemu-devel
Cc: Peter Maydell, Brijesh Singh, kvm, Michael S. Tsirkin,
Stefan Hajnoczi, Alexander Graf, Edgar E. Iglesias,
Markus Armbruster, Bruce Rogers, Christian Borntraeger,
Marcel Apfelbaum, Borislav Petkov, Thomas Lendacky,
Eduardo Habkost, Richard Henderson, Dr. David Alan Gilbert,
Alistair Francis, Cornelia Huck, Richard Henderson,
Peter Crosthwaite, Paolo Bonzini
Add a new memory encryption object 'sev-guest'. The object will be used
to create enrypted VMs on AMD EPYC CPU. The object provides the properties
to pass guest owner's public Diffie-hellman key, guest policy and session
information required to create the memory encryption context within the
SEV firmware.
e.g to launch SEV guest
# $QEMU \
-object sev-guest,id=sev0 \
-machine ....,memory-encryption=sev0
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
docs/amd-memory-encryption.txt | 17 +++
qemu-options.hx | 44 ++++++++
target/i386/Makefile.objs | 2 +-
target/i386/sev.c | 228 +++++++++++++++++++++++++++++++++++++++++
target/i386/sev_i386.h | 61 +++++++++++
5 files changed, 351 insertions(+), 1 deletion(-)
create mode 100644 target/i386/sev.c
create mode 100644 target/i386/sev_i386.h
diff --git a/docs/amd-memory-encryption.txt b/docs/amd-memory-encryption.txt
index 72a92b6c6353..05266fd41b23 100644
--- a/docs/amd-memory-encryption.txt
+++ b/docs/amd-memory-encryption.txt
@@ -35,10 +35,21 @@ in bad measurement). The guest policy is a 4-byte data structure containing
several flags that restricts what can be done on running SEV guest.
See KM Spec section 3 and 6.2 for more details.
+The guest policy can be provided via the 'policy' property (see below)
+
+# ${QEMU} \
+ sev-guest,id=sev0,policy=0x1...\
+
Guest owners provided DH certificate and session parameters will be used to
establish a cryptographic session with the guest owner to negotiate keys used
for the attestation.
+The DH certificate and session blob can be provided via 'dh-cert-file' and
+'session-file' property (see below
+
+# ${QEMU} \
+ sev-guest,id=sev0,dh-cert-file=<file1>,session-file=<file2>
+
LAUNCH_UPDATE_DATA encrypts the memory region using the cryptographic context
created via LAUNCH_START command. If required, this command can be called
multiple times to encrypt different memory regions. The command also calculates
@@ -59,6 +70,12 @@ context.
See SEV KM API Spec [1] 'Launching a guest' usage flow (Appendix A) for the
complete flow chart.
+To launch a SEV guest
+
+# ${QEMU} \
+ -machine ...,memory-encryption=sev0 \
+ -object sev-guest,id=sev0,cbitpos=47,reduced-phys-bits=1
+
Debugging
-----------
Since memory contents of SEV guest is encrypted hence hypervisor access to the
diff --git a/qemu-options.hx b/qemu-options.hx
index 4c280142c52c..6113bce08a8c 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -4353,6 +4353,50 @@ contents of @code{iv.b64} to the second secret
data=$SECRET,iv=$(<iv.b64)
@end example
+@item -object sev-guest,id=@var{id},cbitpos=@var{cbitpos},reduced-phys-bits=@var{val},[sev-device=@var{string},policy=@var{policy},handle=@var{handle},dh-cert-file=@var{file},session-file=@var{file}]
+
+Create a Secure Encrypted Virtualization (SEV) guest object, which can be used
+to provide the guest memory encryption support on AMD processors.
+
+When memory encryption is enabled, one of the physical address bit (aka the
+C-bit) is utilized to mark if a memory page is protected. The @option{cbitpos}
+is used to provide the C-bit position. The C-bit position is Host family dependent
+hence user must provide this value. On EPYC, the value should be 47.
+
+When memory encryption is enabled, we loose certain bits in physical address space.
+The @option{reduced-phys-bits} is used to provide the number of bits we loose in
+physical address space. Similar to C-bit, the value is Host family dependent.
+On EPYC, the value should be 5.
+
+The @option{sev-device} provides the device file to use for communicating with
+the SEV firmware running inside AMD Secure Processor. The default device is
+'/dev/sev'. If hardware supports memory encryption then /dev/sev devices are
+created by CCP driver.
+
+The @option{policy} provides the guest policy to be enforced by the SEV firmware
+and restrict what configuration and operational commands can be performed on this
+guest by the hypervisor. The policy should be provided by the guest owner and is
+bound to the guest and cannot be changed throughout the lifetime of the guest.
+The default is 0.
+
+If guest @option{policy} allows sharing the key with another SEV guest then
+@option{handle} can be use to provide handle of the guest from which to share
+the key.
+
+The @option{dh-cert-file} and @option{session-file} provides the guest owner's
+Public Diffie-Hillman key defined in SEV spec. The PDH and session parameters
+are used for establishing a cryptographic session with the guest owner to
+negotiate keys used for attestation. The file must be encoded in base64.
+
+e.g to launch a SEV guest
+@example
+ # $QEMU \
+ ......
+ -object sev-guest,id=sev0,cbitpos=47,reduced-phys-bits=5 \
+ -machine ...,memory-encryption=sev0
+ .....
+
+@end example
@end table
ETEXI
diff --git a/target/i386/Makefile.objs b/target/i386/Makefile.objs
index f5c6ef20a7bb..76aeaeae2750 100644
--- a/target/i386/Makefile.objs
+++ b/target/i386/Makefile.objs
@@ -4,7 +4,7 @@ obj-$(CONFIG_TCG) += bpt_helper.o cc_helper.o excp_helper.o fpu_helper.o
obj-$(CONFIG_TCG) += int_helper.o mem_helper.o misc_helper.o mpx_helper.o
obj-$(CONFIG_TCG) += seg_helper.o smm_helper.o svm_helper.o
obj-$(CONFIG_SOFTMMU) += machine.o arch_memory_mapping.o arch_dump.o monitor.o
-obj-$(CONFIG_KVM) += kvm.o hyperv.o
+obj-$(CONFIG_KVM) += kvm.o hyperv.o sev.o
obj-$(call lnot,$(CONFIG_KVM)) += kvm-stub.o
# HAX support
ifdef CONFIG_WIN32
diff --git a/target/i386/sev.c b/target/i386/sev.c
new file mode 100644
index 000000000000..ab42e4a456d2
--- /dev/null
+++ b/target/i386/sev.c
@@ -0,0 +1,228 @@
+/*
+ * QEMU SEV support
+ *
+ * Copyright Advanced Micro Devices 2016-2018
+ *
+ * Author:
+ * Brijesh Singh <brijesh.singh@amd.com>
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#include "qemu/osdep.h"
+#include "qapi/error.h"
+#include "qom/object_interfaces.h"
+#include "qemu/base64.h"
+#include "sysemu/kvm.h"
+#include "sev_i386.h"
+#include "sysemu/sysemu.h"
+
+#define DEFAULT_GUEST_POLICY 0x1 /* disable debug */
+#define DEFAULT_SEV_DEVICE "/dev/sev"
+
+static void
+qsev_guest_finalize(Object *obj)
+{
+}
+
+static char *
+qsev_guest_get_session_file(Object *obj, Error **errp)
+{
+ QSevGuestInfo *s = QSEV_GUEST_INFO(obj);
+
+ return s->session_file ? g_strdup(s->session_file) : NULL;
+}
+
+static void
+qsev_guest_set_session_file(Object *obj, const char *value, Error **errp)
+{
+ QSevGuestInfo *s = QSEV_GUEST_INFO(obj);
+
+ s->session_file = g_strdup(value);
+}
+
+static char *
+qsev_guest_get_dh_cert_file(Object *obj, Error **errp)
+{
+ QSevGuestInfo *s = QSEV_GUEST_INFO(obj);
+
+ return g_strdup(s->dh_cert_file);
+}
+
+static void
+qsev_guest_set_dh_cert_file(Object *obj, const char *value, Error **errp)
+{
+ QSevGuestInfo *s = QSEV_GUEST_INFO(obj);
+
+ s->dh_cert_file = g_strdup(value);
+}
+
+static char *
+qsev_guest_get_sev_device(Object *obj, Error **errp)
+{
+ QSevGuestInfo *sev = QSEV_GUEST_INFO(obj);
+
+ return g_strdup(sev->sev_device);
+}
+
+static void
+qsev_guest_set_sev_device(Object *obj, const char *value, Error **errp)
+{
+ QSevGuestInfo *sev = QSEV_GUEST_INFO(obj);
+
+ sev->sev_device = g_strdup(value);
+}
+
+static void
+qsev_guest_class_init(ObjectClass *oc, void *data)
+{
+ object_class_property_add_str(oc, "sev-device",
+ qsev_guest_get_sev_device,
+ qsev_guest_set_sev_device,
+ NULL);
+ object_class_property_set_description(oc, "sev-device",
+ "SEV device to use", NULL);
+ object_class_property_add_str(oc, "dh-cert-file",
+ qsev_guest_get_dh_cert_file,
+ qsev_guest_set_dh_cert_file,
+ NULL);
+ object_class_property_set_description(oc, "dh-cert-file",
+ "guest owners DH certificate (encoded with base64)", NULL);
+ object_class_property_add_str(oc, "session-file",
+ qsev_guest_get_session_file,
+ qsev_guest_set_session_file,
+ NULL);
+ object_class_property_set_description(oc, "session-file",
+ "guest owners session parameters (encoded with base64)", NULL);
+}
+
+static void
+qsev_guest_set_handle(Object *obj, Visitor *v, const char *name,
+ void *opaque, Error **errp)
+{
+ QSevGuestInfo *sev = QSEV_GUEST_INFO(obj);
+ uint32_t value;
+
+ visit_type_uint32(v, name, &value, errp);
+ sev->handle = value;
+}
+
+static void
+qsev_guest_set_policy(Object *obj, Visitor *v, const char *name,
+ void *opaque, Error **errp)
+{
+ QSevGuestInfo *sev = QSEV_GUEST_INFO(obj);
+ uint32_t value;
+
+ visit_type_uint32(v, name, &value, errp);
+ sev->policy = value;
+}
+
+static void
+qsev_guest_set_cbitpos(Object *obj, Visitor *v, const char *name,
+ void *opaque, Error **errp)
+{
+ QSevGuestInfo *sev = QSEV_GUEST_INFO(obj);
+ uint32_t value;
+
+ visit_type_uint32(v, name, &value, errp);
+ sev->cbitpos = value;
+}
+
+static void
+qsev_guest_set_reduced_phys_bits(Object *obj, Visitor *v, const char *name,
+ void *opaque, Error **errp)
+{
+ QSevGuestInfo *sev = QSEV_GUEST_INFO(obj);
+ uint32_t value;
+
+ visit_type_uint32(v, name, &value, errp);
+ sev->reduced_phys_bits = value;
+}
+
+static void
+qsev_guest_get_policy(Object *obj, Visitor *v, const char *name,
+ void *opaque, Error **errp)
+{
+ uint32_t value;
+ QSevGuestInfo *sev = QSEV_GUEST_INFO(obj);
+
+ value = sev->policy;
+ visit_type_uint32(v, name, &value, errp);
+}
+
+static void
+qsev_guest_get_handle(Object *obj, Visitor *v, const char *name,
+ void *opaque, Error **errp)
+{
+ uint32_t value;
+ QSevGuestInfo *sev = QSEV_GUEST_INFO(obj);
+
+ value = sev->handle;
+ visit_type_uint32(v, name, &value, errp);
+}
+
+static void
+qsev_guest_get_cbitpos(Object *obj, Visitor *v, const char *name,
+ void *opaque, Error **errp)
+{
+ uint32_t value;
+ QSevGuestInfo *sev = QSEV_GUEST_INFO(obj);
+
+ value = sev->cbitpos;
+ visit_type_uint32(v, name, &value, errp);
+}
+
+static void
+qsev_guest_get_reduced_phys_bits(Object *obj, Visitor *v, const char *name,
+ void *opaque, Error **errp)
+{
+ uint32_t value;
+ QSevGuestInfo *sev = QSEV_GUEST_INFO(obj);
+
+ value = sev->reduced_phys_bits;
+ visit_type_uint32(v, name, &value, errp);
+}
+
+static void
+qsev_guest_init(Object *obj)
+{
+ QSevGuestInfo *sev = QSEV_GUEST_INFO(obj);
+
+ sev->sev_device = g_strdup(DEFAULT_SEV_DEVICE);
+ sev->policy = DEFAULT_GUEST_POLICY;
+ object_property_add(obj, "policy", "uint32", qsev_guest_get_policy,
+ qsev_guest_set_policy, NULL, NULL, NULL);
+ object_property_add(obj, "handle", "uint32", qsev_guest_get_handle,
+ qsev_guest_set_handle, NULL, NULL, NULL);
+ object_property_add(obj, "cbitpos", "uint32", qsev_guest_get_cbitpos,
+ qsev_guest_set_cbitpos, NULL, NULL, NULL);
+ object_property_add(obj, "reduced-phys-bits", "uint32",
+ qsev_guest_get_reduced_phys_bits,
+ qsev_guest_set_reduced_phys_bits, NULL, NULL, NULL);
+}
+
+/* sev guest info */
+static const TypeInfo qsev_guest_info = {
+ .parent = TYPE_OBJECT,
+ .name = TYPE_QSEV_GUEST_INFO,
+ .instance_size = sizeof(QSevGuestInfo),
+ .instance_finalize = qsev_guest_finalize,
+ .class_size = sizeof(QSevGuestInfoClass),
+ .class_init = qsev_guest_class_init,
+ .instance_init = qsev_guest_init,
+ .interfaces = (InterfaceInfo[]) {
+ { TYPE_USER_CREATABLE },
+ { }
+ }
+};
+
+static void
+sev_register_types(void)
+{
+ type_register_static(&qsev_guest_info);
+}
+
+type_init(sev_register_types);
diff --git a/target/i386/sev_i386.h b/target/i386/sev_i386.h
new file mode 100644
index 000000000000..caf879c3b874
--- /dev/null
+++ b/target/i386/sev_i386.h
@@ -0,0 +1,61 @@
+/*
+ * QEMU Secure Encrypted Virutualization (SEV) support
+ *
+ * Copyright: Advanced Micro Devices, 2016-2018
+ *
+ * Authors:
+ * Brijesh Singh <brijesh.singh@amd.com>
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#ifndef QEMU_SEV_I386_H
+#define QEMU_SEV_I386_H
+
+#include "qom/object.h"
+#include "qapi/error.h"
+#include "sysemu/kvm.h"
+#include "qemu/error-report.h"
+
+#define SEV_POLICY_NODBG 0x1
+#define SEV_POLICY_NOKS 0x2
+#define SEV_POLICY_ES 0x4
+#define SEV_POLICY_NOSEND 0x8
+#define SEV_POLICY_DOMAIN 0x10
+#define SEV_POLICY_SEV 0x20
+
+#define TYPE_QSEV_GUEST_INFO "sev-guest"
+#define QSEV_GUEST_INFO(obj) \
+ OBJECT_CHECK(QSevGuestInfo, (obj), TYPE_QSEV_GUEST_INFO)
+
+typedef struct QSevGuestInfo QSevGuestInfo;
+typedef struct QSevGuestInfoClass QSevGuestInfoClass;
+
+/**
+ * QSevGuestInfo:
+ *
+ * The QSevGuestInfo object is used for creating a SEV guest.
+ *
+ * # $QEMU \
+ * -object sev-guest,id=sev0 \
+ * -machine ...,memory-encryption=sev0
+ */
+struct QSevGuestInfo {
+ Object parent_obj;
+
+ char *sev_device;
+ uint32_t policy;
+ uint32_t handle;
+ char *dh_cert_file;
+ char *session_file;
+ uint32_t cbitpos;
+ uint32_t reduced_phys_bits;
+};
+
+struct QSevGuestInfoClass {
+ ObjectClass parent_class;
+};
+
+#endif
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [Qemu-devel] [PATCH v12 08/28] target/i386: add Secure Encrypted Virtulization (SEV) object
@ 2018-03-08 12:48 ` Brijesh Singh
0 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:48 UTC (permalink / raw)
To: qemu-devel
Cc: Alistair Francis, Christian Borntraeger, Cornelia Huck,
Daniel P . Berrange, Dr. David Alan Gilbert, Michael S. Tsirkin,
Edgar E. Iglesias, Eduardo Habkost, Eric Blake, kvm,
Marcel Apfelbaum, Markus Armbruster, Paolo Bonzini,
Peter Crosthwaite, Peter Maydell, Richard Henderson,
Stefan Hajnoczi, Thomas Lendacky, Borislav Petkov,
Alexander Graf, Bruce Rogers, Brijesh Singh, Richard Henderson
Add a new memory encryption object 'sev-guest'. The object will be used
to create enrypted VMs on AMD EPYC CPU. The object provides the properties
to pass guest owner's public Diffie-hellman key, guest policy and session
information required to create the memory encryption context within the
SEV firmware.
e.g to launch SEV guest
# $QEMU \
-object sev-guest,id=sev0 \
-machine ....,memory-encryption=sev0
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
docs/amd-memory-encryption.txt | 17 +++
qemu-options.hx | 44 ++++++++
target/i386/Makefile.objs | 2 +-
target/i386/sev.c | 228 +++++++++++++++++++++++++++++++++++++++++
target/i386/sev_i386.h | 61 +++++++++++
5 files changed, 351 insertions(+), 1 deletion(-)
create mode 100644 target/i386/sev.c
create mode 100644 target/i386/sev_i386.h
diff --git a/docs/amd-memory-encryption.txt b/docs/amd-memory-encryption.txt
index 72a92b6c6353..05266fd41b23 100644
--- a/docs/amd-memory-encryption.txt
+++ b/docs/amd-memory-encryption.txt
@@ -35,10 +35,21 @@ in bad measurement). The guest policy is a 4-byte data structure containing
several flags that restricts what can be done on running SEV guest.
See KM Spec section 3 and 6.2 for more details.
+The guest policy can be provided via the 'policy' property (see below)
+
+# ${QEMU} \
+ sev-guest,id=sev0,policy=0x1...\
+
Guest owners provided DH certificate and session parameters will be used to
establish a cryptographic session with the guest owner to negotiate keys used
for the attestation.
+The DH certificate and session blob can be provided via 'dh-cert-file' and
+'session-file' property (see below
+
+# ${QEMU} \
+ sev-guest,id=sev0,dh-cert-file=<file1>,session-file=<file2>
+
LAUNCH_UPDATE_DATA encrypts the memory region using the cryptographic context
created via LAUNCH_START command. If required, this command can be called
multiple times to encrypt different memory regions. The command also calculates
@@ -59,6 +70,12 @@ context.
See SEV KM API Spec [1] 'Launching a guest' usage flow (Appendix A) for the
complete flow chart.
+To launch a SEV guest
+
+# ${QEMU} \
+ -machine ...,memory-encryption=sev0 \
+ -object sev-guest,id=sev0,cbitpos=47,reduced-phys-bits=1
+
Debugging
-----------
Since memory contents of SEV guest is encrypted hence hypervisor access to the
diff --git a/qemu-options.hx b/qemu-options.hx
index 4c280142c52c..6113bce08a8c 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -4353,6 +4353,50 @@ contents of @code{iv.b64} to the second secret
data=$SECRET,iv=$(<iv.b64)
@end example
+@item -object sev-guest,id=@var{id},cbitpos=@var{cbitpos},reduced-phys-bits=@var{val},[sev-device=@var{string},policy=@var{policy},handle=@var{handle},dh-cert-file=@var{file},session-file=@var{file}]
+
+Create a Secure Encrypted Virtualization (SEV) guest object, which can be used
+to provide the guest memory encryption support on AMD processors.
+
+When memory encryption is enabled, one of the physical address bit (aka the
+C-bit) is utilized to mark if a memory page is protected. The @option{cbitpos}
+is used to provide the C-bit position. The C-bit position is Host family dependent
+hence user must provide this value. On EPYC, the value should be 47.
+
+When memory encryption is enabled, we loose certain bits in physical address space.
+The @option{reduced-phys-bits} is used to provide the number of bits we loose in
+physical address space. Similar to C-bit, the value is Host family dependent.
+On EPYC, the value should be 5.
+
+The @option{sev-device} provides the device file to use for communicating with
+the SEV firmware running inside AMD Secure Processor. The default device is
+'/dev/sev'. If hardware supports memory encryption then /dev/sev devices are
+created by CCP driver.
+
+The @option{policy} provides the guest policy to be enforced by the SEV firmware
+and restrict what configuration and operational commands can be performed on this
+guest by the hypervisor. The policy should be provided by the guest owner and is
+bound to the guest and cannot be changed throughout the lifetime of the guest.
+The default is 0.
+
+If guest @option{policy} allows sharing the key with another SEV guest then
+@option{handle} can be use to provide handle of the guest from which to share
+the key.
+
+The @option{dh-cert-file} and @option{session-file} provides the guest owner's
+Public Diffie-Hillman key defined in SEV spec. The PDH and session parameters
+are used for establishing a cryptographic session with the guest owner to
+negotiate keys used for attestation. The file must be encoded in base64.
+
+e.g to launch a SEV guest
+@example
+ # $QEMU \
+ ......
+ -object sev-guest,id=sev0,cbitpos=47,reduced-phys-bits=5 \
+ -machine ...,memory-encryption=sev0
+ .....
+
+@end example
@end table
ETEXI
diff --git a/target/i386/Makefile.objs b/target/i386/Makefile.objs
index f5c6ef20a7bb..76aeaeae2750 100644
--- a/target/i386/Makefile.objs
+++ b/target/i386/Makefile.objs
@@ -4,7 +4,7 @@ obj-$(CONFIG_TCG) += bpt_helper.o cc_helper.o excp_helper.o fpu_helper.o
obj-$(CONFIG_TCG) += int_helper.o mem_helper.o misc_helper.o mpx_helper.o
obj-$(CONFIG_TCG) += seg_helper.o smm_helper.o svm_helper.o
obj-$(CONFIG_SOFTMMU) += machine.o arch_memory_mapping.o arch_dump.o monitor.o
-obj-$(CONFIG_KVM) += kvm.o hyperv.o
+obj-$(CONFIG_KVM) += kvm.o hyperv.o sev.o
obj-$(call lnot,$(CONFIG_KVM)) += kvm-stub.o
# HAX support
ifdef CONFIG_WIN32
diff --git a/target/i386/sev.c b/target/i386/sev.c
new file mode 100644
index 000000000000..ab42e4a456d2
--- /dev/null
+++ b/target/i386/sev.c
@@ -0,0 +1,228 @@
+/*
+ * QEMU SEV support
+ *
+ * Copyright Advanced Micro Devices 2016-2018
+ *
+ * Author:
+ * Brijesh Singh <brijesh.singh@amd.com>
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#include "qemu/osdep.h"
+#include "qapi/error.h"
+#include "qom/object_interfaces.h"
+#include "qemu/base64.h"
+#include "sysemu/kvm.h"
+#include "sev_i386.h"
+#include "sysemu/sysemu.h"
+
+#define DEFAULT_GUEST_POLICY 0x1 /* disable debug */
+#define DEFAULT_SEV_DEVICE "/dev/sev"
+
+static void
+qsev_guest_finalize(Object *obj)
+{
+}
+
+static char *
+qsev_guest_get_session_file(Object *obj, Error **errp)
+{
+ QSevGuestInfo *s = QSEV_GUEST_INFO(obj);
+
+ return s->session_file ? g_strdup(s->session_file) : NULL;
+}
+
+static void
+qsev_guest_set_session_file(Object *obj, const char *value, Error **errp)
+{
+ QSevGuestInfo *s = QSEV_GUEST_INFO(obj);
+
+ s->session_file = g_strdup(value);
+}
+
+static char *
+qsev_guest_get_dh_cert_file(Object *obj, Error **errp)
+{
+ QSevGuestInfo *s = QSEV_GUEST_INFO(obj);
+
+ return g_strdup(s->dh_cert_file);
+}
+
+static void
+qsev_guest_set_dh_cert_file(Object *obj, const char *value, Error **errp)
+{
+ QSevGuestInfo *s = QSEV_GUEST_INFO(obj);
+
+ s->dh_cert_file = g_strdup(value);
+}
+
+static char *
+qsev_guest_get_sev_device(Object *obj, Error **errp)
+{
+ QSevGuestInfo *sev = QSEV_GUEST_INFO(obj);
+
+ return g_strdup(sev->sev_device);
+}
+
+static void
+qsev_guest_set_sev_device(Object *obj, const char *value, Error **errp)
+{
+ QSevGuestInfo *sev = QSEV_GUEST_INFO(obj);
+
+ sev->sev_device = g_strdup(value);
+}
+
+static void
+qsev_guest_class_init(ObjectClass *oc, void *data)
+{
+ object_class_property_add_str(oc, "sev-device",
+ qsev_guest_get_sev_device,
+ qsev_guest_set_sev_device,
+ NULL);
+ object_class_property_set_description(oc, "sev-device",
+ "SEV device to use", NULL);
+ object_class_property_add_str(oc, "dh-cert-file",
+ qsev_guest_get_dh_cert_file,
+ qsev_guest_set_dh_cert_file,
+ NULL);
+ object_class_property_set_description(oc, "dh-cert-file",
+ "guest owners DH certificate (encoded with base64)", NULL);
+ object_class_property_add_str(oc, "session-file",
+ qsev_guest_get_session_file,
+ qsev_guest_set_session_file,
+ NULL);
+ object_class_property_set_description(oc, "session-file",
+ "guest owners session parameters (encoded with base64)", NULL);
+}
+
+static void
+qsev_guest_set_handle(Object *obj, Visitor *v, const char *name,
+ void *opaque, Error **errp)
+{
+ QSevGuestInfo *sev = QSEV_GUEST_INFO(obj);
+ uint32_t value;
+
+ visit_type_uint32(v, name, &value, errp);
+ sev->handle = value;
+}
+
+static void
+qsev_guest_set_policy(Object *obj, Visitor *v, const char *name,
+ void *opaque, Error **errp)
+{
+ QSevGuestInfo *sev = QSEV_GUEST_INFO(obj);
+ uint32_t value;
+
+ visit_type_uint32(v, name, &value, errp);
+ sev->policy = value;
+}
+
+static void
+qsev_guest_set_cbitpos(Object *obj, Visitor *v, const char *name,
+ void *opaque, Error **errp)
+{
+ QSevGuestInfo *sev = QSEV_GUEST_INFO(obj);
+ uint32_t value;
+
+ visit_type_uint32(v, name, &value, errp);
+ sev->cbitpos = value;
+}
+
+static void
+qsev_guest_set_reduced_phys_bits(Object *obj, Visitor *v, const char *name,
+ void *opaque, Error **errp)
+{
+ QSevGuestInfo *sev = QSEV_GUEST_INFO(obj);
+ uint32_t value;
+
+ visit_type_uint32(v, name, &value, errp);
+ sev->reduced_phys_bits = value;
+}
+
+static void
+qsev_guest_get_policy(Object *obj, Visitor *v, const char *name,
+ void *opaque, Error **errp)
+{
+ uint32_t value;
+ QSevGuestInfo *sev = QSEV_GUEST_INFO(obj);
+
+ value = sev->policy;
+ visit_type_uint32(v, name, &value, errp);
+}
+
+static void
+qsev_guest_get_handle(Object *obj, Visitor *v, const char *name,
+ void *opaque, Error **errp)
+{
+ uint32_t value;
+ QSevGuestInfo *sev = QSEV_GUEST_INFO(obj);
+
+ value = sev->handle;
+ visit_type_uint32(v, name, &value, errp);
+}
+
+static void
+qsev_guest_get_cbitpos(Object *obj, Visitor *v, const char *name,
+ void *opaque, Error **errp)
+{
+ uint32_t value;
+ QSevGuestInfo *sev = QSEV_GUEST_INFO(obj);
+
+ value = sev->cbitpos;
+ visit_type_uint32(v, name, &value, errp);
+}
+
+static void
+qsev_guest_get_reduced_phys_bits(Object *obj, Visitor *v, const char *name,
+ void *opaque, Error **errp)
+{
+ uint32_t value;
+ QSevGuestInfo *sev = QSEV_GUEST_INFO(obj);
+
+ value = sev->reduced_phys_bits;
+ visit_type_uint32(v, name, &value, errp);
+}
+
+static void
+qsev_guest_init(Object *obj)
+{
+ QSevGuestInfo *sev = QSEV_GUEST_INFO(obj);
+
+ sev->sev_device = g_strdup(DEFAULT_SEV_DEVICE);
+ sev->policy = DEFAULT_GUEST_POLICY;
+ object_property_add(obj, "policy", "uint32", qsev_guest_get_policy,
+ qsev_guest_set_policy, NULL, NULL, NULL);
+ object_property_add(obj, "handle", "uint32", qsev_guest_get_handle,
+ qsev_guest_set_handle, NULL, NULL, NULL);
+ object_property_add(obj, "cbitpos", "uint32", qsev_guest_get_cbitpos,
+ qsev_guest_set_cbitpos, NULL, NULL, NULL);
+ object_property_add(obj, "reduced-phys-bits", "uint32",
+ qsev_guest_get_reduced_phys_bits,
+ qsev_guest_set_reduced_phys_bits, NULL, NULL, NULL);
+}
+
+/* sev guest info */
+static const TypeInfo qsev_guest_info = {
+ .parent = TYPE_OBJECT,
+ .name = TYPE_QSEV_GUEST_INFO,
+ .instance_size = sizeof(QSevGuestInfo),
+ .instance_finalize = qsev_guest_finalize,
+ .class_size = sizeof(QSevGuestInfoClass),
+ .class_init = qsev_guest_class_init,
+ .instance_init = qsev_guest_init,
+ .interfaces = (InterfaceInfo[]) {
+ { TYPE_USER_CREATABLE },
+ { }
+ }
+};
+
+static void
+sev_register_types(void)
+{
+ type_register_static(&qsev_guest_info);
+}
+
+type_init(sev_register_types);
diff --git a/target/i386/sev_i386.h b/target/i386/sev_i386.h
new file mode 100644
index 000000000000..caf879c3b874
--- /dev/null
+++ b/target/i386/sev_i386.h
@@ -0,0 +1,61 @@
+/*
+ * QEMU Secure Encrypted Virutualization (SEV) support
+ *
+ * Copyright: Advanced Micro Devices, 2016-2018
+ *
+ * Authors:
+ * Brijesh Singh <brijesh.singh@amd.com>
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#ifndef QEMU_SEV_I386_H
+#define QEMU_SEV_I386_H
+
+#include "qom/object.h"
+#include "qapi/error.h"
+#include "sysemu/kvm.h"
+#include "qemu/error-report.h"
+
+#define SEV_POLICY_NODBG 0x1
+#define SEV_POLICY_NOKS 0x2
+#define SEV_POLICY_ES 0x4
+#define SEV_POLICY_NOSEND 0x8
+#define SEV_POLICY_DOMAIN 0x10
+#define SEV_POLICY_SEV 0x20
+
+#define TYPE_QSEV_GUEST_INFO "sev-guest"
+#define QSEV_GUEST_INFO(obj) \
+ OBJECT_CHECK(QSevGuestInfo, (obj), TYPE_QSEV_GUEST_INFO)
+
+typedef struct QSevGuestInfo QSevGuestInfo;
+typedef struct QSevGuestInfoClass QSevGuestInfoClass;
+
+/**
+ * QSevGuestInfo:
+ *
+ * The QSevGuestInfo object is used for creating a SEV guest.
+ *
+ * # $QEMU \
+ * -object sev-guest,id=sev0 \
+ * -machine ...,memory-encryption=sev0
+ */
+struct QSevGuestInfo {
+ Object parent_obj;
+
+ char *sev_device;
+ uint32_t policy;
+ uint32_t handle;
+ char *dh_cert_file;
+ char *session_file;
+ uint32_t cbitpos;
+ uint32_t reduced_phys_bits;
+};
+
+struct QSevGuestInfoClass {
+ ObjectClass parent_class;
+};
+
+#endif
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH v12 09/28] qmp: add query-sev command
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
@ 2018-03-08 12:48 ` Brijesh Singh
-1 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:48 UTC (permalink / raw)
To: qemu-devel
Cc: Peter Maydell, Brijesh Singh, kvm, Michael S. Tsirkin,
Stefan Hajnoczi, Alexander Graf, Edgar E. Iglesias,
Markus Armbruster, Bruce Rogers, Christian Borntraeger,
Marcel Apfelbaum, Borislav Petkov, Thomas Lendacky,
Eduardo Habkost, Richard Henderson, Dr. David Alan Gilbert,
Alistair Francis, Cornelia Huck, Peter Crosthwaite,
Paolo Bonzini
The QMP query command can used to retrieve the SEV information when
memory encryption is enabled on AMD platform.
Cc: Eric Blake <eblake@redhat.com>
Cc: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
monitor.c | 7 +++++
qapi/misc.json | 76 +++++++++++++++++++++++++++++++++++++++++++++++++++
target/i386/monitor.c | 8 ++++++
3 files changed, 91 insertions(+)
diff --git a/monitor.c b/monitor.c
index 3f4ba902266b..2225cf5030dc 100644
--- a/monitor.c
+++ b/monitor.c
@@ -983,6 +983,7 @@ static void qmp_unregister_commands_hack(void)
#endif
#ifndef TARGET_I386
qmp_unregister_command(&qmp_commands, "rtc-reset-reinjection");
+ qmp_unregister_command(&qmp_commands, "query-sev");
#endif
#ifndef TARGET_S390X
qmp_unregister_command(&qmp_commands, "dump-skeys");
@@ -4103,6 +4104,12 @@ void qmp_rtc_reset_reinjection(Error **errp)
{
error_setg(errp, QERR_FEATURE_DISABLED, "rtc-reset-reinjection");
}
+
+SevInfo *qmp_query_sev(Error **errp)
+{
+ error_setg(errp, QERR_FEATURE_DISABLED, "query-sev");
+ return NULL;
+}
#endif
#ifndef TARGET_S390X
diff --git a/qapi/misc.json b/qapi/misc.json
index bd04469a4ba2..14681729f8fc 100644
--- a/qapi/misc.json
+++ b/qapi/misc.json
@@ -3201,3 +3201,79 @@
# Since: 2.9
##
{ 'command': 'query-vm-generation-id', 'returns': 'GuidInfo' }
+
+
+##
+# @SevState:
+#
+# An enumeration of SEV state information used during @query-sev.
+#
+# @uninit: The guest is uninitialized.
+#
+# @lupdate: The guest is currently being launched and plaintext and
+# reigster state is being imported.
+#
+# @lsecret: The guest is currently being launched and ciphertext data
+# are being imported.
+#
+# @running: The guest is fully launched or migrated in.
+#
+# @supdate: The guest is currently being migrated out to another machine.
+#
+# @rupdate: The guest is currently being migrated from another machine.
+#
+# Since: 2.12
+##
+{ 'enum': 'SevState',
+ 'data': ['uninit', 'lupdate', 'lsecret', 'running', 'supdate', 'rupdate' ] }
+
+##
+# @SevInfo:
+#
+# Information about Secure Encrypted Virtualization (SEV) support
+#
+# @enabled: true if SEV is active
+#
+# @api-major: SEV API major version
+#
+# @api-minor: SEV API minor version
+#
+# @build-id: SEV FW build id
+#
+# @policy: SEV policy value
+#
+# @state: SEV guest state
+#
+# @handle: SEV firmware handle
+#
+# Since: 2.12
+##
+{ 'struct': 'SevInfo',
+ 'data': { 'enabled': 'bool',
+ 'api-major': 'uint8',
+ 'api-minor' : 'uint8',
+ 'build-id' : 'uint8',
+ 'policy' : 'uint32',
+ 'state' : 'SevState',
+ 'handle' : 'uint32'
+ }
+}
+
+##
+# @query-sev:
+#
+# Returns information about SEV
+#
+# Returns: @SevInfo
+#
+# Since: 2.12
+#
+# Example:
+#
+# -> { "execute": "query-sev" }
+# <- { "return": { "enabled": true, "api-major" : 0, "api-minor" : 0,
+# "build-id" : 0, "policy" : 0, "state" : "running",
+# "handle" : 1 } }
+#
+##
+{ 'command': 'query-sev', 'returns': 'SevInfo' }
diff --git a/target/i386/monitor.c b/target/i386/monitor.c
index 55ea10deb8ef..27b99adf395b 100644
--- a/target/i386/monitor.c
+++ b/target/i386/monitor.c
@@ -30,6 +30,8 @@
#include "hw/i386/pc.h"
#include "sysemu/kvm.h"
#include "hmp.h"
+#include "sev_i386.h"
+#include "qapi/qapi-commands-misc.h"
static void print_pte(Monitor *mon, CPUArchState *env, hwaddr addr,
@@ -665,3 +667,9 @@ void hmp_info_io_apic(Monitor *mon, const QDict *qdict)
ioapic_dump_state(mon, qdict);
}
}
+
+SevInfo *qmp_query_sev(Error **errp)
+{
+ error_setg(errp, "SEV feature is not available");
+ return NULL;
+}
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [Qemu-devel] [PATCH v12 09/28] qmp: add query-sev command
@ 2018-03-08 12:48 ` Brijesh Singh
0 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:48 UTC (permalink / raw)
To: qemu-devel
Cc: Alistair Francis, Christian Borntraeger, Cornelia Huck,
Daniel P . Berrange, Dr. David Alan Gilbert, Michael S. Tsirkin,
Edgar E. Iglesias, Eduardo Habkost, Eric Blake, kvm,
Marcel Apfelbaum, Markus Armbruster, Paolo Bonzini,
Peter Crosthwaite, Peter Maydell, Richard Henderson,
Stefan Hajnoczi, Thomas Lendacky, Borislav Petkov,
Alexander Graf, Bruce Rogers, Brijesh Singh
The QMP query command can used to retrieve the SEV information when
memory encryption is enabled on AMD platform.
Cc: Eric Blake <eblake@redhat.com>
Cc: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
monitor.c | 7 +++++
qapi/misc.json | 76 +++++++++++++++++++++++++++++++++++++++++++++++++++
target/i386/monitor.c | 8 ++++++
3 files changed, 91 insertions(+)
diff --git a/monitor.c b/monitor.c
index 3f4ba902266b..2225cf5030dc 100644
--- a/monitor.c
+++ b/monitor.c
@@ -983,6 +983,7 @@ static void qmp_unregister_commands_hack(void)
#endif
#ifndef TARGET_I386
qmp_unregister_command(&qmp_commands, "rtc-reset-reinjection");
+ qmp_unregister_command(&qmp_commands, "query-sev");
#endif
#ifndef TARGET_S390X
qmp_unregister_command(&qmp_commands, "dump-skeys");
@@ -4103,6 +4104,12 @@ void qmp_rtc_reset_reinjection(Error **errp)
{
error_setg(errp, QERR_FEATURE_DISABLED, "rtc-reset-reinjection");
}
+
+SevInfo *qmp_query_sev(Error **errp)
+{
+ error_setg(errp, QERR_FEATURE_DISABLED, "query-sev");
+ return NULL;
+}
#endif
#ifndef TARGET_S390X
diff --git a/qapi/misc.json b/qapi/misc.json
index bd04469a4ba2..14681729f8fc 100644
--- a/qapi/misc.json
+++ b/qapi/misc.json
@@ -3201,3 +3201,79 @@
# Since: 2.9
##
{ 'command': 'query-vm-generation-id', 'returns': 'GuidInfo' }
+
+
+##
+# @SevState:
+#
+# An enumeration of SEV state information used during @query-sev.
+#
+# @uninit: The guest is uninitialized.
+#
+# @lupdate: The guest is currently being launched and plaintext and
+# reigster state is being imported.
+#
+# @lsecret: The guest is currently being launched and ciphertext data
+# are being imported.
+#
+# @running: The guest is fully launched or migrated in.
+#
+# @supdate: The guest is currently being migrated out to another machine.
+#
+# @rupdate: The guest is currently being migrated from another machine.
+#
+# Since: 2.12
+##
+{ 'enum': 'SevState',
+ 'data': ['uninit', 'lupdate', 'lsecret', 'running', 'supdate', 'rupdate' ] }
+
+##
+# @SevInfo:
+#
+# Information about Secure Encrypted Virtualization (SEV) support
+#
+# @enabled: true if SEV is active
+#
+# @api-major: SEV API major version
+#
+# @api-minor: SEV API minor version
+#
+# @build-id: SEV FW build id
+#
+# @policy: SEV policy value
+#
+# @state: SEV guest state
+#
+# @handle: SEV firmware handle
+#
+# Since: 2.12
+##
+{ 'struct': 'SevInfo',
+ 'data': { 'enabled': 'bool',
+ 'api-major': 'uint8',
+ 'api-minor' : 'uint8',
+ 'build-id' : 'uint8',
+ 'policy' : 'uint32',
+ 'state' : 'SevState',
+ 'handle' : 'uint32'
+ }
+}
+
+##
+# @query-sev:
+#
+# Returns information about SEV
+#
+# Returns: @SevInfo
+#
+# Since: 2.12
+#
+# Example:
+#
+# -> { "execute": "query-sev" }
+# <- { "return": { "enabled": true, "api-major" : 0, "api-minor" : 0,
+# "build-id" : 0, "policy" : 0, "state" : "running",
+# "handle" : 1 } }
+#
+##
+{ 'command': 'query-sev', 'returns': 'SevInfo' }
diff --git a/target/i386/monitor.c b/target/i386/monitor.c
index 55ea10deb8ef..27b99adf395b 100644
--- a/target/i386/monitor.c
+++ b/target/i386/monitor.c
@@ -30,6 +30,8 @@
#include "hw/i386/pc.h"
#include "sysemu/kvm.h"
#include "hmp.h"
+#include "sev_i386.h"
+#include "qapi/qapi-commands-misc.h"
static void print_pte(Monitor *mon, CPUArchState *env, hwaddr addr,
@@ -665,3 +667,9 @@ void hmp_info_io_apic(Monitor *mon, const QDict *qdict)
ioapic_dump_state(mon, qdict);
}
}
+
+SevInfo *qmp_query_sev(Error **errp)
+{
+ error_setg(errp, "SEV feature is not available");
+ return NULL;
+}
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH v12 10/28] include: add psp-sev.h header file
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
@ 2018-03-08 12:48 ` Brijesh Singh
-1 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:48 UTC (permalink / raw)
To: qemu-devel
Cc: Peter Maydell, Brijesh Singh, kvm, Michael S. Tsirkin,
Stefan Hajnoczi, Alexander Graf, Edgar E. Iglesias,
Markus Armbruster, Bruce Rogers, Christian Borntraeger,
Marcel Apfelbaum, Borislav Petkov, Thomas Lendacky,
Eduardo Habkost, Richard Henderson, Dr. David Alan Gilbert,
Alistair Francis, Cornelia Huck, Richard Henderson,
Peter Crosthwaite, Paolo Bonzini
The header file provide the ioctl command and structure to communicate
with /dev/sev device.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
| 142 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 142 insertions(+)
create mode 100644 linux-headers/linux/psp-sev.h
--git a/linux-headers/linux/psp-sev.h b/linux-headers/linux/psp-sev.h
new file mode 100644
index 000000000000..33e247471ae0
--- /dev/null
+++ b/linux-headers/linux/psp-sev.h
@@ -0,0 +1,142 @@
+/*
+ * Userspace interface for AMD Secure Encrypted Virtualization (SEV)
+ * platform management commands.
+ *
+ * Copyright (C) 2016-2017 Advanced Micro Devices, Inc.
+ *
+ * Author: Brijesh Singh <brijesh.singh@amd.com>
+ *
+ * SEV spec 0.14 is available at:
+ * http://support.amd.com/TechDocs/55766_SEV-KM%20API_Specification.pdf
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __PSP_SEV_USER_H__
+#define __PSP_SEV_USER_H__
+
+#include <linux/types.h>
+
+/**
+ * SEV platform commands
+ */
+enum {
+ SEV_FACTORY_RESET = 0,
+ SEV_PLATFORM_STATUS,
+ SEV_PEK_GEN,
+ SEV_PEK_CSR,
+ SEV_PDH_GEN,
+ SEV_PDH_CERT_EXPORT,
+ SEV_PEK_CERT_IMPORT,
+
+ SEV_MAX,
+};
+
+/**
+ * SEV Firmware status code
+ */
+typedef enum {
+ SEV_RET_SUCCESS = 0,
+ SEV_RET_INVALID_PLATFORM_STATE,
+ SEV_RET_INVALID_GUEST_STATE,
+ SEV_RET_INAVLID_CONFIG,
+ SEV_RET_INVALID_LEN,
+ SEV_RET_ALREADY_OWNED,
+ SEV_RET_INVALID_CERTIFICATE,
+ SEV_RET_POLICY_FAILURE,
+ SEV_RET_INACTIVE,
+ SEV_RET_INVALID_ADDRESS,
+ SEV_RET_BAD_SIGNATURE,
+ SEV_RET_BAD_MEASUREMENT,
+ SEV_RET_ASID_OWNED,
+ SEV_RET_INVALID_ASID,
+ SEV_RET_WBINVD_REQUIRED,
+ SEV_RET_DFFLUSH_REQUIRED,
+ SEV_RET_INVALID_GUEST,
+ SEV_RET_INVALID_COMMAND,
+ SEV_RET_ACTIVE,
+ SEV_RET_HWSEV_RET_PLATFORM,
+ SEV_RET_HWSEV_RET_UNSAFE,
+ SEV_RET_UNSUPPORTED,
+ SEV_RET_MAX,
+} sev_ret_code;
+
+/**
+ * struct sev_user_data_status - PLATFORM_STATUS command parameters
+ *
+ * @major: major API version
+ * @minor: minor API version
+ * @state: platform state
+ * @flags: platform config flags
+ * @build: firmware build id for API version
+ * @guest_count: number of active guests
+ */
+struct sev_user_data_status {
+ __u8 api_major; /* Out */
+ __u8 api_minor; /* Out */
+ __u8 state; /* Out */
+ __u32 flags; /* Out */
+ __u8 build; /* Out */
+ __u32 guest_count; /* Out */
+} __attribute__((packed));
+
+/**
+ * struct sev_user_data_pek_csr - PEK_CSR command parameters
+ *
+ * @address: PEK certificate chain
+ * @length: length of certificate
+ */
+struct sev_user_data_pek_csr {
+ __u64 address; /* In */
+ __u32 length; /* In/Out */
+} __attribute__((packed));
+
+/**
+ * struct sev_user_data_cert_import - PEK_CERT_IMPORT command parameters
+ *
+ * @pek_address: PEK certificate chain
+ * @pek_len: length of PEK certificate
+ * @oca_address: OCA certificate chain
+ * @oca_len: length of OCA certificate
+ */
+struct sev_user_data_pek_cert_import {
+ __u64 pek_cert_address; /* In */
+ __u32 pek_cert_len; /* In */
+ __u64 oca_cert_address; /* In */
+ __u32 oca_cert_len; /* In */
+} __attribute__((packed));
+
+/**
+ * struct sev_user_data_pdh_cert_export - PDH_CERT_EXPORT command parameters
+ *
+ * @pdh_address: PDH certificate address
+ * @pdh_len: length of PDH certificate
+ * @cert_chain_address: PDH certificate chain
+ * @cert_chain_len: length of PDH certificate chain
+ */
+struct sev_user_data_pdh_cert_export {
+ __u64 pdh_cert_address; /* In */
+ __u32 pdh_cert_len; /* In/Out */
+ __u64 cert_chain_address; /* In */
+ __u32 cert_chain_len; /* In/Out */
+} __attribute__((packed));
+
+/**
+ * struct sev_issue_cmd - SEV ioctl parameters
+ *
+ * @cmd: SEV commands to execute
+ * @opaque: pointer to the command structure
+ * @error: SEV FW return code on failure
+ */
+struct sev_issue_cmd {
+ __u32 cmd; /* In */
+ __u64 data; /* In */
+ __u32 error; /* Out */
+} __attribute__((packed));
+
+#define SEV_IOC_TYPE 'S'
+#define SEV_ISSUE_CMD _IOWR(SEV_IOC_TYPE, 0x0, struct sev_issue_cmd)
+
+#endif /* __PSP_USER_SEV_H */
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [Qemu-devel] [PATCH v12 10/28] include: add psp-sev.h header file
@ 2018-03-08 12:48 ` Brijesh Singh
0 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:48 UTC (permalink / raw)
To: qemu-devel
Cc: Alistair Francis, Christian Borntraeger, Cornelia Huck,
Daniel P . Berrange, Dr. David Alan Gilbert, Michael S. Tsirkin,
Edgar E. Iglesias, Eduardo Habkost, Eric Blake, kvm,
Marcel Apfelbaum, Markus Armbruster, Paolo Bonzini,
Peter Crosthwaite, Peter Maydell, Richard Henderson,
Stefan Hajnoczi, Thomas Lendacky, Borislav Petkov,
Alexander Graf, Bruce Rogers, Brijesh Singh, Richard Henderson
The header file provide the ioctl command and structure to communicate
with /dev/sev device.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
| 142 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 142 insertions(+)
create mode 100644 linux-headers/linux/psp-sev.h
--git a/linux-headers/linux/psp-sev.h b/linux-headers/linux/psp-sev.h
new file mode 100644
index 000000000000..33e247471ae0
--- /dev/null
+++ b/linux-headers/linux/psp-sev.h
@@ -0,0 +1,142 @@
+/*
+ * Userspace interface for AMD Secure Encrypted Virtualization (SEV)
+ * platform management commands.
+ *
+ * Copyright (C) 2016-2017 Advanced Micro Devices, Inc.
+ *
+ * Author: Brijesh Singh <brijesh.singh@amd.com>
+ *
+ * SEV spec 0.14 is available at:
+ * http://support.amd.com/TechDocs/55766_SEV-KM%20API_Specification.pdf
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __PSP_SEV_USER_H__
+#define __PSP_SEV_USER_H__
+
+#include <linux/types.h>
+
+/**
+ * SEV platform commands
+ */
+enum {
+ SEV_FACTORY_RESET = 0,
+ SEV_PLATFORM_STATUS,
+ SEV_PEK_GEN,
+ SEV_PEK_CSR,
+ SEV_PDH_GEN,
+ SEV_PDH_CERT_EXPORT,
+ SEV_PEK_CERT_IMPORT,
+
+ SEV_MAX,
+};
+
+/**
+ * SEV Firmware status code
+ */
+typedef enum {
+ SEV_RET_SUCCESS = 0,
+ SEV_RET_INVALID_PLATFORM_STATE,
+ SEV_RET_INVALID_GUEST_STATE,
+ SEV_RET_INAVLID_CONFIG,
+ SEV_RET_INVALID_LEN,
+ SEV_RET_ALREADY_OWNED,
+ SEV_RET_INVALID_CERTIFICATE,
+ SEV_RET_POLICY_FAILURE,
+ SEV_RET_INACTIVE,
+ SEV_RET_INVALID_ADDRESS,
+ SEV_RET_BAD_SIGNATURE,
+ SEV_RET_BAD_MEASUREMENT,
+ SEV_RET_ASID_OWNED,
+ SEV_RET_INVALID_ASID,
+ SEV_RET_WBINVD_REQUIRED,
+ SEV_RET_DFFLUSH_REQUIRED,
+ SEV_RET_INVALID_GUEST,
+ SEV_RET_INVALID_COMMAND,
+ SEV_RET_ACTIVE,
+ SEV_RET_HWSEV_RET_PLATFORM,
+ SEV_RET_HWSEV_RET_UNSAFE,
+ SEV_RET_UNSUPPORTED,
+ SEV_RET_MAX,
+} sev_ret_code;
+
+/**
+ * struct sev_user_data_status - PLATFORM_STATUS command parameters
+ *
+ * @major: major API version
+ * @minor: minor API version
+ * @state: platform state
+ * @flags: platform config flags
+ * @build: firmware build id for API version
+ * @guest_count: number of active guests
+ */
+struct sev_user_data_status {
+ __u8 api_major; /* Out */
+ __u8 api_minor; /* Out */
+ __u8 state; /* Out */
+ __u32 flags; /* Out */
+ __u8 build; /* Out */
+ __u32 guest_count; /* Out */
+} __attribute__((packed));
+
+/**
+ * struct sev_user_data_pek_csr - PEK_CSR command parameters
+ *
+ * @address: PEK certificate chain
+ * @length: length of certificate
+ */
+struct sev_user_data_pek_csr {
+ __u64 address; /* In */
+ __u32 length; /* In/Out */
+} __attribute__((packed));
+
+/**
+ * struct sev_user_data_cert_import - PEK_CERT_IMPORT command parameters
+ *
+ * @pek_address: PEK certificate chain
+ * @pek_len: length of PEK certificate
+ * @oca_address: OCA certificate chain
+ * @oca_len: length of OCA certificate
+ */
+struct sev_user_data_pek_cert_import {
+ __u64 pek_cert_address; /* In */
+ __u32 pek_cert_len; /* In */
+ __u64 oca_cert_address; /* In */
+ __u32 oca_cert_len; /* In */
+} __attribute__((packed));
+
+/**
+ * struct sev_user_data_pdh_cert_export - PDH_CERT_EXPORT command parameters
+ *
+ * @pdh_address: PDH certificate address
+ * @pdh_len: length of PDH certificate
+ * @cert_chain_address: PDH certificate chain
+ * @cert_chain_len: length of PDH certificate chain
+ */
+struct sev_user_data_pdh_cert_export {
+ __u64 pdh_cert_address; /* In */
+ __u32 pdh_cert_len; /* In/Out */
+ __u64 cert_chain_address; /* In */
+ __u32 cert_chain_len; /* In/Out */
+} __attribute__((packed));
+
+/**
+ * struct sev_issue_cmd - SEV ioctl parameters
+ *
+ * @cmd: SEV commands to execute
+ * @opaque: pointer to the command structure
+ * @error: SEV FW return code on failure
+ */
+struct sev_issue_cmd {
+ __u32 cmd; /* In */
+ __u64 data; /* In */
+ __u32 error; /* Out */
+} __attribute__((packed));
+
+#define SEV_IOC_TYPE 'S'
+#define SEV_ISSUE_CMD _IOWR(SEV_IOC_TYPE, 0x0, struct sev_issue_cmd)
+
+#endif /* __PSP_USER_SEV_H */
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH v12 11/28] sev/i386: add command to initialize the memory encryption context
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
@ 2018-03-08 12:48 ` Brijesh Singh
-1 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:48 UTC (permalink / raw)
To: qemu-devel
Cc: Peter Maydell, Brijesh Singh, kvm, Michael S. Tsirkin,
Stefan Hajnoczi, Alexander Graf, Edgar E. Iglesias,
Markus Armbruster, Bruce Rogers, Christian Borntraeger,
Marcel Apfelbaum, Borislav Petkov, Thomas Lendacky,
Eduardo Habkost, Richard Henderson, Dr. David Alan Gilbert,
Alistair Francis, Cornelia Huck, Richard Henderson,
Peter Crosthwaite, Paolo Bonzini
When memory encryption is enabled, KVM_SEV_INIT command is used to
initialize the platform. The command loads the SEV related persistent
data from non-volatile storage and initializes the platform context.
This command should be first issued before invoking any other guest
commands provided by the SEV firmware.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
accel/kvm/kvm-all.c | 16 ++++
include/sysemu/sev.h | 22 +++++
stubs/Makefile.objs | 1 +
stubs/sev.c | 21 +++++
target/i386/Makefile.objs | 2 +-
target/i386/monitor.c | 11 ++-
target/i386/sev-stub.c | 41 +++++++++
target/i386/sev.c | 224 ++++++++++++++++++++++++++++++++++++++++++++++
target/i386/sev_i386.h | 24 +++++
target/i386/trace-events | 3 +
10 files changed, 362 insertions(+), 3 deletions(-)
create mode 100644 include/sysemu/sev.h
create mode 100644 stubs/sev.c
create mode 100644 target/i386/sev-stub.c
diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index b91fcb7160d3..a6473522be11 100644
--- a/accel/kvm/kvm-all.c
+++ b/accel/kvm/kvm-all.c
@@ -38,6 +38,7 @@
#include "qemu/event_notifier.h"
#include "trace.h"
#include "hw/irq.h"
+#include "sysemu/sev.h"
#include "hw/boards.h"
@@ -103,6 +104,9 @@ struct KVMState
#endif
KVMMemoryListener memory_listener;
QLIST_HEAD(, KVMParkedVcpu) kvm_parked_vcpus;
+
+ /* memory encryption */
+ void *memcrypt_handle;
};
KVMState *kvm_state;
@@ -1636,6 +1640,18 @@ static int kvm_init(MachineState *ms)
kvm_state = s;
+ /*
+ * if memory encryption object is specified then initialize the memory
+ * encryption context.
+ */
+ if (ms->memory_encryption) {
+ kvm_state->memcrypt_handle = sev_guest_init(ms->memory_encryption);
+ if (!kvm_state->memcrypt_handle) {
+ ret = -1;
+ goto err;
+ }
+ }
+
ret = kvm_arch_init(ms, s);
if (ret < 0) {
goto err;
diff --git a/include/sysemu/sev.h b/include/sysemu/sev.h
new file mode 100644
index 000000000000..3f6a26e92789
--- /dev/null
+++ b/include/sysemu/sev.h
@@ -0,0 +1,22 @@
+/*
+ * QEMU Secure Encrypted Virutualization (SEV) support
+ *
+ * Copyright: Advanced Micro Devices, 2016-2018
+ *
+ * Authors:
+ * Brijesh Singh <brijesh.singh@amd.com>
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#ifndef QEMU_SEV_H
+#define QEMU_SEV_H
+
+#include "sysemu/kvm.h"
+
+void *sev_guest_init(const char *id);
+int sev_encrypt_data(void *handle, uint8_t *ptr, uint64_t len);
+void sev_set_debug_ops(void *handle, MemoryRegion *mr);
+#endif
diff --git a/stubs/Makefile.objs b/stubs/Makefile.objs
index 2d59d8409162..31b36fdfdb88 100644
--- a/stubs/Makefile.objs
+++ b/stubs/Makefile.objs
@@ -43,3 +43,4 @@ stub-obj-y += xen-common.o
stub-obj-y += xen-hvm.o
stub-obj-y += pci-host-piix.o
stub-obj-y += ram-block.o
+stub-obj-y += sev.o
diff --git a/stubs/sev.c b/stubs/sev.c
new file mode 100644
index 000000000000..4a5cc5569e5f
--- /dev/null
+++ b/stubs/sev.c
@@ -0,0 +1,21 @@
+/*
+ * QEMU SEV stub
+ *
+ * Copyright Advanced Micro Devices 2018
+ *
+ * Authors:
+ * Brijesh Singh <brijesh.singh@amd.com>
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#include "qemu/osdep.h"
+#include "qemu-common.h"
+#include "sysemu/sev.h"
+
+void *sev_guest_init(const char *id)
+{
+ return NULL;
+}
diff --git a/target/i386/Makefile.objs b/target/i386/Makefile.objs
index 76aeaeae2750..741cb080eb17 100644
--- a/target/i386/Makefile.objs
+++ b/target/i386/Makefile.objs
@@ -5,7 +5,7 @@ obj-$(CONFIG_TCG) += int_helper.o mem_helper.o misc_helper.o mpx_helper.o
obj-$(CONFIG_TCG) += seg_helper.o smm_helper.o svm_helper.o
obj-$(CONFIG_SOFTMMU) += machine.o arch_memory_mapping.o arch_dump.o monitor.o
obj-$(CONFIG_KVM) += kvm.o hyperv.o sev.o
-obj-$(call lnot,$(CONFIG_KVM)) += kvm-stub.o
+obj-$(call lnot,$(CONFIG_KVM)) += kvm-stub.o sev-stub.o
# HAX support
ifdef CONFIG_WIN32
obj-$(CONFIG_HAX) += hax-all.o hax-mem.o hax-windows.o
diff --git a/target/i386/monitor.c b/target/i386/monitor.c
index 27b99adf395b..29de61996371 100644
--- a/target/i386/monitor.c
+++ b/target/i386/monitor.c
@@ -670,6 +670,13 @@ void hmp_info_io_apic(Monitor *mon, const QDict *qdict)
SevInfo *qmp_query_sev(Error **errp)
{
- error_setg(errp, "SEV feature is not available");
- return NULL;
+ SevInfo *info;
+
+ info = sev_get_info();
+ if (!info) {
+ error_setg(errp, "SEV feature is not available");
+ return NULL;
+ }
+
+ return info;
}
diff --git a/target/i386/sev-stub.c b/target/i386/sev-stub.c
new file mode 100644
index 000000000000..c86d8c139237
--- /dev/null
+++ b/target/i386/sev-stub.c
@@ -0,0 +1,41 @@
+/*
+ * QEMU SEV stub
+ *
+ * Copyright Advanced Micro Devices 2018
+ *
+ * Authors:
+ * Brijesh Singh <brijesh.singh@amd.com>
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#include "qemu/osdep.h"
+#include "qemu-common.h"
+#include "sev_i386.h"
+
+SevInfo *sev_get_info(void)
+{
+ return NULL;
+}
+
+bool sev_enabled(void)
+{
+ return false;
+}
+
+uint64_t sev_get_me_mask(void)
+{
+ return ~0;
+}
+
+uint32_t sev_get_cbit_position(void)
+{
+ return 0;
+}
+
+uint32_t sev_get_reduced_phys_bits(void)
+{
+ return 0;
+}
diff --git a/target/i386/sev.c b/target/i386/sev.c
index ab42e4a456d2..288612e1aa46 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -11,6 +11,11 @@
*
*/
+#include <linux/kvm.h>
+#include <linux/psp-sev.h>
+
+#include <sys/ioctl.h>
+
#include "qemu/osdep.h"
#include "qapi/error.h"
#include "qom/object_interfaces.h"
@@ -18,10 +23,88 @@
#include "sysemu/kvm.h"
#include "sev_i386.h"
#include "sysemu/sysemu.h"
+#include "trace.h"
#define DEFAULT_GUEST_POLICY 0x1 /* disable debug */
#define DEFAULT_SEV_DEVICE "/dev/sev"
+static SEVState *sev_state;
+
+static const char *const sev_fw_errlist[] = {
+ "",
+ "Platform state is invalid",
+ "Guest state is invalid",
+ "Platform configuration is invalid",
+ "Buffer too small",
+ "Platform is already owned",
+ "Certificate is invalid",
+ "Policy is not allowed",
+ "Guest is not active",
+ "Invalid address",
+ "Bad signature",
+ "Bad measurement",
+ "Asid is already owned",
+ "Invalid ASID",
+ "WBINVD is required",
+ "DF_FLUSH is required",
+ "Guest handle is invalid",
+ "Invalid command",
+ "Guest is active",
+ "Hardware error",
+ "Hardware unsafe",
+ "Feature not supported",
+ "Invalid parameter"
+};
+
+#define SEV_FW_MAX_ERROR ARRAY_SIZE(sev_fw_errlist)
+
+static int
+sev_ioctl(int fd, int cmd, void *data, int *error)
+{
+ int r;
+ struct kvm_sev_cmd input;
+
+ memset(&input, 0x0, sizeof(input));
+
+ input.id = cmd;
+ input.sev_fd = fd;
+ input.data = (__u64)data;
+
+ r = kvm_vm_ioctl(kvm_state, KVM_MEMORY_ENCRYPT_OP, &input);
+
+ if (error) {
+ *error = input.error;
+ }
+
+ return r;
+}
+
+static int
+sev_platform_ioctl(int fd, int cmd, void *data, int *error)
+{
+ int r;
+ struct sev_issue_cmd arg;
+
+ arg.cmd = cmd;
+ arg.data = (unsigned long)data;
+ r = ioctl(fd, SEV_ISSUE_CMD, &arg);
+ if (error) {
+ *error = arg.error;
+ }
+
+ return r;
+}
+
+static const char *
+fw_error_to_str(int code)
+{
+ if (code >= SEV_FW_MAX_ERROR) {
+ return "unknown error";
+ }
+
+ return sev_fw_errlist[code];
+}
+
static void
qsev_guest_finalize(Object *obj)
{
@@ -219,6 +302,147 @@ static const TypeInfo qsev_guest_info = {
}
};
+static QSevGuestInfo *
+lookup_sev_guest_info(const char *id)
+{
+ Object *obj;
+ QSevGuestInfo *info;
+
+ obj = object_resolve_path_component(object_get_objects_root(), id);
+ if (!obj) {
+ return NULL;
+ }
+
+ info = (QSevGuestInfo *)
+ object_dynamic_cast(obj, TYPE_QSEV_GUEST_INFO);
+ if (!info) {
+ return NULL;
+ }
+
+ return info;
+}
+
+bool
+sev_enabled(void)
+{
+ return sev_state ? true : false;
+}
+
+uint64_t
+sev_get_me_mask(void)
+{
+ return sev_state ? sev_state->me_mask : ~0;
+}
+
+uint32_t
+sev_get_cbit_position(void)
+{
+ return sev_state ? sev_state->cbitpos : 0;
+}
+
+uint32_t
+sev_get_reduced_phys_bits(void)
+{
+ return sev_state ? sev_state->reduced_phys_bits : 0;
+}
+
+SevInfo *
+sev_get_info(void)
+{
+ SevInfo *info;
+
+ info = g_new0(SevInfo, 1);
+ info->enabled = sev_state ? true : false;
+
+ if (info->enabled) {
+ info->api_major = sev_state->api_major;
+ info->api_minor = sev_state->api_minor;
+ info->build_id = sev_state->build_id;
+ info->policy = sev_state->policy;
+ info->state = sev_state->state;
+ info->handle = sev_state->handle;
+ }
+
+ return info;
+}
+
+void *
+sev_guest_init(const char *id)
+{
+ SEVState *s;
+ char *devname;
+ int ret, fw_error;
+ uint32_t ebx;
+ uint32_t host_cbitpos;
+ struct sev_user_data_status status = {};
+
+ s = g_new0(SEVState, 1);
+ s->sev_info = lookup_sev_guest_info(id);
+ if (!s->sev_info) {
+ error_report("%s: '%s' is not a valid '%s' object",
+ __func__, id, TYPE_QSEV_GUEST_INFO);
+ goto err;
+ }
+
+ sev_state = s;
+ s->state = SEV_STATE_UNINIT;
+
+ host_cpuid(0x8000001F, 0, NULL, &ebx, NULL, NULL);
+ host_cbitpos = ebx & 0x3f;
+
+ s->cbitpos = object_property_get_int(OBJECT(s->sev_info), "cbitpos", NULL);
+ if (host_cbitpos != s->cbitpos) {
+ error_report("%s: cbitpos check failed, host '%d' requested '%d'",
+ __func__, host_cbitpos, s->cbitpos);
+ goto err;
+ }
+
+ s->reduced_phys_bits = object_property_get_int(OBJECT(s->sev_info),
+ "reduced-phys-bits", NULL);
+ if (s->reduced_phys_bits < 1) {
+ error_report("%s: reduced_phys_bits check failed, it should be >=1,"
+ "' requested '%d'", __func__, s->reduced_phys_bits);
+ goto err;
+ }
+
+ s->me_mask = ~(1UL << s->cbitpos);
+
+ devname = object_property_get_str(OBJECT(s->sev_info), "sev-device", NULL);
+ s->sev_fd = open(devname, O_RDWR);
+ if (s->sev_fd < 0) {
+ error_report("%s: Failed to open %s '%s'", __func__,
+ devname, strerror(errno));
+ goto err;
+ }
+ g_free(devname);
+
+ ret = sev_platform_ioctl(s->sev_fd, SEV_PLATFORM_STATUS, &status,
+ &fw_error);
+ if (ret) {
+ error_report("%s: failed to get platform status ret=%d"
+ "fw_error='%d: %s'", __func__, ret, fw_error,
+ fw_error_to_str(fw_error));
+ goto err;
+ }
+ s->build_id = status.build;
+ s->api_major = status.api_major;
+ s->api_minor = status.api_minor;
+
+ trace_kvm_sev_init();
+ ret = sev_ioctl(s->sev_fd, KVM_SEV_INIT, NULL, &fw_error);
+ if (ret) {
+ error_report("%s: failed to initialize ret=%d fw_error=%d '%s'",
+ __func__, ret, fw_error, fw_error_to_str(fw_error));
+ goto err;
+ }
+
+ return s;
+err:
+ g_free(sev_state);
+ sev_state = NULL;
+ return NULL;
+}
+
static void
sev_register_types(void)
{
diff --git a/target/i386/sev_i386.h b/target/i386/sev_i386.h
index caf879c3b874..924cebcab02d 100644
--- a/target/i386/sev_i386.h
+++ b/target/i386/sev_i386.h
@@ -17,7 +17,9 @@
#include "qom/object.h"
#include "qapi/error.h"
#include "sysemu/kvm.h"
+#include "sysemu/sev.h"
#include "qemu/error-report.h"
+#include "qapi/qapi-commands-misc.h"
#define SEV_POLICY_NODBG 0x1
#define SEV_POLICY_NOKS 0x2
@@ -30,6 +32,12 @@
#define QSEV_GUEST_INFO(obj) \
OBJECT_CHECK(QSevGuestInfo, (obj), TYPE_QSEV_GUEST_INFO)
+extern bool sev_enabled(void);
+extern uint64_t sev_get_me_mask(void);
+extern SevInfo *sev_get_info(void);
+extern uint32_t sev_get_cbit_position(void);
+extern uint32_t sev_get_reduced_phys_bits(void);
+
typedef struct QSevGuestInfo QSevGuestInfo;
typedef struct QSevGuestInfoClass QSevGuestInfoClass;
@@ -58,4 +66,20 @@ struct QSevGuestInfoClass {
ObjectClass parent_class;
};
+struct SEVState {
+ QSevGuestInfo *sev_info;
+ uint8_t api_major;
+ uint8_t api_minor;
+ uint8_t build_id;
+ uint32_t policy;
+ uint64_t me_mask;
+ uint32_t cbitpos;
+ uint32_t reduced_phys_bits;
+ uint32_t handle;
+ int sev_fd;
+ SevState state;
+};
+
+typedef struct SEVState SEVState;
+
#endif
diff --git a/target/i386/trace-events b/target/i386/trace-events
index 3153fd445488..797b716751b7 100644
--- a/target/i386/trace-events
+++ b/target/i386/trace-events
@@ -5,3 +5,6 @@ kvm_x86_fixup_msi_error(uint32_t gsi) "VT-d failed to remap interrupt for GSI %"
kvm_x86_add_msi_route(int virq) "Adding route entry for virq %d"
kvm_x86_remove_msi_route(int virq) "Removing route entry for virq %d"
kvm_x86_update_msi_routes(int num) "Updated %d MSI routes"
+
+# target/i386/sev.c
+kvm_sev_init(void) ""
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [Qemu-devel] [PATCH v12 11/28] sev/i386: add command to initialize the memory encryption context
@ 2018-03-08 12:48 ` Brijesh Singh
0 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:48 UTC (permalink / raw)
To: qemu-devel
Cc: Alistair Francis, Christian Borntraeger, Cornelia Huck,
Daniel P . Berrange, Dr. David Alan Gilbert, Michael S. Tsirkin,
Edgar E. Iglesias, Eduardo Habkost, Eric Blake, kvm,
Marcel Apfelbaum, Markus Armbruster, Paolo Bonzini,
Peter Crosthwaite, Peter Maydell, Richard Henderson,
Stefan Hajnoczi, Thomas Lendacky, Borislav Petkov,
Alexander Graf, Bruce Rogers, Brijesh Singh, Richard Henderson
When memory encryption is enabled, KVM_SEV_INIT command is used to
initialize the platform. The command loads the SEV related persistent
data from non-volatile storage and initializes the platform context.
This command should be first issued before invoking any other guest
commands provided by the SEV firmware.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
accel/kvm/kvm-all.c | 16 ++++
include/sysemu/sev.h | 22 +++++
stubs/Makefile.objs | 1 +
stubs/sev.c | 21 +++++
target/i386/Makefile.objs | 2 +-
target/i386/monitor.c | 11 ++-
target/i386/sev-stub.c | 41 +++++++++
target/i386/sev.c | 224 ++++++++++++++++++++++++++++++++++++++++++++++
target/i386/sev_i386.h | 24 +++++
target/i386/trace-events | 3 +
10 files changed, 362 insertions(+), 3 deletions(-)
create mode 100644 include/sysemu/sev.h
create mode 100644 stubs/sev.c
create mode 100644 target/i386/sev-stub.c
diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index b91fcb7160d3..a6473522be11 100644
--- a/accel/kvm/kvm-all.c
+++ b/accel/kvm/kvm-all.c
@@ -38,6 +38,7 @@
#include "qemu/event_notifier.h"
#include "trace.h"
#include "hw/irq.h"
+#include "sysemu/sev.h"
#include "hw/boards.h"
@@ -103,6 +104,9 @@ struct KVMState
#endif
KVMMemoryListener memory_listener;
QLIST_HEAD(, KVMParkedVcpu) kvm_parked_vcpus;
+
+ /* memory encryption */
+ void *memcrypt_handle;
};
KVMState *kvm_state;
@@ -1636,6 +1640,18 @@ static int kvm_init(MachineState *ms)
kvm_state = s;
+ /*
+ * if memory encryption object is specified then initialize the memory
+ * encryption context.
+ */
+ if (ms->memory_encryption) {
+ kvm_state->memcrypt_handle = sev_guest_init(ms->memory_encryption);
+ if (!kvm_state->memcrypt_handle) {
+ ret = -1;
+ goto err;
+ }
+ }
+
ret = kvm_arch_init(ms, s);
if (ret < 0) {
goto err;
diff --git a/include/sysemu/sev.h b/include/sysemu/sev.h
new file mode 100644
index 000000000000..3f6a26e92789
--- /dev/null
+++ b/include/sysemu/sev.h
@@ -0,0 +1,22 @@
+/*
+ * QEMU Secure Encrypted Virutualization (SEV) support
+ *
+ * Copyright: Advanced Micro Devices, 2016-2018
+ *
+ * Authors:
+ * Brijesh Singh <brijesh.singh@amd.com>
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#ifndef QEMU_SEV_H
+#define QEMU_SEV_H
+
+#include "sysemu/kvm.h"
+
+void *sev_guest_init(const char *id);
+int sev_encrypt_data(void *handle, uint8_t *ptr, uint64_t len);
+void sev_set_debug_ops(void *handle, MemoryRegion *mr);
+#endif
diff --git a/stubs/Makefile.objs b/stubs/Makefile.objs
index 2d59d8409162..31b36fdfdb88 100644
--- a/stubs/Makefile.objs
+++ b/stubs/Makefile.objs
@@ -43,3 +43,4 @@ stub-obj-y += xen-common.o
stub-obj-y += xen-hvm.o
stub-obj-y += pci-host-piix.o
stub-obj-y += ram-block.o
+stub-obj-y += sev.o
diff --git a/stubs/sev.c b/stubs/sev.c
new file mode 100644
index 000000000000..4a5cc5569e5f
--- /dev/null
+++ b/stubs/sev.c
@@ -0,0 +1,21 @@
+/*
+ * QEMU SEV stub
+ *
+ * Copyright Advanced Micro Devices 2018
+ *
+ * Authors:
+ * Brijesh Singh <brijesh.singh@amd.com>
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#include "qemu/osdep.h"
+#include "qemu-common.h"
+#include "sysemu/sev.h"
+
+void *sev_guest_init(const char *id)
+{
+ return NULL;
+}
diff --git a/target/i386/Makefile.objs b/target/i386/Makefile.objs
index 76aeaeae2750..741cb080eb17 100644
--- a/target/i386/Makefile.objs
+++ b/target/i386/Makefile.objs
@@ -5,7 +5,7 @@ obj-$(CONFIG_TCG) += int_helper.o mem_helper.o misc_helper.o mpx_helper.o
obj-$(CONFIG_TCG) += seg_helper.o smm_helper.o svm_helper.o
obj-$(CONFIG_SOFTMMU) += machine.o arch_memory_mapping.o arch_dump.o monitor.o
obj-$(CONFIG_KVM) += kvm.o hyperv.o sev.o
-obj-$(call lnot,$(CONFIG_KVM)) += kvm-stub.o
+obj-$(call lnot,$(CONFIG_KVM)) += kvm-stub.o sev-stub.o
# HAX support
ifdef CONFIG_WIN32
obj-$(CONFIG_HAX) += hax-all.o hax-mem.o hax-windows.o
diff --git a/target/i386/monitor.c b/target/i386/monitor.c
index 27b99adf395b..29de61996371 100644
--- a/target/i386/monitor.c
+++ b/target/i386/monitor.c
@@ -670,6 +670,13 @@ void hmp_info_io_apic(Monitor *mon, const QDict *qdict)
SevInfo *qmp_query_sev(Error **errp)
{
- error_setg(errp, "SEV feature is not available");
- return NULL;
+ SevInfo *info;
+
+ info = sev_get_info();
+ if (!info) {
+ error_setg(errp, "SEV feature is not available");
+ return NULL;
+ }
+
+ return info;
}
diff --git a/target/i386/sev-stub.c b/target/i386/sev-stub.c
new file mode 100644
index 000000000000..c86d8c139237
--- /dev/null
+++ b/target/i386/sev-stub.c
@@ -0,0 +1,41 @@
+/*
+ * QEMU SEV stub
+ *
+ * Copyright Advanced Micro Devices 2018
+ *
+ * Authors:
+ * Brijesh Singh <brijesh.singh@amd.com>
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#include "qemu/osdep.h"
+#include "qemu-common.h"
+#include "sev_i386.h"
+
+SevInfo *sev_get_info(void)
+{
+ return NULL;
+}
+
+bool sev_enabled(void)
+{
+ return false;
+}
+
+uint64_t sev_get_me_mask(void)
+{
+ return ~0;
+}
+
+uint32_t sev_get_cbit_position(void)
+{
+ return 0;
+}
+
+uint32_t sev_get_reduced_phys_bits(void)
+{
+ return 0;
+}
diff --git a/target/i386/sev.c b/target/i386/sev.c
index ab42e4a456d2..288612e1aa46 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -11,6 +11,11 @@
*
*/
+#include <linux/kvm.h>
+#include <linux/psp-sev.h>
+
+#include <sys/ioctl.h>
+
#include "qemu/osdep.h"
#include "qapi/error.h"
#include "qom/object_interfaces.h"
@@ -18,10 +23,88 @@
#include "sysemu/kvm.h"
#include "sev_i386.h"
#include "sysemu/sysemu.h"
+#include "trace.h"
#define DEFAULT_GUEST_POLICY 0x1 /* disable debug */
#define DEFAULT_SEV_DEVICE "/dev/sev"
+static SEVState *sev_state;
+
+static const char *const sev_fw_errlist[] = {
+ "",
+ "Platform state is invalid",
+ "Guest state is invalid",
+ "Platform configuration is invalid",
+ "Buffer too small",
+ "Platform is already owned",
+ "Certificate is invalid",
+ "Policy is not allowed",
+ "Guest is not active",
+ "Invalid address",
+ "Bad signature",
+ "Bad measurement",
+ "Asid is already owned",
+ "Invalid ASID",
+ "WBINVD is required",
+ "DF_FLUSH is required",
+ "Guest handle is invalid",
+ "Invalid command",
+ "Guest is active",
+ "Hardware error",
+ "Hardware unsafe",
+ "Feature not supported",
+ "Invalid parameter"
+};
+
+#define SEV_FW_MAX_ERROR ARRAY_SIZE(sev_fw_errlist)
+
+static int
+sev_ioctl(int fd, int cmd, void *data, int *error)
+{
+ int r;
+ struct kvm_sev_cmd input;
+
+ memset(&input, 0x0, sizeof(input));
+
+ input.id = cmd;
+ input.sev_fd = fd;
+ input.data = (__u64)data;
+
+ r = kvm_vm_ioctl(kvm_state, KVM_MEMORY_ENCRYPT_OP, &input);
+
+ if (error) {
+ *error = input.error;
+ }
+
+ return r;
+}
+
+static int
+sev_platform_ioctl(int fd, int cmd, void *data, int *error)
+{
+ int r;
+ struct sev_issue_cmd arg;
+
+ arg.cmd = cmd;
+ arg.data = (unsigned long)data;
+ r = ioctl(fd, SEV_ISSUE_CMD, &arg);
+ if (error) {
+ *error = arg.error;
+ }
+
+ return r;
+}
+
+static const char *
+fw_error_to_str(int code)
+{
+ if (code >= SEV_FW_MAX_ERROR) {
+ return "unknown error";
+ }
+
+ return sev_fw_errlist[code];
+}
+
static void
qsev_guest_finalize(Object *obj)
{
@@ -219,6 +302,147 @@ static const TypeInfo qsev_guest_info = {
}
};
+static QSevGuestInfo *
+lookup_sev_guest_info(const char *id)
+{
+ Object *obj;
+ QSevGuestInfo *info;
+
+ obj = object_resolve_path_component(object_get_objects_root(), id);
+ if (!obj) {
+ return NULL;
+ }
+
+ info = (QSevGuestInfo *)
+ object_dynamic_cast(obj, TYPE_QSEV_GUEST_INFO);
+ if (!info) {
+ return NULL;
+ }
+
+ return info;
+}
+
+bool
+sev_enabled(void)
+{
+ return sev_state ? true : false;
+}
+
+uint64_t
+sev_get_me_mask(void)
+{
+ return sev_state ? sev_state->me_mask : ~0;
+}
+
+uint32_t
+sev_get_cbit_position(void)
+{
+ return sev_state ? sev_state->cbitpos : 0;
+}
+
+uint32_t
+sev_get_reduced_phys_bits(void)
+{
+ return sev_state ? sev_state->reduced_phys_bits : 0;
+}
+
+SevInfo *
+sev_get_info(void)
+{
+ SevInfo *info;
+
+ info = g_new0(SevInfo, 1);
+ info->enabled = sev_state ? true : false;
+
+ if (info->enabled) {
+ info->api_major = sev_state->api_major;
+ info->api_minor = sev_state->api_minor;
+ info->build_id = sev_state->build_id;
+ info->policy = sev_state->policy;
+ info->state = sev_state->state;
+ info->handle = sev_state->handle;
+ }
+
+ return info;
+}
+
+void *
+sev_guest_init(const char *id)
+{
+ SEVState *s;
+ char *devname;
+ int ret, fw_error;
+ uint32_t ebx;
+ uint32_t host_cbitpos;
+ struct sev_user_data_status status = {};
+
+ s = g_new0(SEVState, 1);
+ s->sev_info = lookup_sev_guest_info(id);
+ if (!s->sev_info) {
+ error_report("%s: '%s' is not a valid '%s' object",
+ __func__, id, TYPE_QSEV_GUEST_INFO);
+ goto err;
+ }
+
+ sev_state = s;
+ s->state = SEV_STATE_UNINIT;
+
+ host_cpuid(0x8000001F, 0, NULL, &ebx, NULL, NULL);
+ host_cbitpos = ebx & 0x3f;
+
+ s->cbitpos = object_property_get_int(OBJECT(s->sev_info), "cbitpos", NULL);
+ if (host_cbitpos != s->cbitpos) {
+ error_report("%s: cbitpos check failed, host '%d' requested '%d'",
+ __func__, host_cbitpos, s->cbitpos);
+ goto err;
+ }
+
+ s->reduced_phys_bits = object_property_get_int(OBJECT(s->sev_info),
+ "reduced-phys-bits", NULL);
+ if (s->reduced_phys_bits < 1) {
+ error_report("%s: reduced_phys_bits check failed, it should be >=1,"
+ "' requested '%d'", __func__, s->reduced_phys_bits);
+ goto err;
+ }
+
+ s->me_mask = ~(1UL << s->cbitpos);
+
+ devname = object_property_get_str(OBJECT(s->sev_info), "sev-device", NULL);
+ s->sev_fd = open(devname, O_RDWR);
+ if (s->sev_fd < 0) {
+ error_report("%s: Failed to open %s '%s'", __func__,
+ devname, strerror(errno));
+ goto err;
+ }
+ g_free(devname);
+
+ ret = sev_platform_ioctl(s->sev_fd, SEV_PLATFORM_STATUS, &status,
+ &fw_error);
+ if (ret) {
+ error_report("%s: failed to get platform status ret=%d"
+ "fw_error='%d: %s'", __func__, ret, fw_error,
+ fw_error_to_str(fw_error));
+ goto err;
+ }
+ s->build_id = status.build;
+ s->api_major = status.api_major;
+ s->api_minor = status.api_minor;
+
+ trace_kvm_sev_init();
+ ret = sev_ioctl(s->sev_fd, KVM_SEV_INIT, NULL, &fw_error);
+ if (ret) {
+ error_report("%s: failed to initialize ret=%d fw_error=%d '%s'",
+ __func__, ret, fw_error, fw_error_to_str(fw_error));
+ goto err;
+ }
+
+ return s;
+err:
+ g_free(sev_state);
+ sev_state = NULL;
+ return NULL;
+}
+
static void
sev_register_types(void)
{
diff --git a/target/i386/sev_i386.h b/target/i386/sev_i386.h
index caf879c3b874..924cebcab02d 100644
--- a/target/i386/sev_i386.h
+++ b/target/i386/sev_i386.h
@@ -17,7 +17,9 @@
#include "qom/object.h"
#include "qapi/error.h"
#include "sysemu/kvm.h"
+#include "sysemu/sev.h"
#include "qemu/error-report.h"
+#include "qapi/qapi-commands-misc.h"
#define SEV_POLICY_NODBG 0x1
#define SEV_POLICY_NOKS 0x2
@@ -30,6 +32,12 @@
#define QSEV_GUEST_INFO(obj) \
OBJECT_CHECK(QSevGuestInfo, (obj), TYPE_QSEV_GUEST_INFO)
+extern bool sev_enabled(void);
+extern uint64_t sev_get_me_mask(void);
+extern SevInfo *sev_get_info(void);
+extern uint32_t sev_get_cbit_position(void);
+extern uint32_t sev_get_reduced_phys_bits(void);
+
typedef struct QSevGuestInfo QSevGuestInfo;
typedef struct QSevGuestInfoClass QSevGuestInfoClass;
@@ -58,4 +66,20 @@ struct QSevGuestInfoClass {
ObjectClass parent_class;
};
+struct SEVState {
+ QSevGuestInfo *sev_info;
+ uint8_t api_major;
+ uint8_t api_minor;
+ uint8_t build_id;
+ uint32_t policy;
+ uint64_t me_mask;
+ uint32_t cbitpos;
+ uint32_t reduced_phys_bits;
+ uint32_t handle;
+ int sev_fd;
+ SevState state;
+};
+
+typedef struct SEVState SEVState;
+
#endif
diff --git a/target/i386/trace-events b/target/i386/trace-events
index 3153fd445488..797b716751b7 100644
--- a/target/i386/trace-events
+++ b/target/i386/trace-events
@@ -5,3 +5,6 @@ kvm_x86_fixup_msi_error(uint32_t gsi) "VT-d failed to remap interrupt for GSI %"
kvm_x86_add_msi_route(int virq) "Adding route entry for virq %d"
kvm_x86_remove_msi_route(int virq) "Removing route entry for virq %d"
kvm_x86_update_msi_routes(int num) "Updated %d MSI routes"
+
+# target/i386/sev.c
+kvm_sev_init(void) ""
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH v12 12/28] sev/i386: register the guest memory range which may contain encrypted data
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
@ 2018-03-08 12:48 ` Brijesh Singh
-1 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:48 UTC (permalink / raw)
To: qemu-devel
Cc: Peter Maydell, Brijesh Singh, kvm, Michael S. Tsirkin,
Stefan Hajnoczi, Alexander Graf, Edgar E. Iglesias,
Markus Armbruster, Bruce Rogers, Christian Borntraeger,
Marcel Apfelbaum, Borislav Petkov, Thomas Lendacky,
Eduardo Habkost, Richard Henderson, Dr. David Alan Gilbert,
Alistair Francis, Cornelia Huck, Richard Henderson,
Peter Crosthwaite, Paolo Bonzini
When SEV is enabled, the hardware encryption engine uses a tweak such
that the two identical plaintext at different location will have a
different ciphertexts. So swapping or moving a ciphertexts of two guest
pages will not result in plaintexts being swapped. Hence relocating
a physical backing pages of the SEV guest will require some additional
steps in KVM driver. The KVM_MEMORY_ENCRYPT_{UN,}REG_REGION ioctl can be
used to register/unregister the guest memory region which may contain the
encrypted data. KVM driver will internally handle the relocating physical
backing pages of registered memory regions.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
target/i386/sev.c | 42 ++++++++++++++++++++++++++++++++++++++++++
target/i386/trace-events | 2 ++
2 files changed, 44 insertions(+)
diff --git a/target/i386/sev.c b/target/i386/sev.c
index 288612e1aa46..4f85035d5203 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -105,6 +105,46 @@ fw_error_to_str(int code)
return sev_fw_errlist[code];
}
+static void
+sev_ram_block_added(RAMBlockNotifier *n, void *host, size_t size)
+{
+ int r;
+ struct kvm_enc_region range;
+
+ range.addr = (__u64)host;
+ range.size = size;
+
+ trace_kvm_memcrypt_register_region(host, size);
+ r = kvm_vm_ioctl(kvm_state, KVM_MEMORY_ENCRYPT_REG_REGION, &range);
+ if (r) {
+ error_report("%s: failed to register region (%p+%#lx) error '%s'",
+ __func__, host, size, strerror(errno));
+ exit(1);
+ }
+}
+
+static void
+sev_ram_block_removed(RAMBlockNotifier *n, void *host, size_t size)
+{
+ int r;
+ struct kvm_enc_region range;
+
+ range.addr = (__u64)host;
+ range.size = size;
+
+ trace_kvm_memcrypt_unregister_region(host, size);
+ r = kvm_vm_ioctl(kvm_state, KVM_MEMORY_ENCRYPT_UNREG_REGION, &range);
+ if (r) {
+ error_report("%s: failed to unregister region (%p+%#lx)",
+ __func__, host, size);
+ }
+}
+
+static struct RAMBlockNotifier sev_ram_notifier = {
+ .ram_block_added = sev_ram_block_added,
+ .ram_block_removed = sev_ram_block_removed,
+};
+
static void
qsev_guest_finalize(Object *obj)
{
@@ -436,6 +476,8 @@ sev_guest_init(const char *id)
goto err;
}
+ ram_block_notifier_add(&sev_ram_notifier);
+
return s;
err:
g_free(sev_state);
diff --git a/target/i386/trace-events b/target/i386/trace-events
index 797b716751b7..ffa3d2250425 100644
--- a/target/i386/trace-events
+++ b/target/i386/trace-events
@@ -8,3 +8,5 @@ kvm_x86_update_msi_routes(int num) "Updated %d MSI routes"
# target/i386/sev.c
kvm_sev_init(void) ""
+kvm_memcrypt_register_region(void *addr, size_t len) "addr %p len 0x%lu"
+kvm_memcrypt_unregister_region(void *addr, size_t len) "addr %p len 0x%lu"
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [Qemu-devel] [PATCH v12 12/28] sev/i386: register the guest memory range which may contain encrypted data
@ 2018-03-08 12:48 ` Brijesh Singh
0 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:48 UTC (permalink / raw)
To: qemu-devel
Cc: Alistair Francis, Christian Borntraeger, Cornelia Huck,
Daniel P . Berrange, Dr. David Alan Gilbert, Michael S. Tsirkin,
Edgar E. Iglesias, Eduardo Habkost, Eric Blake, kvm,
Marcel Apfelbaum, Markus Armbruster, Paolo Bonzini,
Peter Crosthwaite, Peter Maydell, Richard Henderson,
Stefan Hajnoczi, Thomas Lendacky, Borislav Petkov,
Alexander Graf, Bruce Rogers, Brijesh Singh, Richard Henderson
When SEV is enabled, the hardware encryption engine uses a tweak such
that the two identical plaintext at different location will have a
different ciphertexts. So swapping or moving a ciphertexts of two guest
pages will not result in plaintexts being swapped. Hence relocating
a physical backing pages of the SEV guest will require some additional
steps in KVM driver. The KVM_MEMORY_ENCRYPT_{UN,}REG_REGION ioctl can be
used to register/unregister the guest memory region which may contain the
encrypted data. KVM driver will internally handle the relocating physical
backing pages of registered memory regions.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
target/i386/sev.c | 42 ++++++++++++++++++++++++++++++++++++++++++
target/i386/trace-events | 2 ++
2 files changed, 44 insertions(+)
diff --git a/target/i386/sev.c b/target/i386/sev.c
index 288612e1aa46..4f85035d5203 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -105,6 +105,46 @@ fw_error_to_str(int code)
return sev_fw_errlist[code];
}
+static void
+sev_ram_block_added(RAMBlockNotifier *n, void *host, size_t size)
+{
+ int r;
+ struct kvm_enc_region range;
+
+ range.addr = (__u64)host;
+ range.size = size;
+
+ trace_kvm_memcrypt_register_region(host, size);
+ r = kvm_vm_ioctl(kvm_state, KVM_MEMORY_ENCRYPT_REG_REGION, &range);
+ if (r) {
+ error_report("%s: failed to register region (%p+%#lx) error '%s'",
+ __func__, host, size, strerror(errno));
+ exit(1);
+ }
+}
+
+static void
+sev_ram_block_removed(RAMBlockNotifier *n, void *host, size_t size)
+{
+ int r;
+ struct kvm_enc_region range;
+
+ range.addr = (__u64)host;
+ range.size = size;
+
+ trace_kvm_memcrypt_unregister_region(host, size);
+ r = kvm_vm_ioctl(kvm_state, KVM_MEMORY_ENCRYPT_UNREG_REGION, &range);
+ if (r) {
+ error_report("%s: failed to unregister region (%p+%#lx)",
+ __func__, host, size);
+ }
+}
+
+static struct RAMBlockNotifier sev_ram_notifier = {
+ .ram_block_added = sev_ram_block_added,
+ .ram_block_removed = sev_ram_block_removed,
+};
+
static void
qsev_guest_finalize(Object *obj)
{
@@ -436,6 +476,8 @@ sev_guest_init(const char *id)
goto err;
}
+ ram_block_notifier_add(&sev_ram_notifier);
+
return s;
err:
g_free(sev_state);
diff --git a/target/i386/trace-events b/target/i386/trace-events
index 797b716751b7..ffa3d2250425 100644
--- a/target/i386/trace-events
+++ b/target/i386/trace-events
@@ -8,3 +8,5 @@ kvm_x86_update_msi_routes(int num) "Updated %d MSI routes"
# target/i386/sev.c
kvm_sev_init(void) ""
+kvm_memcrypt_register_region(void *addr, size_t len) "addr %p len 0x%lu"
+kvm_memcrypt_unregister_region(void *addr, size_t len) "addr %p len 0x%lu"
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH v12 13/28] kvm: introduce memory encryption APIs
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
@ 2018-03-08 12:48 ` Brijesh Singh
-1 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:48 UTC (permalink / raw)
To: qemu-devel
Cc: Peter Maydell, Brijesh Singh, kvm, Michael S. Tsirkin,
Stefan Hajnoczi, Alexander Graf, Edgar E. Iglesias,
Markus Armbruster, Bruce Rogers, Christian Borntraeger,
Marcel Apfelbaum, Borislav Petkov, Thomas Lendacky,
Eduardo Habkost, Richard Henderson, Dr. David Alan Gilbert,
Alistair Francis, Cornelia Huck, Peter Crosthwaite,
Paolo Bonzini
Inorder to integerate the Secure Encryption Virtualization (SEV) support
add few high-level memory encryption APIs which can be used for encrypting
the guest memory region.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: kvm@vger.kernel.org
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
accel/kvm/kvm-all.c | 30 ++++++++++++++++++++++++++++++
accel/stubs/kvm-stub.c | 14 ++++++++++++++
include/sysemu/kvm.h | 25 +++++++++++++++++++++++++
3 files changed, 69 insertions(+)
diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index a6473522be11..975ba3845234 100644
--- a/accel/kvm/kvm-all.c
+++ b/accel/kvm/kvm-all.c
@@ -107,6 +107,8 @@ struct KVMState
/* memory encryption */
void *memcrypt_handle;
+ int (*memcrypt_encrypt_data)(void *handle, uint8_t *ptr, uint64_t len);
+ void (*memcrypt_debug_ops)(void *handle, MemoryRegion *mr);
};
KVMState *kvm_state;
@@ -142,6 +144,34 @@ int kvm_get_max_memslots(void)
return s->nr_slots;
}
+bool kvm_memcrypt_enabled(void)
+{
+ if (kvm_state && kvm_state->memcrypt_handle) {
+ return true;
+ }
+
+ return false;
+}
+
+int kvm_memcrypt_encrypt_data(uint8_t *ptr, uint64_t len)
+{
+ if (kvm_state->memcrypt_handle &&
+ kvm_state->memcrypt_encrypt_data) {
+ return kvm_state->memcrypt_encrypt_data(kvm_state->memcrypt_handle,
+ ptr, len);
+ }
+
+ return 1;
+}
+
+void kvm_memcrypt_set_debug_ops(MemoryRegion *mr)
+{
+ if (kvm_state->memcrypt_handle &&
+ kvm_state->memcrypt_debug_ops) {
+ kvm_state->memcrypt_debug_ops(kvm_state->memcrypt_handle, mr);
+ }
+}
+
static KVMSlot *kvm_get_free_slot(KVMMemoryListener *kml)
{
KVMState *s = kvm_state;
diff --git a/accel/stubs/kvm-stub.c b/accel/stubs/kvm-stub.c
index c964af3e1c97..5739712a67e3 100644
--- a/accel/stubs/kvm-stub.c
+++ b/accel/stubs/kvm-stub.c
@@ -105,6 +105,20 @@ int kvm_on_sigbus(int code, void *addr)
return 1;
}
+bool kvm_memcrypt_enabled(void)
+{
+ return false;
+}
+
+int kvm_memcrypt_encrypt_data(uint8_t *ptr, uint64_t len)
+{
+ return 1;
+}
+
+void kvm_memcrypt_set_debug_ops(MemoryRegion *mr)
+{
+}
+
#ifndef CONFIG_USER_ONLY
int kvm_irqchip_add_msi_route(KVMState *s, int vector, PCIDevice *dev)
{
diff --git a/include/sysemu/kvm.h b/include/sysemu/kvm.h
index 85002ac49a54..d69bd1ff2b07 100644
--- a/include/sysemu/kvm.h
+++ b/include/sysemu/kvm.h
@@ -231,6 +231,31 @@ int kvm_destroy_vcpu(CPUState *cpu);
*/
bool kvm_arm_supports_user_irq(void);
+/**
+ * kvm_memcrypt_enabled - return boolean indicating whether memory encryption
+ * is enabled
+ * Returns: 1 memory encryption is enabled
+ * 0 memory encryption is disabled
+ */
+bool kvm_memcrypt_enabled(void);
+
+/**
+ * kvm_memcrypt_encrypt_data: encrypt the memory range
+ *
+ * Return: 1 failed to encrypt the range
+ * 0 succesfully encrypted memory region
+ */
+int kvm_memcrypt_encrypt_data(uint8_t *ptr, uint64_t len);
+
+/**
+ * kvm_memcrypt_set_debug_ram_ops: set debug_ram_ops callback
+ *
+ * When debug_ram_ops is set, debug access to this memory region will use
+ * memory encryption APIs.
+ */
+void kvm_memcrypt_set_debug_ops(MemoryRegion *mr);
+
+
#ifdef NEED_CPU_H
#include "cpu.h"
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [Qemu-devel] [PATCH v12 13/28] kvm: introduce memory encryption APIs
@ 2018-03-08 12:48 ` Brijesh Singh
0 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:48 UTC (permalink / raw)
To: qemu-devel
Cc: Alistair Francis, Christian Borntraeger, Cornelia Huck,
Daniel P . Berrange, Dr. David Alan Gilbert, Michael S. Tsirkin,
Edgar E. Iglesias, Eduardo Habkost, Eric Blake, kvm,
Marcel Apfelbaum, Markus Armbruster, Paolo Bonzini,
Peter Crosthwaite, Peter Maydell, Richard Henderson,
Stefan Hajnoczi, Thomas Lendacky, Borislav Petkov,
Alexander Graf, Bruce Rogers, Brijesh Singh
Inorder to integerate the Secure Encryption Virtualization (SEV) support
add few high-level memory encryption APIs which can be used for encrypting
the guest memory region.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: kvm@vger.kernel.org
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
accel/kvm/kvm-all.c | 30 ++++++++++++++++++++++++++++++
accel/stubs/kvm-stub.c | 14 ++++++++++++++
include/sysemu/kvm.h | 25 +++++++++++++++++++++++++
3 files changed, 69 insertions(+)
diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index a6473522be11..975ba3845234 100644
--- a/accel/kvm/kvm-all.c
+++ b/accel/kvm/kvm-all.c
@@ -107,6 +107,8 @@ struct KVMState
/* memory encryption */
void *memcrypt_handle;
+ int (*memcrypt_encrypt_data)(void *handle, uint8_t *ptr, uint64_t len);
+ void (*memcrypt_debug_ops)(void *handle, MemoryRegion *mr);
};
KVMState *kvm_state;
@@ -142,6 +144,34 @@ int kvm_get_max_memslots(void)
return s->nr_slots;
}
+bool kvm_memcrypt_enabled(void)
+{
+ if (kvm_state && kvm_state->memcrypt_handle) {
+ return true;
+ }
+
+ return false;
+}
+
+int kvm_memcrypt_encrypt_data(uint8_t *ptr, uint64_t len)
+{
+ if (kvm_state->memcrypt_handle &&
+ kvm_state->memcrypt_encrypt_data) {
+ return kvm_state->memcrypt_encrypt_data(kvm_state->memcrypt_handle,
+ ptr, len);
+ }
+
+ return 1;
+}
+
+void kvm_memcrypt_set_debug_ops(MemoryRegion *mr)
+{
+ if (kvm_state->memcrypt_handle &&
+ kvm_state->memcrypt_debug_ops) {
+ kvm_state->memcrypt_debug_ops(kvm_state->memcrypt_handle, mr);
+ }
+}
+
static KVMSlot *kvm_get_free_slot(KVMMemoryListener *kml)
{
KVMState *s = kvm_state;
diff --git a/accel/stubs/kvm-stub.c b/accel/stubs/kvm-stub.c
index c964af3e1c97..5739712a67e3 100644
--- a/accel/stubs/kvm-stub.c
+++ b/accel/stubs/kvm-stub.c
@@ -105,6 +105,20 @@ int kvm_on_sigbus(int code, void *addr)
return 1;
}
+bool kvm_memcrypt_enabled(void)
+{
+ return false;
+}
+
+int kvm_memcrypt_encrypt_data(uint8_t *ptr, uint64_t len)
+{
+ return 1;
+}
+
+void kvm_memcrypt_set_debug_ops(MemoryRegion *mr)
+{
+}
+
#ifndef CONFIG_USER_ONLY
int kvm_irqchip_add_msi_route(KVMState *s, int vector, PCIDevice *dev)
{
diff --git a/include/sysemu/kvm.h b/include/sysemu/kvm.h
index 85002ac49a54..d69bd1ff2b07 100644
--- a/include/sysemu/kvm.h
+++ b/include/sysemu/kvm.h
@@ -231,6 +231,31 @@ int kvm_destroy_vcpu(CPUState *cpu);
*/
bool kvm_arm_supports_user_irq(void);
+/**
+ * kvm_memcrypt_enabled - return boolean indicating whether memory encryption
+ * is enabled
+ * Returns: 1 memory encryption is enabled
+ * 0 memory encryption is disabled
+ */
+bool kvm_memcrypt_enabled(void);
+
+/**
+ * kvm_memcrypt_encrypt_data: encrypt the memory range
+ *
+ * Return: 1 failed to encrypt the range
+ * 0 succesfully encrypted memory region
+ */
+int kvm_memcrypt_encrypt_data(uint8_t *ptr, uint64_t len);
+
+/**
+ * kvm_memcrypt_set_debug_ram_ops: set debug_ram_ops callback
+ *
+ * When debug_ram_ops is set, debug access to this memory region will use
+ * memory encryption APIs.
+ */
+void kvm_memcrypt_set_debug_ops(MemoryRegion *mr);
+
+
#ifdef NEED_CPU_H
#include "cpu.h"
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH v12 14/28] hmp: add 'info sev' command
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
@ 2018-03-08 12:48 ` Brijesh Singh
-1 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:48 UTC (permalink / raw)
To: qemu-devel
Cc: Peter Maydell, Brijesh Singh, kvm, Michael S. Tsirkin,
Stefan Hajnoczi, Alexander Graf, Edgar E. Iglesias,
Markus Armbruster, Bruce Rogers, Christian Borntraeger,
Marcel Apfelbaum, Borislav Petkov, Thomas Lendacky,
Eduardo Habkost, Richard Henderson, Dr. David Alan Gilbert,
Alistair Francis, Cornelia Huck, Peter Crosthwaite,
Paolo Bonzini
The command can be used to show the SEV information when memory
encryption is enabled on AMD platform.
Cc: Eric Blake <eblake@redhat.com>
Cc: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: Markus Armbruster <armbru@redhat.com>
Reviewed-by: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
hmp-commands-info.hx | 16 ++++++++++++++++
hmp.h | 1 +
target/i386/monitor.c | 20 ++++++++++++++++++++
3 files changed, 37 insertions(+)
diff --git a/hmp-commands-info.hx b/hmp-commands-info.hx
index ad590a4ffb2b..ddfcd5adcca6 100644
--- a/hmp-commands-info.hx
+++ b/hmp-commands-info.hx
@@ -867,6 +867,22 @@ Display the amount of initially allocated and present hotpluggable (if
enabled) memory in bytes.
ETEXI
+#if defined(TARGET_I386)
+ {
+ .name = "sev",
+ .args_type = "",
+ .params = "",
+ .help = "show SEV information",
+ .cmd = hmp_info_sev,
+ },
+#endif
+
+STEXI
+@item info sev
+@findex info sev
+Show SEV information.
+ETEXI
+
STEXI
@end table
ETEXI
diff --git a/hmp.h b/hmp.h
index b89733876de1..4e2ec375b0f4 100644
--- a/hmp.h
+++ b/hmp.h
@@ -143,5 +143,6 @@ void hmp_info_ramblock(Monitor *mon, const QDict *qdict);
void hmp_hotpluggable_cpus(Monitor *mon, const QDict *qdict);
void hmp_info_vm_generation_id(Monitor *mon, const QDict *qdict);
void hmp_info_memory_size_summary(Monitor *mon, const QDict *qdict);
+void hmp_info_sev(Monitor *mon, const QDict *qdict);
#endif
diff --git a/target/i386/monitor.c b/target/i386/monitor.c
index 29de61996371..4d9019626031 100644
--- a/target/i386/monitor.c
+++ b/target/i386/monitor.c
@@ -29,6 +29,7 @@
#include "qapi/qmp/qdict.h"
#include "hw/i386/pc.h"
#include "sysemu/kvm.h"
+#include "sysemu/sev.h"
#include "hmp.h"
#include "sev_i386.h"
#include "qapi/qapi-commands-misc.h"
@@ -680,3 +681,22 @@ SevInfo *qmp_query_sev(Error **errp)
return info;
}
+
+void hmp_info_sev(Monitor *mon, const QDict *qdict)
+{
+ SevInfo *info = sev_get_info();
+
+ if (info && info->enabled) {
+ monitor_printf(mon, "handle: %d\n", info->handle);
+ monitor_printf(mon, "state: %s\n", SevState_str(info->state));
+ monitor_printf(mon, "build: %d\n", info->build_id);
+ monitor_printf(mon, "api version: %d.%d\n",
+ info->api_major, info->api_minor);
+ monitor_printf(mon, "debug: %s\n",
+ info->policy & SEV_POLICY_NODBG ? "off" : "on");
+ monitor_printf(mon, "key-sharing: %s\n",
+ info->policy & SEV_POLICY_NOKS ? "off" : "on");
+ } else {
+ monitor_printf(mon, "SEV is not enabled\n");
+ }
+}
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [Qemu-devel] [PATCH v12 14/28] hmp: add 'info sev' command
@ 2018-03-08 12:48 ` Brijesh Singh
0 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:48 UTC (permalink / raw)
To: qemu-devel
Cc: Alistair Francis, Christian Borntraeger, Cornelia Huck,
Daniel P . Berrange, Dr. David Alan Gilbert, Michael S. Tsirkin,
Edgar E. Iglesias, Eduardo Habkost, Eric Blake, kvm,
Marcel Apfelbaum, Markus Armbruster, Paolo Bonzini,
Peter Crosthwaite, Peter Maydell, Richard Henderson,
Stefan Hajnoczi, Thomas Lendacky, Borislav Petkov,
Alexander Graf, Bruce Rogers, Brijesh Singh
The command can be used to show the SEV information when memory
encryption is enabled on AMD platform.
Cc: Eric Blake <eblake@redhat.com>
Cc: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: Markus Armbruster <armbru@redhat.com>
Reviewed-by: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
hmp-commands-info.hx | 16 ++++++++++++++++
hmp.h | 1 +
target/i386/monitor.c | 20 ++++++++++++++++++++
3 files changed, 37 insertions(+)
diff --git a/hmp-commands-info.hx b/hmp-commands-info.hx
index ad590a4ffb2b..ddfcd5adcca6 100644
--- a/hmp-commands-info.hx
+++ b/hmp-commands-info.hx
@@ -867,6 +867,22 @@ Display the amount of initially allocated and present hotpluggable (if
enabled) memory in bytes.
ETEXI
+#if defined(TARGET_I386)
+ {
+ .name = "sev",
+ .args_type = "",
+ .params = "",
+ .help = "show SEV information",
+ .cmd = hmp_info_sev,
+ },
+#endif
+
+STEXI
+@item info sev
+@findex info sev
+Show SEV information.
+ETEXI
+
STEXI
@end table
ETEXI
diff --git a/hmp.h b/hmp.h
index b89733876de1..4e2ec375b0f4 100644
--- a/hmp.h
+++ b/hmp.h
@@ -143,5 +143,6 @@ void hmp_info_ramblock(Monitor *mon, const QDict *qdict);
void hmp_hotpluggable_cpus(Monitor *mon, const QDict *qdict);
void hmp_info_vm_generation_id(Monitor *mon, const QDict *qdict);
void hmp_info_memory_size_summary(Monitor *mon, const QDict *qdict);
+void hmp_info_sev(Monitor *mon, const QDict *qdict);
#endif
diff --git a/target/i386/monitor.c b/target/i386/monitor.c
index 29de61996371..4d9019626031 100644
--- a/target/i386/monitor.c
+++ b/target/i386/monitor.c
@@ -29,6 +29,7 @@
#include "qapi/qmp/qdict.h"
#include "hw/i386/pc.h"
#include "sysemu/kvm.h"
+#include "sysemu/sev.h"
#include "hmp.h"
#include "sev_i386.h"
#include "qapi/qapi-commands-misc.h"
@@ -680,3 +681,22 @@ SevInfo *qmp_query_sev(Error **errp)
return info;
}
+
+void hmp_info_sev(Monitor *mon, const QDict *qdict)
+{
+ SevInfo *info = sev_get_info();
+
+ if (info && info->enabled) {
+ monitor_printf(mon, "handle: %d\n", info->handle);
+ monitor_printf(mon, "state: %s\n", SevState_str(info->state));
+ monitor_printf(mon, "build: %d\n", info->build_id);
+ monitor_printf(mon, "api version: %d.%d\n",
+ info->api_major, info->api_minor);
+ monitor_printf(mon, "debug: %s\n",
+ info->policy & SEV_POLICY_NODBG ? "off" : "on");
+ monitor_printf(mon, "key-sharing: %s\n",
+ info->policy & SEV_POLICY_NOKS ? "off" : "on");
+ } else {
+ monitor_printf(mon, "SEV is not enabled\n");
+ }
+}
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH v12 15/28] sev/i386: add command to create launch memory encryption context
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
@ 2018-03-08 12:48 ` Brijesh Singh
-1 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:48 UTC (permalink / raw)
To: qemu-devel
Cc: Peter Maydell, Brijesh Singh, kvm, Michael S. Tsirkin,
Stefan Hajnoczi, Alexander Graf, Edgar E. Iglesias,
Markus Armbruster, Bruce Rogers, Christian Borntraeger,
Marcel Apfelbaum, Borislav Petkov, Thomas Lendacky,
Eduardo Habkost, Richard Henderson, Dr. David Alan Gilbert,
Alistair Francis, Cornelia Huck, Richard Henderson,
Peter Crosthwaite, Paolo Bonzini
The KVM_SEV_LAUNCH_START command creates a new VM encryption key (VEK).
The encryption key created with the command will be used for encrypting
the bootstrap images (such as guest bios).
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
target/i386/sev.c | 86 ++++++++++++++++++++++++++++++++++++++++++++++++
target/i386/trace-events | 2 ++
2 files changed, 88 insertions(+)
diff --git a/target/i386/sev.c b/target/i386/sev.c
index 4f85035d5203..eee693745103 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -105,6 +105,17 @@ fw_error_to_str(int code)
return sev_fw_errlist[code];
}
+static void
+sev_set_guest_state(SevState new_state)
+{
+ assert(new_state < SEV_STATE__MAX);
+ assert(sev_state);
+
+ trace_kvm_sev_change_state(SevState_str(sev_state->state),
+ SevState_str(new_state));
+ sev_state->state = new_state;
+}
+
static void
sev_ram_block_added(RAMBlockNotifier *n, void *host, size_t size)
{
@@ -406,6 +417,75 @@ sev_get_info(void)
return info;
}
+static int
+sev_read_file_base64(const char *filename, guchar **data, gsize *len)
+{
+ gsize sz;
+ gchar *base64;
+ GError *error = NULL;
+
+ if (!g_file_get_contents(filename, &base64, &sz, &error)) {
+ error_report("failed to read '%s' (%s)", filename, error->message);
+ return -1;
+ }
+
+ *data = g_base64_decode(base64, len);
+ return 0;
+}
+
+static int
+sev_launch_start(SEVState *s)
+{
+ gsize sz;
+ int ret = 1;
+ int fw_error;
+ QSevGuestInfo *sev = s->sev_info;
+ struct kvm_sev_launch_start *start;
+ guchar *session = NULL, *dh_cert = NULL;
+
+ start = g_new0(struct kvm_sev_launch_start, 1);
+
+ start->handle = object_property_get_int(OBJECT(sev), "handle",
+ &error_abort);
+ start->policy = object_property_get_int(OBJECT(sev), "policy",
+ &error_abort);
+ if (sev->session_file) {
+ if (sev_read_file_base64(sev->session_file, &session, &sz) < 0) {
+ return 1;
+ }
+ start->session_uaddr = (unsigned long)session;
+ start->session_len = sz;
+ }
+
+ if (sev->dh_cert_file) {
+ if (sev_read_file_base64(sev->dh_cert_file, &dh_cert, &sz) < 0) {
+ return 1;
+ }
+ start->dh_uaddr = (unsigned long)dh_cert;
+ start->dh_len = sz;
+ }
+
+ trace_kvm_sev_launch_start(start->policy, session, dh_cert);
+ ret = sev_ioctl(s->sev_fd, KVM_SEV_LAUNCH_START, start, &fw_error);
+ if (ret < 0) {
+ error_report("%s: LAUNCH_START ret=%d fw_error=%d '%s'",
+ __func__, ret, fw_error, fw_error_to_str(fw_error));
+ return 1;
+ }
+
+ object_property_set_int(OBJECT(sev), start->handle, "handle",
+ &error_abort);
+ sev_set_guest_state(SEV_STATE_LUPDATE);
+ s->handle = start->handle;
+ s->policy = start->policy;
+
+ g_free(start);
+ g_free(session);
+ g_free(dh_cert);
+
+ return 0;
+}
+
void *
sev_guest_init(const char *id)
{
@@ -476,6 +556,12 @@ sev_guest_init(const char *id)
goto err;
}
+ ret = sev_launch_start(s);
+ if (ret) {
+ error_report("%s: failed to create encryption context", __func__);
+ goto err;
+ }
+
ram_block_notifier_add(&sev_ram_notifier);
return s;
diff --git a/target/i386/trace-events b/target/i386/trace-events
index ffa3d2250425..9402251e9991 100644
--- a/target/i386/trace-events
+++ b/target/i386/trace-events
@@ -10,3 +10,5 @@ kvm_x86_update_msi_routes(int num) "Updated %d MSI routes"
kvm_sev_init(void) ""
kvm_memcrypt_register_region(void *addr, size_t len) "addr %p len 0x%lu"
kvm_memcrypt_unregister_region(void *addr, size_t len) "addr %p len 0x%lu"
+kvm_sev_change_state(const char *old, const char *new) "%s -> %s"
+kvm_sev_launch_start(int policy, void *session, void *pdh) "policy 0x%x session %p pdh %p"
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [Qemu-devel] [PATCH v12 15/28] sev/i386: add command to create launch memory encryption context
@ 2018-03-08 12:48 ` Brijesh Singh
0 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:48 UTC (permalink / raw)
To: qemu-devel
Cc: Alistair Francis, Christian Borntraeger, Cornelia Huck,
Daniel P . Berrange, Dr. David Alan Gilbert, Michael S. Tsirkin,
Edgar E. Iglesias, Eduardo Habkost, Eric Blake, kvm,
Marcel Apfelbaum, Markus Armbruster, Paolo Bonzini,
Peter Crosthwaite, Peter Maydell, Richard Henderson,
Stefan Hajnoczi, Thomas Lendacky, Borislav Petkov,
Alexander Graf, Bruce Rogers, Brijesh Singh, Richard Henderson
The KVM_SEV_LAUNCH_START command creates a new VM encryption key (VEK).
The encryption key created with the command will be used for encrypting
the bootstrap images (such as guest bios).
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
target/i386/sev.c | 86 ++++++++++++++++++++++++++++++++++++++++++++++++
target/i386/trace-events | 2 ++
2 files changed, 88 insertions(+)
diff --git a/target/i386/sev.c b/target/i386/sev.c
index 4f85035d5203..eee693745103 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -105,6 +105,17 @@ fw_error_to_str(int code)
return sev_fw_errlist[code];
}
+static void
+sev_set_guest_state(SevState new_state)
+{
+ assert(new_state < SEV_STATE__MAX);
+ assert(sev_state);
+
+ trace_kvm_sev_change_state(SevState_str(sev_state->state),
+ SevState_str(new_state));
+ sev_state->state = new_state;
+}
+
static void
sev_ram_block_added(RAMBlockNotifier *n, void *host, size_t size)
{
@@ -406,6 +417,75 @@ sev_get_info(void)
return info;
}
+static int
+sev_read_file_base64(const char *filename, guchar **data, gsize *len)
+{
+ gsize sz;
+ gchar *base64;
+ GError *error = NULL;
+
+ if (!g_file_get_contents(filename, &base64, &sz, &error)) {
+ error_report("failed to read '%s' (%s)", filename, error->message);
+ return -1;
+ }
+
+ *data = g_base64_decode(base64, len);
+ return 0;
+}
+
+static int
+sev_launch_start(SEVState *s)
+{
+ gsize sz;
+ int ret = 1;
+ int fw_error;
+ QSevGuestInfo *sev = s->sev_info;
+ struct kvm_sev_launch_start *start;
+ guchar *session = NULL, *dh_cert = NULL;
+
+ start = g_new0(struct kvm_sev_launch_start, 1);
+
+ start->handle = object_property_get_int(OBJECT(sev), "handle",
+ &error_abort);
+ start->policy = object_property_get_int(OBJECT(sev), "policy",
+ &error_abort);
+ if (sev->session_file) {
+ if (sev_read_file_base64(sev->session_file, &session, &sz) < 0) {
+ return 1;
+ }
+ start->session_uaddr = (unsigned long)session;
+ start->session_len = sz;
+ }
+
+ if (sev->dh_cert_file) {
+ if (sev_read_file_base64(sev->dh_cert_file, &dh_cert, &sz) < 0) {
+ return 1;
+ }
+ start->dh_uaddr = (unsigned long)dh_cert;
+ start->dh_len = sz;
+ }
+
+ trace_kvm_sev_launch_start(start->policy, session, dh_cert);
+ ret = sev_ioctl(s->sev_fd, KVM_SEV_LAUNCH_START, start, &fw_error);
+ if (ret < 0) {
+ error_report("%s: LAUNCH_START ret=%d fw_error=%d '%s'",
+ __func__, ret, fw_error, fw_error_to_str(fw_error));
+ return 1;
+ }
+
+ object_property_set_int(OBJECT(sev), start->handle, "handle",
+ &error_abort);
+ sev_set_guest_state(SEV_STATE_LUPDATE);
+ s->handle = start->handle;
+ s->policy = start->policy;
+
+ g_free(start);
+ g_free(session);
+ g_free(dh_cert);
+
+ return 0;
+}
+
void *
sev_guest_init(const char *id)
{
@@ -476,6 +556,12 @@ sev_guest_init(const char *id)
goto err;
}
+ ret = sev_launch_start(s);
+ if (ret) {
+ error_report("%s: failed to create encryption context", __func__);
+ goto err;
+ }
+
ram_block_notifier_add(&sev_ram_notifier);
return s;
diff --git a/target/i386/trace-events b/target/i386/trace-events
index ffa3d2250425..9402251e9991 100644
--- a/target/i386/trace-events
+++ b/target/i386/trace-events
@@ -10,3 +10,5 @@ kvm_x86_update_msi_routes(int num) "Updated %d MSI routes"
kvm_sev_init(void) ""
kvm_memcrypt_register_region(void *addr, size_t len) "addr %p len 0x%lu"
kvm_memcrypt_unregister_region(void *addr, size_t len) "addr %p len 0x%lu"
+kvm_sev_change_state(const char *old, const char *new) "%s -> %s"
+kvm_sev_launch_start(int policy, void *session, void *pdh) "policy 0x%x session %p pdh %p"
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH v12 16/28] sev/i386: add command to encrypt guest memory region
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
@ 2018-03-08 12:48 ` Brijesh Singh
-1 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:48 UTC (permalink / raw)
To: qemu-devel
Cc: Peter Maydell, Brijesh Singh, kvm, Michael S. Tsirkin,
Stefan Hajnoczi, Alexander Graf, Edgar E. Iglesias,
Markus Armbruster, Bruce Rogers, Christian Borntraeger,
Marcel Apfelbaum, Borislav Petkov, Thomas Lendacky,
Eduardo Habkost, Richard Henderson, Dr. David Alan Gilbert,
Alistair Francis, Cornelia Huck, Richard Henderson,
Peter Crosthwaite, Paolo Bonzini
The KVM_SEV_LAUNCH_UPDATE_DATA command is used to encrypt a guest memory
region using the VM Encryption Key created using LAUNCH_START.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
accel/kvm/kvm-all.c | 2 ++
stubs/sev.c | 5 +++++
target/i386/sev.c | 43 +++++++++++++++++++++++++++++++++++++++++++
target/i386/trace-events | 1 +
4 files changed, 51 insertions(+)
diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index 975ba3845234..411aa87719e6 100644
--- a/accel/kvm/kvm-all.c
+++ b/accel/kvm/kvm-all.c
@@ -1680,6 +1680,8 @@ static int kvm_init(MachineState *ms)
ret = -1;
goto err;
}
+
+ kvm_state->memcrypt_encrypt_data = sev_encrypt_data;
}
ret = kvm_arch_init(ms, s);
diff --git a/stubs/sev.c b/stubs/sev.c
index 4a5cc5569e5f..2e20f3b73a5b 100644
--- a/stubs/sev.c
+++ b/stubs/sev.c
@@ -15,6 +15,11 @@
#include "qemu-common.h"
#include "sysemu/sev.h"
+int sev_encrypt_data(void *handle, uint8_t *ptr, uint64_t len)
+{
+ return 1;
+}
+
void *sev_guest_init(const char *id)
{
return NULL;
diff --git a/target/i386/sev.c b/target/i386/sev.c
index eee693745103..cb0bf84742ed 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -105,6 +105,13 @@ fw_error_to_str(int code)
return sev_fw_errlist[code];
}
+static bool
+sev_check_state(SevState state)
+{
+ assert(sev_state);
+ return sev_state->state == state ? true : false;
+}
+
static void
sev_set_guest_state(SevState new_state)
{
@@ -486,6 +493,29 @@ sev_launch_start(SEVState *s)
return 0;
}
+static int
+sev_launch_update_data(uint8_t *addr, uint64_t len)
+{
+ int ret, fw_error;
+ struct kvm_sev_launch_update_data update;
+
+ if (!addr || !len) {
+ return 1;
+ }
+
+ update.uaddr = (__u64)addr;
+ update.len = len;
+ trace_kvm_sev_launch_update_data(addr, len);
+ ret = sev_ioctl(sev_state->sev_fd, KVM_SEV_LAUNCH_UPDATE_DATA,
+ &update, &fw_error);
+ if (ret) {
+ error_report("%s: LAUNCH_UPDATE ret=%d fw_error=%d '%s'",
+ __func__, ret, fw_error, fw_error_to_str(fw_error));
+ }
+
+ return ret;
+}
+
void *
sev_guest_init(const char *id)
{
@@ -571,6 +601,19 @@ err:
return NULL;
}
+int
+sev_encrypt_data(void *handle, uint8_t *ptr, uint64_t len)
+{
+ assert(handle);
+
+ /* if SEV is in update state then encrypt the data else do nothing */
+ if (sev_check_state(SEV_STATE_LUPDATE)) {
+ return sev_launch_update_data(ptr, len);
+ }
+
+ return 0;
+}
+
static void
sev_register_types(void)
{
diff --git a/target/i386/trace-events b/target/i386/trace-events
index 9402251e9991..c0cd8e93217f 100644
--- a/target/i386/trace-events
+++ b/target/i386/trace-events
@@ -12,3 +12,4 @@ kvm_memcrypt_register_region(void *addr, size_t len) "addr %p len 0x%lu"
kvm_memcrypt_unregister_region(void *addr, size_t len) "addr %p len 0x%lu"
kvm_sev_change_state(const char *old, const char *new) "%s -> %s"
kvm_sev_launch_start(int policy, void *session, void *pdh) "policy 0x%x session %p pdh %p"
+kvm_sev_launch_update_data(void *addr, uint64_t len) "addr %p len 0x%" PRIu64
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [Qemu-devel] [PATCH v12 16/28] sev/i386: add command to encrypt guest memory region
@ 2018-03-08 12:48 ` Brijesh Singh
0 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:48 UTC (permalink / raw)
To: qemu-devel
Cc: Alistair Francis, Christian Borntraeger, Cornelia Huck,
Daniel P . Berrange, Dr. David Alan Gilbert, Michael S. Tsirkin,
Edgar E. Iglesias, Eduardo Habkost, Eric Blake, kvm,
Marcel Apfelbaum, Markus Armbruster, Paolo Bonzini,
Peter Crosthwaite, Peter Maydell, Richard Henderson,
Stefan Hajnoczi, Thomas Lendacky, Borislav Petkov,
Alexander Graf, Bruce Rogers, Brijesh Singh, Richard Henderson
The KVM_SEV_LAUNCH_UPDATE_DATA command is used to encrypt a guest memory
region using the VM Encryption Key created using LAUNCH_START.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
accel/kvm/kvm-all.c | 2 ++
stubs/sev.c | 5 +++++
target/i386/sev.c | 43 +++++++++++++++++++++++++++++++++++++++++++
target/i386/trace-events | 1 +
4 files changed, 51 insertions(+)
diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index 975ba3845234..411aa87719e6 100644
--- a/accel/kvm/kvm-all.c
+++ b/accel/kvm/kvm-all.c
@@ -1680,6 +1680,8 @@ static int kvm_init(MachineState *ms)
ret = -1;
goto err;
}
+
+ kvm_state->memcrypt_encrypt_data = sev_encrypt_data;
}
ret = kvm_arch_init(ms, s);
diff --git a/stubs/sev.c b/stubs/sev.c
index 4a5cc5569e5f..2e20f3b73a5b 100644
--- a/stubs/sev.c
+++ b/stubs/sev.c
@@ -15,6 +15,11 @@
#include "qemu-common.h"
#include "sysemu/sev.h"
+int sev_encrypt_data(void *handle, uint8_t *ptr, uint64_t len)
+{
+ return 1;
+}
+
void *sev_guest_init(const char *id)
{
return NULL;
diff --git a/target/i386/sev.c b/target/i386/sev.c
index eee693745103..cb0bf84742ed 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -105,6 +105,13 @@ fw_error_to_str(int code)
return sev_fw_errlist[code];
}
+static bool
+sev_check_state(SevState state)
+{
+ assert(sev_state);
+ return sev_state->state == state ? true : false;
+}
+
static void
sev_set_guest_state(SevState new_state)
{
@@ -486,6 +493,29 @@ sev_launch_start(SEVState *s)
return 0;
}
+static int
+sev_launch_update_data(uint8_t *addr, uint64_t len)
+{
+ int ret, fw_error;
+ struct kvm_sev_launch_update_data update;
+
+ if (!addr || !len) {
+ return 1;
+ }
+
+ update.uaddr = (__u64)addr;
+ update.len = len;
+ trace_kvm_sev_launch_update_data(addr, len);
+ ret = sev_ioctl(sev_state->sev_fd, KVM_SEV_LAUNCH_UPDATE_DATA,
+ &update, &fw_error);
+ if (ret) {
+ error_report("%s: LAUNCH_UPDATE ret=%d fw_error=%d '%s'",
+ __func__, ret, fw_error, fw_error_to_str(fw_error));
+ }
+
+ return ret;
+}
+
void *
sev_guest_init(const char *id)
{
@@ -571,6 +601,19 @@ err:
return NULL;
}
+int
+sev_encrypt_data(void *handle, uint8_t *ptr, uint64_t len)
+{
+ assert(handle);
+
+ /* if SEV is in update state then encrypt the data else do nothing */
+ if (sev_check_state(SEV_STATE_LUPDATE)) {
+ return sev_launch_update_data(ptr, len);
+ }
+
+ return 0;
+}
+
static void
sev_register_types(void)
{
diff --git a/target/i386/trace-events b/target/i386/trace-events
index 9402251e9991..c0cd8e93217f 100644
--- a/target/i386/trace-events
+++ b/target/i386/trace-events
@@ -12,3 +12,4 @@ kvm_memcrypt_register_region(void *addr, size_t len) "addr %p len 0x%lu"
kvm_memcrypt_unregister_region(void *addr, size_t len) "addr %p len 0x%lu"
kvm_sev_change_state(const char *old, const char *new) "%s -> %s"
kvm_sev_launch_start(int policy, void *session, void *pdh) "policy 0x%x session %p pdh %p"
+kvm_sev_launch_update_data(void *addr, uint64_t len) "addr %p len 0x%" PRIu64
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH v12 17/28] target/i386: encrypt bios rom
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
@ 2018-03-08 12:48 ` Brijesh Singh
-1 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:48 UTC (permalink / raw)
To: qemu-devel
Cc: Peter Maydell, Brijesh Singh, kvm, Michael S. Tsirkin,
Stefan Hajnoczi, Alexander Graf, Edgar E. Iglesias,
Markus Armbruster, Bruce Rogers, Christian Borntraeger,
Marcel Apfelbaum, Borislav Petkov, Thomas Lendacky,
Eduardo Habkost, Richard Henderson, Dr. David Alan Gilbert,
Alistair Francis, Cornelia Huck, Richard Henderson,
Peter Crosthwaite, Paolo Bonzini
SEV requires that guest bios must be encrypted before booting the guest.
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
hw/i386/pc_sysfw.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/hw/i386/pc_sysfw.c b/hw/i386/pc_sysfw.c
index 4325575e7d82..73ac783f2055 100644
--- a/hw/i386/pc_sysfw.c
+++ b/hw/i386/pc_sysfw.c
@@ -113,6 +113,8 @@ static void pc_system_flash_init(MemoryRegion *rom_memory)
pflash_t *system_flash;
MemoryRegion *flash_mem;
char name[64];
+ void *flash_ptr;
+ int ret, flash_size;
sector_bits = 12;
sector_size = 1 << sector_bits;
@@ -169,6 +171,17 @@ static void pc_system_flash_init(MemoryRegion *rom_memory)
if (unit == 0) {
flash_mem = pflash_cfi01_get_memory(system_flash);
pc_isa_bios_init(rom_memory, flash_mem, size);
+
+ /* Encrypt the pflash boot ROM */
+ if (kvm_memcrypt_enabled()) {
+ flash_ptr = memory_region_get_ram_ptr(flash_mem);
+ flash_size = memory_region_size(flash_mem);
+ ret = kvm_memcrypt_encrypt_data(flash_ptr, flash_size);
+ if (ret) {
+ error_report("failed to encrypt pflash rom");
+ exit(1);
+ }
+ }
}
}
}
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [Qemu-devel] [PATCH v12 17/28] target/i386: encrypt bios rom
@ 2018-03-08 12:48 ` Brijesh Singh
0 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:48 UTC (permalink / raw)
To: qemu-devel
Cc: Alistair Francis, Christian Borntraeger, Cornelia Huck,
Daniel P . Berrange, Dr. David Alan Gilbert, Michael S. Tsirkin,
Edgar E. Iglesias, Eduardo Habkost, Eric Blake, kvm,
Marcel Apfelbaum, Markus Armbruster, Paolo Bonzini,
Peter Crosthwaite, Peter Maydell, Richard Henderson,
Stefan Hajnoczi, Thomas Lendacky, Borislav Petkov,
Alexander Graf, Bruce Rogers, Brijesh Singh, Richard Henderson
SEV requires that guest bios must be encrypted before booting the guest.
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
hw/i386/pc_sysfw.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/hw/i386/pc_sysfw.c b/hw/i386/pc_sysfw.c
index 4325575e7d82..73ac783f2055 100644
--- a/hw/i386/pc_sysfw.c
+++ b/hw/i386/pc_sysfw.c
@@ -113,6 +113,8 @@ static void pc_system_flash_init(MemoryRegion *rom_memory)
pflash_t *system_flash;
MemoryRegion *flash_mem;
char name[64];
+ void *flash_ptr;
+ int ret, flash_size;
sector_bits = 12;
sector_size = 1 << sector_bits;
@@ -169,6 +171,17 @@ static void pc_system_flash_init(MemoryRegion *rom_memory)
if (unit == 0) {
flash_mem = pflash_cfi01_get_memory(system_flash);
pc_isa_bios_init(rom_memory, flash_mem, size);
+
+ /* Encrypt the pflash boot ROM */
+ if (kvm_memcrypt_enabled()) {
+ flash_ptr = memory_region_get_ram_ptr(flash_mem);
+ flash_size = memory_region_size(flash_mem);
+ ret = kvm_memcrypt_encrypt_data(flash_ptr, flash_size);
+ if (ret) {
+ error_report("failed to encrypt pflash rom");
+ exit(1);
+ }
+ }
}
}
}
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH v12 18/28] sev/i386: add support to LAUNCH_MEASURE command
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
@ 2018-03-08 12:48 ` Brijesh Singh
-1 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:48 UTC (permalink / raw)
To: qemu-devel
Cc: Peter Maydell, Brijesh Singh, kvm, Michael S. Tsirkin,
Stefan Hajnoczi, Alexander Graf, Edgar E. Iglesias,
Markus Armbruster, Bruce Rogers, Christian Borntraeger,
Marcel Apfelbaum, Borislav Petkov, Thomas Lendacky,
Eduardo Habkost, Richard Henderson, Dr. David Alan Gilbert,
Alistair Francis, Cornelia Huck, Richard Henderson,
Peter Crosthwaite, Paolo Bonzini
During machine creation we encrypted the guest bios image, the
LAUNCH_MEASURE command can be used to retrieve the measurement of
the encrypted memory region. This measurement is a signature of
the memory contents that can be sent to the guest owner as an
attestation that the memory was encrypted correctly by the firmware.
VM management tools like libvirt can query the measurement using
query-sev-launch-measure QMP command.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
target/i386/sev-stub.c | 5 ++++
target/i386/sev.c | 63 ++++++++++++++++++++++++++++++++++++++++++++++++
target/i386/sev_i386.h | 2 ++
target/i386/trace-events | 1 +
4 files changed, 71 insertions(+)
diff --git a/target/i386/sev-stub.c b/target/i386/sev-stub.c
index c86d8c139237..2f61c32ec975 100644
--- a/target/i386/sev-stub.c
+++ b/target/i386/sev-stub.c
@@ -39,3 +39,8 @@ uint32_t sev_get_reduced_phys_bits(void)
{
return 0;
}
+
+char *sev_get_launch_measurement(void)
+{
+ return NULL;
+}
diff --git a/target/i386/sev.c b/target/i386/sev.c
index cb0bf84742ed..7ad7eaf600a7 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -516,6 +516,68 @@ sev_launch_update_data(uint8_t *addr, uint64_t len)
return ret;
}
+static void
+sev_launch_get_measure(Notifier *notifier, void *unused)
+{
+ int ret, error;
+ guchar *data;
+ SEVState *s = sev_state;
+ struct kvm_sev_launch_measure *measurement;
+
+ if (!sev_check_state(SEV_STATE_LUPDATE)) {
+ return;
+ }
+
+ measurement = g_new0(struct kvm_sev_launch_measure, 1);
+
+ /* query the measurement blob length */
+ ret = sev_ioctl(sev_state->sev_fd, KVM_SEV_LAUNCH_MEASURE,
+ measurement, &error);
+ if (!measurement->len) {
+ error_report("%s: LAUNCH_MEASURE ret=%d fw_error=%d '%s'",
+ __func__, ret, error, fw_error_to_str(errno));
+ goto free_measurement;
+ }
+
+ data = g_new0(guchar, measurement->len);
+ measurement->uaddr = (unsigned long)data;
+
+ /* get the measurement blob */
+ ret = sev_ioctl(sev_state->sev_fd, KVM_SEV_LAUNCH_MEASURE,
+ measurement, &error);
+ if (ret) {
+ error_report("%s: LAUNCH_MEASURE ret=%d fw_error=%d '%s'",
+ __func__, ret, error, fw_error_to_str(errno));
+ goto free_data;
+ }
+
+ sev_set_guest_state(SEV_STATE_LSECRET);
+
+ /* encode the measurement value and emit the event */
+ s->measurement = g_base64_encode(data, measurement->len);
+ trace_kvm_sev_launch_measurement(s->measurement);
+
+free_data:
+ g_free(data);
+free_measurement:
+ g_free(measurement);
+}
+
+char *
+sev_get_launch_measurement(void)
+{
+ if (sev_state &&
+ sev_state->state >= SEV_STATE_LSECRET) {
+ return g_strdup(sev_state->measurement);
+ }
+
+ return NULL;
+}
+
+static Notifier sev_machine_done_notify = {
+ .notify = sev_launch_get_measure,
+};
+
void *
sev_guest_init(const char *id)
{
@@ -593,6 +655,7 @@ sev_guest_init(const char *id)
}
ram_block_notifier_add(&sev_ram_notifier);
+ qemu_add_machine_init_done_notifier(&sev_machine_done_notify);
return s;
err:
diff --git a/target/i386/sev_i386.h b/target/i386/sev_i386.h
index 924cebcab02d..6e370775770e 100644
--- a/target/i386/sev_i386.h
+++ b/target/i386/sev_i386.h
@@ -37,6 +37,7 @@ extern uint64_t sev_get_me_mask(void);
extern SevInfo *sev_get_info(void);
extern uint32_t sev_get_cbit_position(void);
extern uint32_t sev_get_reduced_phys_bits(void);
+extern char *sev_get_launch_measurement(void);
typedef struct QSevGuestInfo QSevGuestInfo;
typedef struct QSevGuestInfoClass QSevGuestInfoClass;
@@ -78,6 +79,7 @@ struct SEVState {
uint32_t handle;
int sev_fd;
SevState state;
+ gchar *measurement;
};
typedef struct SEVState SEVState;
diff --git a/target/i386/trace-events b/target/i386/trace-events
index c0cd8e93217f..f7a1a1e6b85c 100644
--- a/target/i386/trace-events
+++ b/target/i386/trace-events
@@ -13,3 +13,4 @@ kvm_memcrypt_unregister_region(void *addr, size_t len) "addr %p len 0x%lu"
kvm_sev_change_state(const char *old, const char *new) "%s -> %s"
kvm_sev_launch_start(int policy, void *session, void *pdh) "policy 0x%x session %p pdh %p"
kvm_sev_launch_update_data(void *addr, uint64_t len) "addr %p len 0x%" PRIu64
+kvm_sev_launch_measurement(const char *value) "data %s"
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [Qemu-devel] [PATCH v12 18/28] sev/i386: add support to LAUNCH_MEASURE command
@ 2018-03-08 12:48 ` Brijesh Singh
0 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:48 UTC (permalink / raw)
To: qemu-devel
Cc: Alistair Francis, Christian Borntraeger, Cornelia Huck,
Daniel P . Berrange, Dr. David Alan Gilbert, Michael S. Tsirkin,
Edgar E. Iglesias, Eduardo Habkost, Eric Blake, kvm,
Marcel Apfelbaum, Markus Armbruster, Paolo Bonzini,
Peter Crosthwaite, Peter Maydell, Richard Henderson,
Stefan Hajnoczi, Thomas Lendacky, Borislav Petkov,
Alexander Graf, Bruce Rogers, Brijesh Singh, Richard Henderson
During machine creation we encrypted the guest bios image, the
LAUNCH_MEASURE command can be used to retrieve the measurement of
the encrypted memory region. This measurement is a signature of
the memory contents that can be sent to the guest owner as an
attestation that the memory was encrypted correctly by the firmware.
VM management tools like libvirt can query the measurement using
query-sev-launch-measure QMP command.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
target/i386/sev-stub.c | 5 ++++
target/i386/sev.c | 63 ++++++++++++++++++++++++++++++++++++++++++++++++
target/i386/sev_i386.h | 2 ++
target/i386/trace-events | 1 +
4 files changed, 71 insertions(+)
diff --git a/target/i386/sev-stub.c b/target/i386/sev-stub.c
index c86d8c139237..2f61c32ec975 100644
--- a/target/i386/sev-stub.c
+++ b/target/i386/sev-stub.c
@@ -39,3 +39,8 @@ uint32_t sev_get_reduced_phys_bits(void)
{
return 0;
}
+
+char *sev_get_launch_measurement(void)
+{
+ return NULL;
+}
diff --git a/target/i386/sev.c b/target/i386/sev.c
index cb0bf84742ed..7ad7eaf600a7 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -516,6 +516,68 @@ sev_launch_update_data(uint8_t *addr, uint64_t len)
return ret;
}
+static void
+sev_launch_get_measure(Notifier *notifier, void *unused)
+{
+ int ret, error;
+ guchar *data;
+ SEVState *s = sev_state;
+ struct kvm_sev_launch_measure *measurement;
+
+ if (!sev_check_state(SEV_STATE_LUPDATE)) {
+ return;
+ }
+
+ measurement = g_new0(struct kvm_sev_launch_measure, 1);
+
+ /* query the measurement blob length */
+ ret = sev_ioctl(sev_state->sev_fd, KVM_SEV_LAUNCH_MEASURE,
+ measurement, &error);
+ if (!measurement->len) {
+ error_report("%s: LAUNCH_MEASURE ret=%d fw_error=%d '%s'",
+ __func__, ret, error, fw_error_to_str(errno));
+ goto free_measurement;
+ }
+
+ data = g_new0(guchar, measurement->len);
+ measurement->uaddr = (unsigned long)data;
+
+ /* get the measurement blob */
+ ret = sev_ioctl(sev_state->sev_fd, KVM_SEV_LAUNCH_MEASURE,
+ measurement, &error);
+ if (ret) {
+ error_report("%s: LAUNCH_MEASURE ret=%d fw_error=%d '%s'",
+ __func__, ret, error, fw_error_to_str(errno));
+ goto free_data;
+ }
+
+ sev_set_guest_state(SEV_STATE_LSECRET);
+
+ /* encode the measurement value and emit the event */
+ s->measurement = g_base64_encode(data, measurement->len);
+ trace_kvm_sev_launch_measurement(s->measurement);
+
+free_data:
+ g_free(data);
+free_measurement:
+ g_free(measurement);
+}
+
+char *
+sev_get_launch_measurement(void)
+{
+ if (sev_state &&
+ sev_state->state >= SEV_STATE_LSECRET) {
+ return g_strdup(sev_state->measurement);
+ }
+
+ return NULL;
+}
+
+static Notifier sev_machine_done_notify = {
+ .notify = sev_launch_get_measure,
+};
+
void *
sev_guest_init(const char *id)
{
@@ -593,6 +655,7 @@ sev_guest_init(const char *id)
}
ram_block_notifier_add(&sev_ram_notifier);
+ qemu_add_machine_init_done_notifier(&sev_machine_done_notify);
return s;
err:
diff --git a/target/i386/sev_i386.h b/target/i386/sev_i386.h
index 924cebcab02d..6e370775770e 100644
--- a/target/i386/sev_i386.h
+++ b/target/i386/sev_i386.h
@@ -37,6 +37,7 @@ extern uint64_t sev_get_me_mask(void);
extern SevInfo *sev_get_info(void);
extern uint32_t sev_get_cbit_position(void);
extern uint32_t sev_get_reduced_phys_bits(void);
+extern char *sev_get_launch_measurement(void);
typedef struct QSevGuestInfo QSevGuestInfo;
typedef struct QSevGuestInfoClass QSevGuestInfoClass;
@@ -78,6 +79,7 @@ struct SEVState {
uint32_t handle;
int sev_fd;
SevState state;
+ gchar *measurement;
};
typedef struct SEVState SEVState;
diff --git a/target/i386/trace-events b/target/i386/trace-events
index c0cd8e93217f..f7a1a1e6b85c 100644
--- a/target/i386/trace-events
+++ b/target/i386/trace-events
@@ -13,3 +13,4 @@ kvm_memcrypt_unregister_region(void *addr, size_t len) "addr %p len 0x%lu"
kvm_sev_change_state(const char *old, const char *new) "%s -> %s"
kvm_sev_launch_start(int policy, void *session, void *pdh) "policy 0x%x session %p pdh %p"
kvm_sev_launch_update_data(void *addr, uint64_t len) "addr %p len 0x%" PRIu64
+kvm_sev_launch_measurement(const char *value) "data %s"
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH v12 19/28] sev/i386: finalize the SEV guest launch flow
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
@ 2018-03-08 12:48 ` Brijesh Singh
-1 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:48 UTC (permalink / raw)
To: qemu-devel
Cc: Peter Maydell, Brijesh Singh, kvm, Michael S. Tsirkin,
Stefan Hajnoczi, Alexander Graf, Edgar E. Iglesias,
Markus Armbruster, Bruce Rogers, Christian Borntraeger,
Marcel Apfelbaum, Borislav Petkov, Thomas Lendacky,
Eduardo Habkost, Richard Henderson, Dr. David Alan Gilbert,
Alistair Francis, Cornelia Huck, Richard Henderson,
Peter Crosthwaite, Paolo Bonzini
SEV launch flow requires us to issue LAUNCH_FINISH command before guest
is ready to run.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
target/i386/sev.c | 29 +++++++++++++++++++++++++++++
target/i386/trace-events | 1 +
2 files changed, 30 insertions(+)
diff --git a/target/i386/sev.c b/target/i386/sev.c
index 7ad7eaf600a7..ce199d259f7a 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -578,6 +578,34 @@ static Notifier sev_machine_done_notify = {
.notify = sev_launch_get_measure,
};
+static void
+sev_launch_finish(SEVState *s)
+{
+ int ret, error;
+
+ trace_kvm_sev_launch_finish();
+ ret = sev_ioctl(sev_state->sev_fd, KVM_SEV_LAUNCH_FINISH, 0, &error);
+ if (ret) {
+ error_report("%s: LAUNCH_FINISH ret=%d fw_error=%d '%s'",
+ __func__, ret, error, fw_error_to_str(error));
+ exit(1);
+ }
+
+ sev_set_guest_state(SEV_STATE_RUNNING);
+}
+
+static void
+sev_vm_state_change(void *opaque, int running, RunState state)
+{
+ SEVState *s = opaque;
+
+ if (running) {
+ if (!sev_check_state(SEV_STATE_RUNNING)) {
+ sev_launch_finish(s);
+ }
+ }
+}
+
void *
sev_guest_init(const char *id)
{
@@ -656,6 +684,7 @@ sev_guest_init(const char *id)
ram_block_notifier_add(&sev_ram_notifier);
qemu_add_machine_init_done_notifier(&sev_machine_done_notify);
+ qemu_add_vm_change_state_handler(sev_vm_state_change, s);
return s;
err:
diff --git a/target/i386/trace-events b/target/i386/trace-events
index f7a1a1e6b85c..b1fbde6e40fe 100644
--- a/target/i386/trace-events
+++ b/target/i386/trace-events
@@ -14,3 +14,4 @@ kvm_sev_change_state(const char *old, const char *new) "%s -> %s"
kvm_sev_launch_start(int policy, void *session, void *pdh) "policy 0x%x session %p pdh %p"
kvm_sev_launch_update_data(void *addr, uint64_t len) "addr %p len 0x%" PRIu64
kvm_sev_launch_measurement(const char *value) "data %s"
+kvm_sev_launch_finish(void) ""
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [Qemu-devel] [PATCH v12 19/28] sev/i386: finalize the SEV guest launch flow
@ 2018-03-08 12:48 ` Brijesh Singh
0 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:48 UTC (permalink / raw)
To: qemu-devel
Cc: Alistair Francis, Christian Borntraeger, Cornelia Huck,
Daniel P . Berrange, Dr. David Alan Gilbert, Michael S. Tsirkin,
Edgar E. Iglesias, Eduardo Habkost, Eric Blake, kvm,
Marcel Apfelbaum, Markus Armbruster, Paolo Bonzini,
Peter Crosthwaite, Peter Maydell, Richard Henderson,
Stefan Hajnoczi, Thomas Lendacky, Borislav Petkov,
Alexander Graf, Bruce Rogers, Brijesh Singh, Richard Henderson
SEV launch flow requires us to issue LAUNCH_FINISH command before guest
is ready to run.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
target/i386/sev.c | 29 +++++++++++++++++++++++++++++
target/i386/trace-events | 1 +
2 files changed, 30 insertions(+)
diff --git a/target/i386/sev.c b/target/i386/sev.c
index 7ad7eaf600a7..ce199d259f7a 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -578,6 +578,34 @@ static Notifier sev_machine_done_notify = {
.notify = sev_launch_get_measure,
};
+static void
+sev_launch_finish(SEVState *s)
+{
+ int ret, error;
+
+ trace_kvm_sev_launch_finish();
+ ret = sev_ioctl(sev_state->sev_fd, KVM_SEV_LAUNCH_FINISH, 0, &error);
+ if (ret) {
+ error_report("%s: LAUNCH_FINISH ret=%d fw_error=%d '%s'",
+ __func__, ret, error, fw_error_to_str(error));
+ exit(1);
+ }
+
+ sev_set_guest_state(SEV_STATE_RUNNING);
+}
+
+static void
+sev_vm_state_change(void *opaque, int running, RunState state)
+{
+ SEVState *s = opaque;
+
+ if (running) {
+ if (!sev_check_state(SEV_STATE_RUNNING)) {
+ sev_launch_finish(s);
+ }
+ }
+}
+
void *
sev_guest_init(const char *id)
{
@@ -656,6 +684,7 @@ sev_guest_init(const char *id)
ram_block_notifier_add(&sev_ram_notifier);
qemu_add_machine_init_done_notifier(&sev_machine_done_notify);
+ qemu_add_vm_change_state_handler(sev_vm_state_change, s);
return s;
err:
diff --git a/target/i386/trace-events b/target/i386/trace-events
index f7a1a1e6b85c..b1fbde6e40fe 100644
--- a/target/i386/trace-events
+++ b/target/i386/trace-events
@@ -14,3 +14,4 @@ kvm_sev_change_state(const char *old, const char *new) "%s -> %s"
kvm_sev_launch_start(int policy, void *session, void *pdh) "policy 0x%x session %p pdh %p"
kvm_sev_launch_update_data(void *addr, uint64_t len) "addr %p len 0x%" PRIu64
kvm_sev_launch_measurement(const char *value) "data %s"
+kvm_sev_launch_finish(void) ""
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH v12 20/28] hw/i386: set ram_debug_ops when memory encryption is enabled
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
@ 2018-03-08 12:48 ` Brijesh Singh
-1 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:48 UTC (permalink / raw)
To: qemu-devel
Cc: Peter Maydell, Brijesh Singh, kvm, Michael S. Tsirkin,
Stefan Hajnoczi, Alexander Graf, Edgar E. Iglesias,
Markus Armbruster, Bruce Rogers, Christian Borntraeger,
Marcel Apfelbaum, Borislav Petkov, Thomas Lendacky,
Eduardo Habkost, Richard Henderson, Dr. David Alan Gilbert,
Alistair Francis, Cornelia Huck, Richard Henderson,
Peter Crosthwaite, Paolo Bonzini
When memory encryption is enabled, the guest RAM and boot flash ROM will
contain the encrypted data. By setting the debug ops allow us to invoke
encryption APIs when accessing the memory for the debug purposes.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
hw/i386/pc.c | 9 +++++++++
hw/i386/pc_sysfw.c | 6 ++++++
2 files changed, 15 insertions(+)
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 35fcb6efdfb9..69364b6856b5 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1360,6 +1360,15 @@ void pc_memory_init(PCMachineState *pcms,
e820_add_entry(0x100000000ULL, pcms->above_4g_mem_size, E820_RAM);
}
+ /*
+ * When memory encryption is enabled, the guest RAM will be encrypted with
+ * a guest unique key. Set the debug ops so that any debug access to the
+ * guest RAM will go through the memory encryption APIs.
+ */
+ if (kvm_memcrypt_enabled()) {
+ kvm_memcrypt_set_debug_ops(ram);
+ }
+
if (!pcmc->has_reserved_memory &&
(machine->ram_slots ||
(machine->maxram_size > machine->ram_size))) {
diff --git a/hw/i386/pc_sysfw.c b/hw/i386/pc_sysfw.c
index 73ac783f2055..845240f97293 100644
--- a/hw/i386/pc_sysfw.c
+++ b/hw/i386/pc_sysfw.c
@@ -181,6 +181,12 @@ static void pc_system_flash_init(MemoryRegion *rom_memory)
error_report("failed to encrypt pflash rom");
exit(1);
}
+
+ /*
+ * The pflash ROM is encrypted, set the debug ops so that any
+ * debug accesses will use memory encryption APIs.
+ */
+ kvm_memcrypt_set_debug_ops(flash_mem);
}
}
}
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [Qemu-devel] [PATCH v12 20/28] hw/i386: set ram_debug_ops when memory encryption is enabled
@ 2018-03-08 12:48 ` Brijesh Singh
0 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:48 UTC (permalink / raw)
To: qemu-devel
Cc: Alistair Francis, Christian Borntraeger, Cornelia Huck,
Daniel P . Berrange, Dr. David Alan Gilbert, Michael S. Tsirkin,
Edgar E. Iglesias, Eduardo Habkost, Eric Blake, kvm,
Marcel Apfelbaum, Markus Armbruster, Paolo Bonzini,
Peter Crosthwaite, Peter Maydell, Richard Henderson,
Stefan Hajnoczi, Thomas Lendacky, Borislav Petkov,
Alexander Graf, Bruce Rogers, Brijesh Singh, Richard Henderson
When memory encryption is enabled, the guest RAM and boot flash ROM will
contain the encrypted data. By setting the debug ops allow us to invoke
encryption APIs when accessing the memory for the debug purposes.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
hw/i386/pc.c | 9 +++++++++
hw/i386/pc_sysfw.c | 6 ++++++
2 files changed, 15 insertions(+)
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 35fcb6efdfb9..69364b6856b5 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1360,6 +1360,15 @@ void pc_memory_init(PCMachineState *pcms,
e820_add_entry(0x100000000ULL, pcms->above_4g_mem_size, E820_RAM);
}
+ /*
+ * When memory encryption is enabled, the guest RAM will be encrypted with
+ * a guest unique key. Set the debug ops so that any debug access to the
+ * guest RAM will go through the memory encryption APIs.
+ */
+ if (kvm_memcrypt_enabled()) {
+ kvm_memcrypt_set_debug_ops(ram);
+ }
+
if (!pcmc->has_reserved_memory &&
(machine->ram_slots ||
(machine->maxram_size > machine->ram_size))) {
diff --git a/hw/i386/pc_sysfw.c b/hw/i386/pc_sysfw.c
index 73ac783f2055..845240f97293 100644
--- a/hw/i386/pc_sysfw.c
+++ b/hw/i386/pc_sysfw.c
@@ -181,6 +181,12 @@ static void pc_system_flash_init(MemoryRegion *rom_memory)
error_report("failed to encrypt pflash rom");
exit(1);
}
+
+ /*
+ * The pflash ROM is encrypted, set the debug ops so that any
+ * debug accesses will use memory encryption APIs.
+ */
+ kvm_memcrypt_set_debug_ops(flash_mem);
}
}
}
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH v12 21/28] sev/i386: add debug encrypt and decrypt commands
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
@ 2018-03-08 12:48 ` Brijesh Singh
-1 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:48 UTC (permalink / raw)
To: qemu-devel
Cc: Peter Maydell, Brijesh Singh, kvm, Michael S. Tsirkin,
Stefan Hajnoczi, Alexander Graf, Edgar E. Iglesias,
Markus Armbruster, Bruce Rogers, Christian Borntraeger,
Marcel Apfelbaum, Borislav Petkov, Thomas Lendacky,
Eduardo Habkost, Richard Henderson, Dr. David Alan Gilbert,
Alistair Francis, Cornelia Huck, Richard Henderson,
Peter Crosthwaite, Paolo Bonzini
KVM_SEV_DBG_DECRYPT and KVM_SEV_DBG_ENCRYPT commands are used for
decrypting and encrypting guest memory region. The command works only if
the guest policy allows the debugging.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
accel/kvm/kvm-all.c | 1 +
stubs/sev.c | 4 ++++
target/i386/sev.c | 57 ++++++++++++++++++++++++++++++++++++++++++++++++
target/i386/trace-events | 1 +
4 files changed, 63 insertions(+)
diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index 411aa87719e6..8089173491dd 100644
--- a/accel/kvm/kvm-all.c
+++ b/accel/kvm/kvm-all.c
@@ -1682,6 +1682,7 @@ static int kvm_init(MachineState *ms)
}
kvm_state->memcrypt_encrypt_data = sev_encrypt_data;
+ kvm_state->memcrypt_debug_ops = sev_set_debug_ops;
}
ret = kvm_arch_init(ms, s);
diff --git a/stubs/sev.c b/stubs/sev.c
index 2e20f3b73a5b..73f5c7f93a67 100644
--- a/stubs/sev.c
+++ b/stubs/sev.c
@@ -15,6 +15,10 @@
#include "qemu-common.h"
#include "sysemu/sev.h"
+void sev_set_debug_ops(void *handle, MemoryRegion *mr)
+{
+}
+
int sev_encrypt_data(void *handle, uint8_t *ptr, uint64_t len)
{
return 1;
diff --git a/target/i386/sev.c b/target/i386/sev.c
index ce199d259f7a..f687e9e40e32 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -29,6 +29,7 @@
#define DEFAULT_SEV_DEVICE "/dev/sev"
static SEVState *sev_state;
+static MemoryRegionRAMReadWriteOps sev_ops;
static const char *const sev_fw_errlist[] = {
"",
@@ -606,6 +607,46 @@ sev_vm_state_change(void *opaque, int running, RunState state)
}
}
+static int
+sev_dbg_enc_dec(uint8_t *dst, const uint8_t *src, uint32_t len, bool write)
+{
+ int ret, error;
+ struct kvm_sev_dbg dbg;
+
+ dbg.src_uaddr = (unsigned long)src;
+ dbg.dst_uaddr = (unsigned long)dst;
+ dbg.len = len;
+
+ trace_kvm_sev_debug(write ? "encrypt" : "decrypt", src, dst, len);
+ ret = sev_ioctl(sev_state->sev_fd,
+ write ? KVM_SEV_DBG_ENCRYPT : KVM_SEV_DBG_DECRYPT,
+ &dbg, &error);
+ if (ret) {
+ error_report("%s (%s) %#llx->%#llx+%#x ret=%d fw_error=%d '%s'",
+ __func__, write ? "write" : "read", dbg.src_uaddr,
+ dbg.dst_uaddr, dbg.len, ret, error,
+ fw_error_to_str(error));
+ }
+
+ return ret;
+}
+
+static int
+sev_mem_read(uint8_t *dst, const uint8_t *src, uint32_t len, MemTxAttrs attrs)
+{
+ assert(attrs.debug);
+
+ return sev_dbg_enc_dec(dst, src, len, false);
+}
+
+static int
+sev_mem_write(uint8_t *dst, const uint8_t *src, uint32_t len, MemTxAttrs attrs)
+{
+ assert(attrs.debug);
+
+ return sev_dbg_enc_dec(dst, src, len, true);
+}
+
void *
sev_guest_init(const char *id)
{
@@ -706,6 +747,22 @@ sev_encrypt_data(void *handle, uint8_t *ptr, uint64_t len)
return 0;
}
+void
+sev_set_debug_ops(void *handle, MemoryRegion *mr)
+{
+ SEVState *s = (SEVState *)handle;
+
+ /* If policy does not allow debug then no need to register ops */
+ if (s->policy & SEV_POLICY_NODBG) {
+ return;
+ }
+
+ sev_ops.read = sev_mem_read;
+ sev_ops.write = sev_mem_write;
+
+ memory_region_set_ram_debug_ops(mr, &sev_ops);
+}
+
static void
sev_register_types(void)
{
diff --git a/target/i386/trace-events b/target/i386/trace-events
index b1fbde6e40fe..00aa6e98d810 100644
--- a/target/i386/trace-events
+++ b/target/i386/trace-events
@@ -15,3 +15,4 @@ kvm_sev_launch_start(int policy, void *session, void *pdh) "policy 0x%x session
kvm_sev_launch_update_data(void *addr, uint64_t len) "addr %p len 0x%" PRIu64
kvm_sev_launch_measurement(const char *value) "data %s"
kvm_sev_launch_finish(void) ""
+kvm_sev_debug(const char *op, const uint8_t *src, uint8_t *dst, int len) "(%s) src %p dst %p len %d"
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [Qemu-devel] [PATCH v12 21/28] sev/i386: add debug encrypt and decrypt commands
@ 2018-03-08 12:48 ` Brijesh Singh
0 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:48 UTC (permalink / raw)
To: qemu-devel
Cc: Alistair Francis, Christian Borntraeger, Cornelia Huck,
Daniel P . Berrange, Dr. David Alan Gilbert, Michael S. Tsirkin,
Edgar E. Iglesias, Eduardo Habkost, Eric Blake, kvm,
Marcel Apfelbaum, Markus Armbruster, Paolo Bonzini,
Peter Crosthwaite, Peter Maydell, Richard Henderson,
Stefan Hajnoczi, Thomas Lendacky, Borislav Petkov,
Alexander Graf, Bruce Rogers, Brijesh Singh, Richard Henderson
KVM_SEV_DBG_DECRYPT and KVM_SEV_DBG_ENCRYPT commands are used for
decrypting and encrypting guest memory region. The command works only if
the guest policy allows the debugging.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
accel/kvm/kvm-all.c | 1 +
stubs/sev.c | 4 ++++
target/i386/sev.c | 57 ++++++++++++++++++++++++++++++++++++++++++++++++
target/i386/trace-events | 1 +
4 files changed, 63 insertions(+)
diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index 411aa87719e6..8089173491dd 100644
--- a/accel/kvm/kvm-all.c
+++ b/accel/kvm/kvm-all.c
@@ -1682,6 +1682,7 @@ static int kvm_init(MachineState *ms)
}
kvm_state->memcrypt_encrypt_data = sev_encrypt_data;
+ kvm_state->memcrypt_debug_ops = sev_set_debug_ops;
}
ret = kvm_arch_init(ms, s);
diff --git a/stubs/sev.c b/stubs/sev.c
index 2e20f3b73a5b..73f5c7f93a67 100644
--- a/stubs/sev.c
+++ b/stubs/sev.c
@@ -15,6 +15,10 @@
#include "qemu-common.h"
#include "sysemu/sev.h"
+void sev_set_debug_ops(void *handle, MemoryRegion *mr)
+{
+}
+
int sev_encrypt_data(void *handle, uint8_t *ptr, uint64_t len)
{
return 1;
diff --git a/target/i386/sev.c b/target/i386/sev.c
index ce199d259f7a..f687e9e40e32 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -29,6 +29,7 @@
#define DEFAULT_SEV_DEVICE "/dev/sev"
static SEVState *sev_state;
+static MemoryRegionRAMReadWriteOps sev_ops;
static const char *const sev_fw_errlist[] = {
"",
@@ -606,6 +607,46 @@ sev_vm_state_change(void *opaque, int running, RunState state)
}
}
+static int
+sev_dbg_enc_dec(uint8_t *dst, const uint8_t *src, uint32_t len, bool write)
+{
+ int ret, error;
+ struct kvm_sev_dbg dbg;
+
+ dbg.src_uaddr = (unsigned long)src;
+ dbg.dst_uaddr = (unsigned long)dst;
+ dbg.len = len;
+
+ trace_kvm_sev_debug(write ? "encrypt" : "decrypt", src, dst, len);
+ ret = sev_ioctl(sev_state->sev_fd,
+ write ? KVM_SEV_DBG_ENCRYPT : KVM_SEV_DBG_DECRYPT,
+ &dbg, &error);
+ if (ret) {
+ error_report("%s (%s) %#llx->%#llx+%#x ret=%d fw_error=%d '%s'",
+ __func__, write ? "write" : "read", dbg.src_uaddr,
+ dbg.dst_uaddr, dbg.len, ret, error,
+ fw_error_to_str(error));
+ }
+
+ return ret;
+}
+
+static int
+sev_mem_read(uint8_t *dst, const uint8_t *src, uint32_t len, MemTxAttrs attrs)
+{
+ assert(attrs.debug);
+
+ return sev_dbg_enc_dec(dst, src, len, false);
+}
+
+static int
+sev_mem_write(uint8_t *dst, const uint8_t *src, uint32_t len, MemTxAttrs attrs)
+{
+ assert(attrs.debug);
+
+ return sev_dbg_enc_dec(dst, src, len, true);
+}
+
void *
sev_guest_init(const char *id)
{
@@ -706,6 +747,22 @@ sev_encrypt_data(void *handle, uint8_t *ptr, uint64_t len)
return 0;
}
+void
+sev_set_debug_ops(void *handle, MemoryRegion *mr)
+{
+ SEVState *s = (SEVState *)handle;
+
+ /* If policy does not allow debug then no need to register ops */
+ if (s->policy & SEV_POLICY_NODBG) {
+ return;
+ }
+
+ sev_ops.read = sev_mem_read;
+ sev_ops.write = sev_mem_write;
+
+ memory_region_set_ram_debug_ops(mr, &sev_ops);
+}
+
static void
sev_register_types(void)
{
diff --git a/target/i386/trace-events b/target/i386/trace-events
index b1fbde6e40fe..00aa6e98d810 100644
--- a/target/i386/trace-events
+++ b/target/i386/trace-events
@@ -15,3 +15,4 @@ kvm_sev_launch_start(int policy, void *session, void *pdh) "policy 0x%x session
kvm_sev_launch_update_data(void *addr, uint64_t len) "addr %p len 0x%" PRIu64
kvm_sev_launch_measurement(const char *value) "data %s"
kvm_sev_launch_finish(void) ""
+kvm_sev_debug(const char *op, const uint8_t *src, uint8_t *dst, int len) "(%s) src %p dst %p len %d"
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH v12 22/28] target/i386: clear C-bit when walking SEV guest page table
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
@ 2018-03-08 12:48 ` Brijesh Singh
-1 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:48 UTC (permalink / raw)
To: qemu-devel
Cc: Peter Maydell, Brijesh Singh, kvm, Michael S. Tsirkin,
Stefan Hajnoczi, Alexander Graf, Edgar E. Iglesias,
Markus Armbruster, Bruce Rogers, Christian Borntraeger,
Marcel Apfelbaum, Borislav Petkov, Thomas Lendacky,
Eduardo Habkost, Richard Henderson, Dr. David Alan Gilbert,
Alistair Francis, Cornelia Huck, Richard Henderson,
Peter Crosthwaite, Paolo Bonzini
In SEV-enabled guest the pte entry will have C-bit set, we need to
clear the C-bit when walking the page table.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
target/i386/helper.c | 31 +++++++++++++----------
target/i386/monitor.c | 68 +++++++++++++++++++++++++++++++++------------------
2 files changed, 62 insertions(+), 37 deletions(-)
diff --git a/target/i386/helper.c b/target/i386/helper.c
index 58fb6eec562a..dc5c7005cf13 100644
--- a/target/i386/helper.c
+++ b/target/i386/helper.c
@@ -21,6 +21,7 @@
#include "cpu.h"
#include "exec/exec-all.h"
#include "sysemu/kvm.h"
+#include "sev_i386.h"
#include "kvm_i386.h"
#ifndef CONFIG_USER_ONLY
#include "sysemu/sysemu.h"
@@ -732,6 +733,9 @@ hwaddr x86_cpu_get_phys_page_debug(CPUState *cs, vaddr addr)
int32_t a20_mask;
uint32_t page_offset;
int page_size;
+ uint64_t me_mask;
+
+ me_mask = sev_get_me_mask();
a20_mask = x86_get_a20_mask(env);
if (!(env->cr[0] & CR0_PG_MASK)) {
@@ -755,25 +759,25 @@ hwaddr x86_cpu_get_phys_page_debug(CPUState *cs, vaddr addr)
}
if (la57) {
- pml5e_addr = ((env->cr[3] & ~0xfff) +
+ pml5e_addr = ((env->cr[3] & ~0xfff & me_mask) +
(((addr >> 48) & 0x1ff) << 3)) & a20_mask;
- pml5e = ldq_phys_debug(cs, pml5e_addr);
+ pml5e = ldq_phys_debug(cs, pml5e_addr) & me_mask;
if (!(pml5e & PG_PRESENT_MASK)) {
return -1;
}
} else {
- pml5e = env->cr[3];
+ pml5e = env->cr[3] & me_mask;
}
pml4e_addr = ((pml5e & PG_ADDRESS_MASK) +
(((addr >> 39) & 0x1ff) << 3)) & a20_mask;
- pml4e = ldq_phys_debug(cs, pml4e_addr);
+ pml4e = ldq_phys_debug(cs, pml4e_addr) & me_mask;
if (!(pml4e & PG_PRESENT_MASK)) {
return -1;
}
pdpe_addr = ((pml4e & PG_ADDRESS_MASK) +
(((addr >> 30) & 0x1ff) << 3)) & a20_mask;
- pdpe = x86_ldq_phys(cs, pdpe_addr);
+ pdpe = ldq_phys_debug(cs, pdpe_addr) & me_mask;
if (!(pdpe & PG_PRESENT_MASK)) {
return -1;
}
@@ -786,16 +790,16 @@ hwaddr x86_cpu_get_phys_page_debug(CPUState *cs, vaddr addr)
} else
#endif
{
- pdpe_addr = ((env->cr[3] & ~0x1f) + ((addr >> 27) & 0x18)) &
- a20_mask;
- pdpe = ldq_phys_debug(cs, pdpe_addr);
+ pdpe_addr = ((env->cr[3] & ~0x1f & me_mask) + ((addr >> 27) & 0x18))
+ & a20_mask;
+ pdpe = ldq_phys_debug(cs, pdpe_addr) & me_mask;
if (!(pdpe & PG_PRESENT_MASK))
return -1;
}
pde_addr = ((pdpe & PG_ADDRESS_MASK) +
(((addr >> 21) & 0x1ff) << 3)) & a20_mask;
- pde = ldq_phys_debug(cs, pde_addr);
+ pde = ldq_phys_debug(cs, pde_addr) & me_mask;
if (!(pde & PG_PRESENT_MASK)) {
return -1;
}
@@ -808,7 +812,7 @@ hwaddr x86_cpu_get_phys_page_debug(CPUState *cs, vaddr addr)
pte_addr = ((pde & PG_ADDRESS_MASK) +
(((addr >> 12) & 0x1ff) << 3)) & a20_mask;
page_size = 4096;
- pte = ldq_phys_debug(cs, pte_addr);
+ pte = ldq_phys_debug(cs, pte_addr) & me_mask;
}
if (!(pte & PG_PRESENT_MASK)) {
return -1;
@@ -817,8 +821,9 @@ hwaddr x86_cpu_get_phys_page_debug(CPUState *cs, vaddr addr)
uint32_t pde;
/* page directory entry */
- pde_addr = ((env->cr[3] & ~0xfff) + ((addr >> 20) & 0xffc)) & a20_mask;
- pde = ldl_phys_debug(cs, pde_addr);
+ pde_addr = ((env->cr[3] & ~0xfff & me_mask) + ((addr >> 20) & 0xffc))
+ & a20_mask;
+ pde = ldl_phys_debug(cs, pde_addr) & me_mask;
if (!(pde & PG_PRESENT_MASK))
return -1;
if ((pde & PG_PSE_MASK) && (env->cr[4] & CR4_PSE_MASK)) {
@@ -827,7 +832,7 @@ hwaddr x86_cpu_get_phys_page_debug(CPUState *cs, vaddr addr)
} else {
/* page directory entry */
pte_addr = ((pde & ~0xfff) + ((addr >> 10) & 0xffc)) & a20_mask;
- pte = ldl_phys_debug(cs, pte_addr);
+ pte = ldl_phys_debug(cs, pte_addr) & me_mask;
if (!(pte & PG_PRESENT_MASK)) {
return -1;
}
diff --git a/target/i386/monitor.c b/target/i386/monitor.c
index 4d9019626031..7df31c3cdf1b 100644
--- a/target/i386/monitor.c
+++ b/target/i386/monitor.c
@@ -98,16 +98,20 @@ static void tlb_info_pae32(Monitor *mon, CPUArchState *env)
unsigned int l1, l2, l3;
uint64_t pdpe, pde, pte;
uint64_t pdp_addr, pd_addr, pt_addr;
+ uint64_t me_mask;
+
+ me_mask = sev_get_me_mask();
pdp_addr = env->cr[3] & ~0x1f;
+ pdp_addr &= me_mask;
for (l1 = 0; l1 < 4; l1++) {
cpu_physical_memory_read_debug(pdp_addr + l1 * 8, &pdpe, 8);
- pdpe = le64_to_cpu(pdpe);
+ pdpe = le64_to_cpu(pdpe & me_mask);
if (pdpe & PG_PRESENT_MASK) {
pd_addr = pdpe & 0x3fffffffff000ULL;
for (l2 = 0; l2 < 512; l2++) {
cpu_physical_memory_read_debug(pd_addr + l2 * 8, &pde, 8);
- pde = le64_to_cpu(pde);
+ pde = le64_to_cpu(pde & me_mask);
if (pde & PG_PRESENT_MASK) {
if (pde & PG_PSE_MASK) {
/* 2M pages with PAE, CR4.PSE is ignored */
@@ -118,7 +122,7 @@ static void tlb_info_pae32(Monitor *mon, CPUArchState *env)
for (l3 = 0; l3 < 512; l3++) {
cpu_physical_memory_read_debug(pt_addr + l3 * 8,
&pte, 8);
- pte = le64_to_cpu(pte);
+ pte = le64_to_cpu(pte & me_mask);
if (pte & PG_PRESENT_MASK) {
print_pte(mon, env, (l1 << 30) + (l2 << 21)
+ (l3 << 12),
@@ -140,10 +144,13 @@ static void tlb_info_la48(Monitor *mon, CPUArchState *env,
uint64_t l1, l2, l3, l4;
uint64_t pml4e, pdpe, pde, pte;
uint64_t pdp_addr, pd_addr, pt_addr;
+ uint64_t me_mask;
+
+ me_mask = sev_get_me_mask();
for (l1 = 0; l1 < 512; l1++) {
cpu_physical_memory_read_debug(pml4_addr + l1 * 8, &pml4e, 8);
- pml4e = le64_to_cpu(pml4e);
+ pml4e = le64_to_cpu(pml4e & me_mask);
if (!(pml4e & PG_PRESENT_MASK)) {
continue;
}
@@ -151,7 +158,7 @@ static void tlb_info_la48(Monitor *mon, CPUArchState *env,
pdp_addr = pml4e & 0x3fffffffff000ULL;
for (l2 = 0; l2 < 512; l2++) {
cpu_physical_memory_read_debug(pdp_addr + l2 * 8, &pdpe, 8);
- pdpe = le64_to_cpu(pdpe);
+ pdpe = le64_to_cpu(pdpe & me_mask);
if (!(pdpe & PG_PRESENT_MASK)) {
continue;
}
@@ -166,7 +173,7 @@ static void tlb_info_la48(Monitor *mon, CPUArchState *env,
pd_addr = pdpe & 0x3fffffffff000ULL;
for (l3 = 0; l3 < 512; l3++) {
cpu_physical_memory_read_debug(pd_addr + l3 * 8, &pde, 8);
- pde = le64_to_cpu(pde);
+ pde = le64_to_cpu(pde & me_mask);
if (!(pde & PG_PRESENT_MASK)) {
continue;
}
@@ -181,7 +188,7 @@ static void tlb_info_la48(Monitor *mon, CPUArchState *env,
pt_addr = pde & 0x3fffffffff000ULL;
for (l4 = 0; l4 < 512; l4++) {
cpu_physical_memory_read_debug(pt_addr + l4 * 8, &pte, 8);
- pte = le64_to_cpu(pte);
+ pte = le64_to_cpu(pte & me_mask);
if (pte & PG_PRESENT_MASK) {
print_pte(mon, env, (l0 << 48) + (l1 << 39) +
(l2 << 30) + (l3 << 21) + (l4 << 12),
@@ -198,11 +205,14 @@ static void tlb_info_la57(Monitor *mon, CPUArchState *env)
uint64_t l0;
uint64_t pml5e;
uint64_t pml5_addr;
+ uint64_t me_mask;
- pml5_addr = env->cr[3] & 0x3fffffffff000ULL;
+ me_mask = sev_get_me_mask();
+
+ pml5_addr = env->cr[3] & 0x3fffffffff000ULL & me_mask;
for (l0 = 0; l0 < 512; l0++) {
cpu_physical_memory_read_debug(pml5_addr + l0 * 8, &pml5e, 8);
- pml5e = le64_to_cpu(pml5e);
+ pml5e = le64_to_cpu(pml5e & me_mask);
if (pml5e & PG_PRESENT_MASK) {
tlb_info_la48(mon, env, l0, pml5e & 0x3fffffffff000ULL);
}
@@ -230,7 +240,8 @@ void hmp_info_tlb(Monitor *mon, const QDict *qdict)
if (env->cr[4] & CR4_LA57_MASK) {
tlb_info_la57(mon, env);
} else {
- tlb_info_la48(mon, env, 0, env->cr[3] & 0x3fffffffff000ULL);
+ tlb_info_la48(mon, env, 0, env->cr[3] & 0x3fffffffff000ULL &
+ sev_get_me_mask());
}
} else
#endif
@@ -314,19 +325,22 @@ static void mem_info_pae32(Monitor *mon, CPUArchState *env)
uint64_t pdpe, pde, pte;
uint64_t pdp_addr, pd_addr, pt_addr;
hwaddr start, end;
+ uint64_t me_mask;
- pdp_addr = env->cr[3] & ~0x1f;
+ me_mask = sev_get_me_mask();
+
+ pdp_addr = env->cr[3] & ~0x1f & me_mask;
last_prot = 0;
start = -1;
for (l1 = 0; l1 < 4; l1++) {
cpu_physical_memory_read_debug(pdp_addr + l1 * 8, &pdpe, 8);
- pdpe = le64_to_cpu(pdpe);
+ pdpe = le64_to_cpu(pdpe & me_mask);
end = l1 << 30;
if (pdpe & PG_PRESENT_MASK) {
pd_addr = pdpe & 0x3fffffffff000ULL;
for (l2 = 0; l2 < 512; l2++) {
cpu_physical_memory_read_debug(pd_addr + l2 * 8, &pde, 8);
- pde = le64_to_cpu(pde);
+ pde = le64_to_cpu(pde & me_mask);
end = (l1 << 30) + (l2 << 21);
if (pde & PG_PRESENT_MASK) {
if (pde & PG_PSE_MASK) {
@@ -338,7 +352,7 @@ static void mem_info_pae32(Monitor *mon, CPUArchState *env)
for (l3 = 0; l3 < 512; l3++) {
cpu_physical_memory_read_debug(pt_addr + l3 * 8,
&pte, 8);
- pte = le64_to_cpu(pte);
+ pte = le64_to_cpu(pte & me_mask);
end = (l1 << 30) + (l2 << 21) + (l3 << 12);
if (pte & PG_PRESENT_MASK) {
prot = pte & pde & (PG_USER_MASK | PG_RW_MASK |
@@ -371,19 +385,22 @@ static void mem_info_la48(Monitor *mon, CPUArchState *env)
uint64_t l1, l2, l3, l4;
uint64_t pml4e, pdpe, pde, pte;
uint64_t pml4_addr, pdp_addr, pd_addr, pt_addr, start, end;
+ uint64_t me_mask;
+
+ me_mask = sev_get_me_mask();
- pml4_addr = env->cr[3] & 0x3fffffffff000ULL;
+ pml4_addr = env->cr[3] & 0x3fffffffff000ULL & me_mask;
last_prot = 0;
start = -1;
for (l1 = 0; l1 < 512; l1++) {
cpu_physical_memory_read_debug(pml4_addr + l1 * 8, &pml4e, 8);
- pml4e = le64_to_cpu(pml4e);
+ pml4e = le64_to_cpu(pml4e & me_mask);
end = l1 << 39;
if (pml4e & PG_PRESENT_MASK) {
pdp_addr = pml4e & 0x3fffffffff000ULL;
for (l2 = 0; l2 < 512; l2++) {
cpu_physical_memory_read_debug(pdp_addr + l2 * 8, &pdpe, 8);
- pdpe = le64_to_cpu(pdpe);
+ pdpe = le64_to_cpu(pdpe & me_mask);
end = (l1 << 39) + (l2 << 30);
if (pdpe & PG_PRESENT_MASK) {
if (pdpe & PG_PSE_MASK) {
@@ -396,7 +413,7 @@ static void mem_info_la48(Monitor *mon, CPUArchState *env)
for (l3 = 0; l3 < 512; l3++) {
cpu_physical_memory_read_debug(pd_addr + l3 * 8,
&pde, 8);
- pde = le64_to_cpu(pde);
+ pde = le64_to_cpu(pde & me_mask);
end = (l1 << 39) + (l2 << 30) + (l3 << 21);
if (pde & PG_PRESENT_MASK) {
if (pde & PG_PSE_MASK) {
@@ -410,7 +427,7 @@ static void mem_info_la48(Monitor *mon, CPUArchState *env)
cpu_physical_memory_read_debug(pt_addr
+ l4 * 8,
&pte, 8);
- pte = le64_to_cpu(pte);
+ pte = le64_to_cpu(pte & me_mask);
end = (l1 << 39) + (l2 << 30) +
(l3 << 21) + (l4 << 12);
if (pte & PG_PRESENT_MASK) {
@@ -449,13 +466,16 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env)
uint64_t l0, l1, l2, l3, l4;
uint64_t pml5e, pml4e, pdpe, pde, pte;
uint64_t pml5_addr, pml4_addr, pdp_addr, pd_addr, pt_addr, start, end;
+ uint64_t me_mask;
+
+ me_mask = sev_get_me_mask();
- pml5_addr = env->cr[3] & 0x3fffffffff000ULL;
+ pml5_addr = env->cr[3] & 0x3fffffffff000ULL & me_mask;
last_prot = 0;
start = -1;
for (l0 = 0; l0 < 512; l0++) {
cpu_physical_memory_read_debug(pml5_addr + l0 * 8, &pml5e, 8);
- pml5e = le64_to_cpu(pml5e);
+ pml5e = le64_to_cpu(pml5e & me_mask);
end = l0 << 48;
if (!(pml5e & PG_PRESENT_MASK)) {
prot = 0;
@@ -466,7 +486,7 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env)
pml4_addr = pml5e & 0x3fffffffff000ULL;
for (l1 = 0; l1 < 512; l1++) {
cpu_physical_memory_read_debug(pml4_addr + l1 * 8, &pml4e, 8);
- pml4e = le64_to_cpu(pml4e);
+ pml4e = le64_to_cpu(pml4e & me_mask);
end = (l0 << 48) + (l1 << 39);
if (!(pml4e & PG_PRESENT_MASK)) {
prot = 0;
@@ -477,7 +497,7 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env)
pdp_addr = pml4e & 0x3fffffffff000ULL;
for (l2 = 0; l2 < 512; l2++) {
cpu_physical_memory_read_debug(pdp_addr + l2 * 8, &pdpe, 8);
- pdpe = le64_to_cpu(pdpe);
+ pdpe = le64_to_cpu(pdpe & me_mask);
end = (l0 << 48) + (l1 << 39) + (l2 << 30);
if (pdpe & PG_PRESENT_MASK) {
prot = 0;
@@ -496,7 +516,7 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env)
pd_addr = pdpe & 0x3fffffffff000ULL;
for (l3 = 0; l3 < 512; l3++) {
cpu_physical_memory_read_debug(pd_addr + l3 * 8, &pde, 8);
- pde = le64_to_cpu(pde);
+ pde = le64_to_cpu(pde & me_mask);
end = (l0 << 48) + (l1 << 39) + (l2 << 30) + (l3 << 21);
if (pde & PG_PRESENT_MASK) {
prot = 0;
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [Qemu-devel] [PATCH v12 22/28] target/i386: clear C-bit when walking SEV guest page table
@ 2018-03-08 12:48 ` Brijesh Singh
0 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:48 UTC (permalink / raw)
To: qemu-devel
Cc: Alistair Francis, Christian Borntraeger, Cornelia Huck,
Daniel P . Berrange, Dr. David Alan Gilbert, Michael S. Tsirkin,
Edgar E. Iglesias, Eduardo Habkost, Eric Blake, kvm,
Marcel Apfelbaum, Markus Armbruster, Paolo Bonzini,
Peter Crosthwaite, Peter Maydell, Richard Henderson,
Stefan Hajnoczi, Thomas Lendacky, Borislav Petkov,
Alexander Graf, Bruce Rogers, Brijesh Singh, Richard Henderson
In SEV-enabled guest the pte entry will have C-bit set, we need to
clear the C-bit when walking the page table.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
target/i386/helper.c | 31 +++++++++++++----------
target/i386/monitor.c | 68 +++++++++++++++++++++++++++++++++------------------
2 files changed, 62 insertions(+), 37 deletions(-)
diff --git a/target/i386/helper.c b/target/i386/helper.c
index 58fb6eec562a..dc5c7005cf13 100644
--- a/target/i386/helper.c
+++ b/target/i386/helper.c
@@ -21,6 +21,7 @@
#include "cpu.h"
#include "exec/exec-all.h"
#include "sysemu/kvm.h"
+#include "sev_i386.h"
#include "kvm_i386.h"
#ifndef CONFIG_USER_ONLY
#include "sysemu/sysemu.h"
@@ -732,6 +733,9 @@ hwaddr x86_cpu_get_phys_page_debug(CPUState *cs, vaddr addr)
int32_t a20_mask;
uint32_t page_offset;
int page_size;
+ uint64_t me_mask;
+
+ me_mask = sev_get_me_mask();
a20_mask = x86_get_a20_mask(env);
if (!(env->cr[0] & CR0_PG_MASK)) {
@@ -755,25 +759,25 @@ hwaddr x86_cpu_get_phys_page_debug(CPUState *cs, vaddr addr)
}
if (la57) {
- pml5e_addr = ((env->cr[3] & ~0xfff) +
+ pml5e_addr = ((env->cr[3] & ~0xfff & me_mask) +
(((addr >> 48) & 0x1ff) << 3)) & a20_mask;
- pml5e = ldq_phys_debug(cs, pml5e_addr);
+ pml5e = ldq_phys_debug(cs, pml5e_addr) & me_mask;
if (!(pml5e & PG_PRESENT_MASK)) {
return -1;
}
} else {
- pml5e = env->cr[3];
+ pml5e = env->cr[3] & me_mask;
}
pml4e_addr = ((pml5e & PG_ADDRESS_MASK) +
(((addr >> 39) & 0x1ff) << 3)) & a20_mask;
- pml4e = ldq_phys_debug(cs, pml4e_addr);
+ pml4e = ldq_phys_debug(cs, pml4e_addr) & me_mask;
if (!(pml4e & PG_PRESENT_MASK)) {
return -1;
}
pdpe_addr = ((pml4e & PG_ADDRESS_MASK) +
(((addr >> 30) & 0x1ff) << 3)) & a20_mask;
- pdpe = x86_ldq_phys(cs, pdpe_addr);
+ pdpe = ldq_phys_debug(cs, pdpe_addr) & me_mask;
if (!(pdpe & PG_PRESENT_MASK)) {
return -1;
}
@@ -786,16 +790,16 @@ hwaddr x86_cpu_get_phys_page_debug(CPUState *cs, vaddr addr)
} else
#endif
{
- pdpe_addr = ((env->cr[3] & ~0x1f) + ((addr >> 27) & 0x18)) &
- a20_mask;
- pdpe = ldq_phys_debug(cs, pdpe_addr);
+ pdpe_addr = ((env->cr[3] & ~0x1f & me_mask) + ((addr >> 27) & 0x18))
+ & a20_mask;
+ pdpe = ldq_phys_debug(cs, pdpe_addr) & me_mask;
if (!(pdpe & PG_PRESENT_MASK))
return -1;
}
pde_addr = ((pdpe & PG_ADDRESS_MASK) +
(((addr >> 21) & 0x1ff) << 3)) & a20_mask;
- pde = ldq_phys_debug(cs, pde_addr);
+ pde = ldq_phys_debug(cs, pde_addr) & me_mask;
if (!(pde & PG_PRESENT_MASK)) {
return -1;
}
@@ -808,7 +812,7 @@ hwaddr x86_cpu_get_phys_page_debug(CPUState *cs, vaddr addr)
pte_addr = ((pde & PG_ADDRESS_MASK) +
(((addr >> 12) & 0x1ff) << 3)) & a20_mask;
page_size = 4096;
- pte = ldq_phys_debug(cs, pte_addr);
+ pte = ldq_phys_debug(cs, pte_addr) & me_mask;
}
if (!(pte & PG_PRESENT_MASK)) {
return -1;
@@ -817,8 +821,9 @@ hwaddr x86_cpu_get_phys_page_debug(CPUState *cs, vaddr addr)
uint32_t pde;
/* page directory entry */
- pde_addr = ((env->cr[3] & ~0xfff) + ((addr >> 20) & 0xffc)) & a20_mask;
- pde = ldl_phys_debug(cs, pde_addr);
+ pde_addr = ((env->cr[3] & ~0xfff & me_mask) + ((addr >> 20) & 0xffc))
+ & a20_mask;
+ pde = ldl_phys_debug(cs, pde_addr) & me_mask;
if (!(pde & PG_PRESENT_MASK))
return -1;
if ((pde & PG_PSE_MASK) && (env->cr[4] & CR4_PSE_MASK)) {
@@ -827,7 +832,7 @@ hwaddr x86_cpu_get_phys_page_debug(CPUState *cs, vaddr addr)
} else {
/* page directory entry */
pte_addr = ((pde & ~0xfff) + ((addr >> 10) & 0xffc)) & a20_mask;
- pte = ldl_phys_debug(cs, pte_addr);
+ pte = ldl_phys_debug(cs, pte_addr) & me_mask;
if (!(pte & PG_PRESENT_MASK)) {
return -1;
}
diff --git a/target/i386/monitor.c b/target/i386/monitor.c
index 4d9019626031..7df31c3cdf1b 100644
--- a/target/i386/monitor.c
+++ b/target/i386/monitor.c
@@ -98,16 +98,20 @@ static void tlb_info_pae32(Monitor *mon, CPUArchState *env)
unsigned int l1, l2, l3;
uint64_t pdpe, pde, pte;
uint64_t pdp_addr, pd_addr, pt_addr;
+ uint64_t me_mask;
+
+ me_mask = sev_get_me_mask();
pdp_addr = env->cr[3] & ~0x1f;
+ pdp_addr &= me_mask;
for (l1 = 0; l1 < 4; l1++) {
cpu_physical_memory_read_debug(pdp_addr + l1 * 8, &pdpe, 8);
- pdpe = le64_to_cpu(pdpe);
+ pdpe = le64_to_cpu(pdpe & me_mask);
if (pdpe & PG_PRESENT_MASK) {
pd_addr = pdpe & 0x3fffffffff000ULL;
for (l2 = 0; l2 < 512; l2++) {
cpu_physical_memory_read_debug(pd_addr + l2 * 8, &pde, 8);
- pde = le64_to_cpu(pde);
+ pde = le64_to_cpu(pde & me_mask);
if (pde & PG_PRESENT_MASK) {
if (pde & PG_PSE_MASK) {
/* 2M pages with PAE, CR4.PSE is ignored */
@@ -118,7 +122,7 @@ static void tlb_info_pae32(Monitor *mon, CPUArchState *env)
for (l3 = 0; l3 < 512; l3++) {
cpu_physical_memory_read_debug(pt_addr + l3 * 8,
&pte, 8);
- pte = le64_to_cpu(pte);
+ pte = le64_to_cpu(pte & me_mask);
if (pte & PG_PRESENT_MASK) {
print_pte(mon, env, (l1 << 30) + (l2 << 21)
+ (l3 << 12),
@@ -140,10 +144,13 @@ static void tlb_info_la48(Monitor *mon, CPUArchState *env,
uint64_t l1, l2, l3, l4;
uint64_t pml4e, pdpe, pde, pte;
uint64_t pdp_addr, pd_addr, pt_addr;
+ uint64_t me_mask;
+
+ me_mask = sev_get_me_mask();
for (l1 = 0; l1 < 512; l1++) {
cpu_physical_memory_read_debug(pml4_addr + l1 * 8, &pml4e, 8);
- pml4e = le64_to_cpu(pml4e);
+ pml4e = le64_to_cpu(pml4e & me_mask);
if (!(pml4e & PG_PRESENT_MASK)) {
continue;
}
@@ -151,7 +158,7 @@ static void tlb_info_la48(Monitor *mon, CPUArchState *env,
pdp_addr = pml4e & 0x3fffffffff000ULL;
for (l2 = 0; l2 < 512; l2++) {
cpu_physical_memory_read_debug(pdp_addr + l2 * 8, &pdpe, 8);
- pdpe = le64_to_cpu(pdpe);
+ pdpe = le64_to_cpu(pdpe & me_mask);
if (!(pdpe & PG_PRESENT_MASK)) {
continue;
}
@@ -166,7 +173,7 @@ static void tlb_info_la48(Monitor *mon, CPUArchState *env,
pd_addr = pdpe & 0x3fffffffff000ULL;
for (l3 = 0; l3 < 512; l3++) {
cpu_physical_memory_read_debug(pd_addr + l3 * 8, &pde, 8);
- pde = le64_to_cpu(pde);
+ pde = le64_to_cpu(pde & me_mask);
if (!(pde & PG_PRESENT_MASK)) {
continue;
}
@@ -181,7 +188,7 @@ static void tlb_info_la48(Monitor *mon, CPUArchState *env,
pt_addr = pde & 0x3fffffffff000ULL;
for (l4 = 0; l4 < 512; l4++) {
cpu_physical_memory_read_debug(pt_addr + l4 * 8, &pte, 8);
- pte = le64_to_cpu(pte);
+ pte = le64_to_cpu(pte & me_mask);
if (pte & PG_PRESENT_MASK) {
print_pte(mon, env, (l0 << 48) + (l1 << 39) +
(l2 << 30) + (l3 << 21) + (l4 << 12),
@@ -198,11 +205,14 @@ static void tlb_info_la57(Monitor *mon, CPUArchState *env)
uint64_t l0;
uint64_t pml5e;
uint64_t pml5_addr;
+ uint64_t me_mask;
- pml5_addr = env->cr[3] & 0x3fffffffff000ULL;
+ me_mask = sev_get_me_mask();
+
+ pml5_addr = env->cr[3] & 0x3fffffffff000ULL & me_mask;
for (l0 = 0; l0 < 512; l0++) {
cpu_physical_memory_read_debug(pml5_addr + l0 * 8, &pml5e, 8);
- pml5e = le64_to_cpu(pml5e);
+ pml5e = le64_to_cpu(pml5e & me_mask);
if (pml5e & PG_PRESENT_MASK) {
tlb_info_la48(mon, env, l0, pml5e & 0x3fffffffff000ULL);
}
@@ -230,7 +240,8 @@ void hmp_info_tlb(Monitor *mon, const QDict *qdict)
if (env->cr[4] & CR4_LA57_MASK) {
tlb_info_la57(mon, env);
} else {
- tlb_info_la48(mon, env, 0, env->cr[3] & 0x3fffffffff000ULL);
+ tlb_info_la48(mon, env, 0, env->cr[3] & 0x3fffffffff000ULL &
+ sev_get_me_mask());
}
} else
#endif
@@ -314,19 +325,22 @@ static void mem_info_pae32(Monitor *mon, CPUArchState *env)
uint64_t pdpe, pde, pte;
uint64_t pdp_addr, pd_addr, pt_addr;
hwaddr start, end;
+ uint64_t me_mask;
- pdp_addr = env->cr[3] & ~0x1f;
+ me_mask = sev_get_me_mask();
+
+ pdp_addr = env->cr[3] & ~0x1f & me_mask;
last_prot = 0;
start = -1;
for (l1 = 0; l1 < 4; l1++) {
cpu_physical_memory_read_debug(pdp_addr + l1 * 8, &pdpe, 8);
- pdpe = le64_to_cpu(pdpe);
+ pdpe = le64_to_cpu(pdpe & me_mask);
end = l1 << 30;
if (pdpe & PG_PRESENT_MASK) {
pd_addr = pdpe & 0x3fffffffff000ULL;
for (l2 = 0; l2 < 512; l2++) {
cpu_physical_memory_read_debug(pd_addr + l2 * 8, &pde, 8);
- pde = le64_to_cpu(pde);
+ pde = le64_to_cpu(pde & me_mask);
end = (l1 << 30) + (l2 << 21);
if (pde & PG_PRESENT_MASK) {
if (pde & PG_PSE_MASK) {
@@ -338,7 +352,7 @@ static void mem_info_pae32(Monitor *mon, CPUArchState *env)
for (l3 = 0; l3 < 512; l3++) {
cpu_physical_memory_read_debug(pt_addr + l3 * 8,
&pte, 8);
- pte = le64_to_cpu(pte);
+ pte = le64_to_cpu(pte & me_mask);
end = (l1 << 30) + (l2 << 21) + (l3 << 12);
if (pte & PG_PRESENT_MASK) {
prot = pte & pde & (PG_USER_MASK | PG_RW_MASK |
@@ -371,19 +385,22 @@ static void mem_info_la48(Monitor *mon, CPUArchState *env)
uint64_t l1, l2, l3, l4;
uint64_t pml4e, pdpe, pde, pte;
uint64_t pml4_addr, pdp_addr, pd_addr, pt_addr, start, end;
+ uint64_t me_mask;
+
+ me_mask = sev_get_me_mask();
- pml4_addr = env->cr[3] & 0x3fffffffff000ULL;
+ pml4_addr = env->cr[3] & 0x3fffffffff000ULL & me_mask;
last_prot = 0;
start = -1;
for (l1 = 0; l1 < 512; l1++) {
cpu_physical_memory_read_debug(pml4_addr + l1 * 8, &pml4e, 8);
- pml4e = le64_to_cpu(pml4e);
+ pml4e = le64_to_cpu(pml4e & me_mask);
end = l1 << 39;
if (pml4e & PG_PRESENT_MASK) {
pdp_addr = pml4e & 0x3fffffffff000ULL;
for (l2 = 0; l2 < 512; l2++) {
cpu_physical_memory_read_debug(pdp_addr + l2 * 8, &pdpe, 8);
- pdpe = le64_to_cpu(pdpe);
+ pdpe = le64_to_cpu(pdpe & me_mask);
end = (l1 << 39) + (l2 << 30);
if (pdpe & PG_PRESENT_MASK) {
if (pdpe & PG_PSE_MASK) {
@@ -396,7 +413,7 @@ static void mem_info_la48(Monitor *mon, CPUArchState *env)
for (l3 = 0; l3 < 512; l3++) {
cpu_physical_memory_read_debug(pd_addr + l3 * 8,
&pde, 8);
- pde = le64_to_cpu(pde);
+ pde = le64_to_cpu(pde & me_mask);
end = (l1 << 39) + (l2 << 30) + (l3 << 21);
if (pde & PG_PRESENT_MASK) {
if (pde & PG_PSE_MASK) {
@@ -410,7 +427,7 @@ static void mem_info_la48(Monitor *mon, CPUArchState *env)
cpu_physical_memory_read_debug(pt_addr
+ l4 * 8,
&pte, 8);
- pte = le64_to_cpu(pte);
+ pte = le64_to_cpu(pte & me_mask);
end = (l1 << 39) + (l2 << 30) +
(l3 << 21) + (l4 << 12);
if (pte & PG_PRESENT_MASK) {
@@ -449,13 +466,16 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env)
uint64_t l0, l1, l2, l3, l4;
uint64_t pml5e, pml4e, pdpe, pde, pte;
uint64_t pml5_addr, pml4_addr, pdp_addr, pd_addr, pt_addr, start, end;
+ uint64_t me_mask;
+
+ me_mask = sev_get_me_mask();
- pml5_addr = env->cr[3] & 0x3fffffffff000ULL;
+ pml5_addr = env->cr[3] & 0x3fffffffff000ULL & me_mask;
last_prot = 0;
start = -1;
for (l0 = 0; l0 < 512; l0++) {
cpu_physical_memory_read_debug(pml5_addr + l0 * 8, &pml5e, 8);
- pml5e = le64_to_cpu(pml5e);
+ pml5e = le64_to_cpu(pml5e & me_mask);
end = l0 << 48;
if (!(pml5e & PG_PRESENT_MASK)) {
prot = 0;
@@ -466,7 +486,7 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env)
pml4_addr = pml5e & 0x3fffffffff000ULL;
for (l1 = 0; l1 < 512; l1++) {
cpu_physical_memory_read_debug(pml4_addr + l1 * 8, &pml4e, 8);
- pml4e = le64_to_cpu(pml4e);
+ pml4e = le64_to_cpu(pml4e & me_mask);
end = (l0 << 48) + (l1 << 39);
if (!(pml4e & PG_PRESENT_MASK)) {
prot = 0;
@@ -477,7 +497,7 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env)
pdp_addr = pml4e & 0x3fffffffff000ULL;
for (l2 = 0; l2 < 512; l2++) {
cpu_physical_memory_read_debug(pdp_addr + l2 * 8, &pdpe, 8);
- pdpe = le64_to_cpu(pdpe);
+ pdpe = le64_to_cpu(pdpe & me_mask);
end = (l0 << 48) + (l1 << 39) + (l2 << 30);
if (pdpe & PG_PRESENT_MASK) {
prot = 0;
@@ -496,7 +516,7 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env)
pd_addr = pdpe & 0x3fffffffff000ULL;
for (l3 = 0; l3 < 512; l3++) {
cpu_physical_memory_read_debug(pd_addr + l3 * 8, &pde, 8);
- pde = le64_to_cpu(pde);
+ pde = le64_to_cpu(pde & me_mask);
end = (l0 << 48) + (l1 << 39) + (l2 << 30) + (l3 << 21);
if (pde & PG_PRESENT_MASK) {
prot = 0;
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH v12 23/28] qmp: add query-sev-launch-measure command
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
@ 2018-03-08 12:48 ` Brijesh Singh
-1 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:48 UTC (permalink / raw)
To: qemu-devel
Cc: Peter Maydell, Brijesh Singh, kvm, Michael S. Tsirkin,
Stefan Hajnoczi, Alexander Graf, Edgar E. Iglesias,
Markus Armbruster, Bruce Rogers, Christian Borntraeger,
Marcel Apfelbaum, Borislav Petkov, Thomas Lendacky,
Eduardo Habkost, Richard Henderson, Dr. David Alan Gilbert,
Alistair Francis, Cornelia Huck, Peter Crosthwaite,
Paolo Bonzini
The command can be used by libvirt to retrieve the measurement of SEV guest.
This measurement is a signature of the memory contents that was encrypted
through the LAUNCH_UPDATE_DATA.
Cc: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
monitor.c | 7 +++++++
qapi/misc.json | 29 +++++++++++++++++++++++++++++
target/i386/monitor.c | 17 +++++++++++++++++
3 files changed, 53 insertions(+)
diff --git a/monitor.c b/monitor.c
index 2225cf5030dc..d53ecc5ddab3 100644
--- a/monitor.c
+++ b/monitor.c
@@ -984,6 +984,7 @@ static void qmp_unregister_commands_hack(void)
#ifndef TARGET_I386
qmp_unregister_command(&qmp_commands, "rtc-reset-reinjection");
qmp_unregister_command(&qmp_commands, "query-sev");
+ qmp_unregister_command(&qmp_commands, "query-sev-launch-measure");
#endif
#ifndef TARGET_S390X
qmp_unregister_command(&qmp_commands, "dump-skeys");
@@ -4110,6 +4111,12 @@ SevInfo *qmp_query_sev(Error **errp)
error_setg(errp, QERR_FEATURE_DISABLED, "query-sev");
return NULL;
}
+
+SevLaunchMeasureInfo *qmp_query_sev_launch_measure(Error **errp)
+{
+ error_setg(errp, QERR_FEATURE_DISABLED, "query-sev-launch-measure");
+ return NULL;
+}
#endif
#ifndef TARGET_S390X
diff --git a/qapi/misc.json b/qapi/misc.json
index 14681729f8fc..a39c43aa64b1 100644
--- a/qapi/misc.json
+++ b/qapi/misc.json
@@ -3277,3 +3277,32 @@
#
##
{ 'command': 'query-sev', 'returns': 'SevInfo' }
+
+##
+# @SevLaunchMeasureInfo:
+#
+# SEV Guest Launch measurement information
+#
+# @data: the measurement value encoded in base64
+#
+# Since: 2.12
+#
+##
+{ 'struct': 'SevLaunchMeasureInfo', 'data': {'data': 'str'} }
+
+##
+# @query-sev-launch-measure:
+#
+# Query the SEV guest launch information.
+#
+# Returns: The @SevLaunchMeasureInfo for the guest
+#
+# Since: 2.12
+#
+# Example:
+#
+# -> { "execute": "query-sev-launch-measure" }
+# <- { "return": { "data": "4l8LXeNlSPUDlXPJG5966/8%YZ" } }
+#
+##
+{ 'command': 'query-sev-launch-measure', 'returns': 'SevLaunchMeasureInfo' }
diff --git a/target/i386/monitor.c b/target/i386/monitor.c
index 7df31c3cdf1b..e5596bbc0fc2 100644
--- a/target/i386/monitor.c
+++ b/target/i386/monitor.c
@@ -720,3 +720,20 @@ void hmp_info_sev(Monitor *mon, const QDict *qdict)
monitor_printf(mon, "SEV is not enabled\n");
}
}
+
+SevLaunchMeasureInfo *qmp_query_sev_launch_measure(Error **errp)
+{
+ char *data;
+ SevLaunchMeasureInfo *info;
+
+ data = sev_get_launch_measurement();
+ if (!data) {
+ error_setg(errp, "Measurement is not available");
+ return NULL;
+ }
+
+ info = g_malloc0(sizeof(*info));
+ info->data = data;
+
+ return info;
+}
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [Qemu-devel] [PATCH v12 23/28] qmp: add query-sev-launch-measure command
@ 2018-03-08 12:48 ` Brijesh Singh
0 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:48 UTC (permalink / raw)
To: qemu-devel
Cc: Alistair Francis, Christian Borntraeger, Cornelia Huck,
Daniel P . Berrange, Dr. David Alan Gilbert, Michael S. Tsirkin,
Edgar E. Iglesias, Eduardo Habkost, Eric Blake, kvm,
Marcel Apfelbaum, Markus Armbruster, Paolo Bonzini,
Peter Crosthwaite, Peter Maydell, Richard Henderson,
Stefan Hajnoczi, Thomas Lendacky, Borislav Petkov,
Alexander Graf, Bruce Rogers, Brijesh Singh
The command can be used by libvirt to retrieve the measurement of SEV guest.
This measurement is a signature of the memory contents that was encrypted
through the LAUNCH_UPDATE_DATA.
Cc: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
monitor.c | 7 +++++++
qapi/misc.json | 29 +++++++++++++++++++++++++++++
target/i386/monitor.c | 17 +++++++++++++++++
3 files changed, 53 insertions(+)
diff --git a/monitor.c b/monitor.c
index 2225cf5030dc..d53ecc5ddab3 100644
--- a/monitor.c
+++ b/monitor.c
@@ -984,6 +984,7 @@ static void qmp_unregister_commands_hack(void)
#ifndef TARGET_I386
qmp_unregister_command(&qmp_commands, "rtc-reset-reinjection");
qmp_unregister_command(&qmp_commands, "query-sev");
+ qmp_unregister_command(&qmp_commands, "query-sev-launch-measure");
#endif
#ifndef TARGET_S390X
qmp_unregister_command(&qmp_commands, "dump-skeys");
@@ -4110,6 +4111,12 @@ SevInfo *qmp_query_sev(Error **errp)
error_setg(errp, QERR_FEATURE_DISABLED, "query-sev");
return NULL;
}
+
+SevLaunchMeasureInfo *qmp_query_sev_launch_measure(Error **errp)
+{
+ error_setg(errp, QERR_FEATURE_DISABLED, "query-sev-launch-measure");
+ return NULL;
+}
#endif
#ifndef TARGET_S390X
diff --git a/qapi/misc.json b/qapi/misc.json
index 14681729f8fc..a39c43aa64b1 100644
--- a/qapi/misc.json
+++ b/qapi/misc.json
@@ -3277,3 +3277,32 @@
#
##
{ 'command': 'query-sev', 'returns': 'SevInfo' }
+
+##
+# @SevLaunchMeasureInfo:
+#
+# SEV Guest Launch measurement information
+#
+# @data: the measurement value encoded in base64
+#
+# Since: 2.12
+#
+##
+{ 'struct': 'SevLaunchMeasureInfo', 'data': {'data': 'str'} }
+
+##
+# @query-sev-launch-measure:
+#
+# Query the SEV guest launch information.
+#
+# Returns: The @SevLaunchMeasureInfo for the guest
+#
+# Since: 2.12
+#
+# Example:
+#
+# -> { "execute": "query-sev-launch-measure" }
+# <- { "return": { "data": "4l8LXeNlSPUDlXPJG5966/8%YZ" } }
+#
+##
+{ 'command': 'query-sev-launch-measure', 'returns': 'SevLaunchMeasureInfo' }
diff --git a/target/i386/monitor.c b/target/i386/monitor.c
index 7df31c3cdf1b..e5596bbc0fc2 100644
--- a/target/i386/monitor.c
+++ b/target/i386/monitor.c
@@ -720,3 +720,20 @@ void hmp_info_sev(Monitor *mon, const QDict *qdict)
monitor_printf(mon, "SEV is not enabled\n");
}
}
+
+SevLaunchMeasureInfo *qmp_query_sev_launch_measure(Error **errp)
+{
+ char *data;
+ SevLaunchMeasureInfo *info;
+
+ data = sev_get_launch_measurement();
+ if (!data) {
+ error_setg(errp, "Measurement is not available");
+ return NULL;
+ }
+
+ info = g_malloc0(sizeof(*info));
+ info->data = data;
+
+ return info;
+}
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH v12 24/28] sev/i386: add migration blocker
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
@ 2018-03-08 12:48 ` Brijesh Singh
-1 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:48 UTC (permalink / raw)
To: qemu-devel
Cc: Peter Maydell, Brijesh Singh, kvm, Michael S. Tsirkin,
Stefan Hajnoczi, Alexander Graf, Edgar E. Iglesias,
Markus Armbruster, Bruce Rogers, Christian Borntraeger,
Marcel Apfelbaum, Borislav Petkov, Thomas Lendacky,
Eduardo Habkost, Richard Henderson, Dr. David Alan Gilbert,
Alistair Francis, Cornelia Huck, Peter Crosthwaite,
Paolo Bonzini
SEV guest migration is not implemented yet.
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
---
target/i386/sev.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/target/i386/sev.c b/target/i386/sev.c
index f687e9e40e32..b9bfce95246a 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -24,12 +24,14 @@
#include "sev_i386.h"
#include "sysemu/sysemu.h"
#include "trace.h"
+#include "migration/blocker.h"
#define DEFAULT_GUEST_POLICY 0x1 /* disable debug */
#define DEFAULT_SEV_DEVICE "/dev/sev"
static SEVState *sev_state;
static MemoryRegionRAMReadWriteOps sev_ops;
+static Error *sev_mig_blocker;
static const char *const sev_fw_errlist[] = {
"",
@@ -583,6 +585,7 @@ static void
sev_launch_finish(SEVState *s)
{
int ret, error;
+ Error *local_err = NULL;
trace_kvm_sev_launch_finish();
ret = sev_ioctl(sev_state->sev_fd, KVM_SEV_LAUNCH_FINISH, 0, &error);
@@ -593,6 +596,16 @@ sev_launch_finish(SEVState *s)
}
sev_set_guest_state(SEV_STATE_RUNNING);
+
+ /* add migration blocker */
+ error_setg(&sev_mig_blocker,
+ "SEV: Migration is not implemented");
+ ret = migrate_add_blocker(sev_mig_blocker, &local_err);
+ if (local_err) {
+ error_report_err(local_err);
+ error_free(sev_mig_blocker);
+ exit(1);
+ }
}
static void
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [Qemu-devel] [PATCH v12 24/28] sev/i386: add migration blocker
@ 2018-03-08 12:48 ` Brijesh Singh
0 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:48 UTC (permalink / raw)
To: qemu-devel
Cc: Alistair Francis, Christian Borntraeger, Cornelia Huck,
Daniel P . Berrange, Dr. David Alan Gilbert, Michael S. Tsirkin,
Edgar E. Iglesias, Eduardo Habkost, Eric Blake, kvm,
Marcel Apfelbaum, Markus Armbruster, Paolo Bonzini,
Peter Crosthwaite, Peter Maydell, Richard Henderson,
Stefan Hajnoczi, Thomas Lendacky, Borislav Petkov,
Alexander Graf, Bruce Rogers, Brijesh Singh
SEV guest migration is not implemented yet.
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
---
target/i386/sev.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/target/i386/sev.c b/target/i386/sev.c
index f687e9e40e32..b9bfce95246a 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -24,12 +24,14 @@
#include "sev_i386.h"
#include "sysemu/sysemu.h"
#include "trace.h"
+#include "migration/blocker.h"
#define DEFAULT_GUEST_POLICY 0x1 /* disable debug */
#define DEFAULT_SEV_DEVICE "/dev/sev"
static SEVState *sev_state;
static MemoryRegionRAMReadWriteOps sev_ops;
+static Error *sev_mig_blocker;
static const char *const sev_fw_errlist[] = {
"",
@@ -583,6 +585,7 @@ static void
sev_launch_finish(SEVState *s)
{
int ret, error;
+ Error *local_err = NULL;
trace_kvm_sev_launch_finish();
ret = sev_ioctl(sev_state->sev_fd, KVM_SEV_LAUNCH_FINISH, 0, &error);
@@ -593,6 +596,16 @@ sev_launch_finish(SEVState *s)
}
sev_set_guest_state(SEV_STATE_RUNNING);
+
+ /* add migration blocker */
+ error_setg(&sev_mig_blocker,
+ "SEV: Migration is not implemented");
+ ret = migrate_add_blocker(sev_mig_blocker, &local_err);
+ if (local_err) {
+ error_report_err(local_err);
+ error_free(sev_mig_blocker);
+ exit(1);
+ }
}
static void
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH v12 25/28] cpu/i386: populate CPUID 0x8000_001F when SEV is active
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
@ 2018-03-08 12:48 ` Brijesh Singh
-1 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:48 UTC (permalink / raw)
To: qemu-devel
Cc: Peter Maydell, Brijesh Singh, kvm, Michael S. Tsirkin,
Stefan Hajnoczi, Alexander Graf, Edgar E. Iglesias,
Markus Armbruster, Bruce Rogers, Christian Borntraeger,
Marcel Apfelbaum, Borislav Petkov, Thomas Lendacky,
Eduardo Habkost, Richard Henderson, Dr. David Alan Gilbert,
Alistair Francis, Cornelia Huck, Richard Henderson,
Peter Crosthwaite, Paolo Bonzini
When SEV is enabled, CPUID 0x8000_001F should provide additional
information regarding the feature (such as which page table bit is used
to mark the pages as encrypted etc).
The details for memory encryption CPUID is available in AMD APM
(https://support.amd.com/TechDocs/24594.pdf) Section E.4.17
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
target/i386/cpu.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 2c04645ceac9..647f792ba123 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -26,6 +26,7 @@
#include "sysemu/hvf.h"
#include "sysemu/cpus.h"
#include "kvm_i386.h"
+#include "sev_i386.h"
#include "qemu/error-report.h"
#include "qemu/option.h"
@@ -3612,6 +3613,13 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count,
*ecx = 0;
*edx = 0;
break;
+ case 0x8000001F:
+ *eax = sev_enabled() ? 0x2 : 0;
+ *ebx = sev_get_cbit_position();
+ *ebx |= sev_get_reduced_phys_bits() << 6;
+ *ecx = 0;
+ *edx = 0;
+ break;
default:
/* reserved values: zero */
*eax = 0;
@@ -4041,6 +4049,11 @@ static void x86_cpu_expand_features(X86CPU *cpu, Error **errp)
if (env->features[FEAT_8000_0001_ECX] & CPUID_EXT3_SVM) {
x86_cpu_adjust_level(cpu, &env->cpuid_min_xlevel, 0x8000000A);
}
+
+ /* SEV requires CPUID[0x8000001F] */
+ if (sev_enabled()) {
+ x86_cpu_adjust_level(cpu, &env->cpuid_min_xlevel, 0x8000001F);
+ }
}
/* Set cpuid_*level* based on cpuid_min_*level, if not explicitly set */
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [Qemu-devel] [PATCH v12 25/28] cpu/i386: populate CPUID 0x8000_001F when SEV is active
@ 2018-03-08 12:48 ` Brijesh Singh
0 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:48 UTC (permalink / raw)
To: qemu-devel
Cc: Alistair Francis, Christian Borntraeger, Cornelia Huck,
Daniel P . Berrange, Dr. David Alan Gilbert, Michael S. Tsirkin,
Edgar E. Iglesias, Eduardo Habkost, Eric Blake, kvm,
Marcel Apfelbaum, Markus Armbruster, Paolo Bonzini,
Peter Crosthwaite, Peter Maydell, Richard Henderson,
Stefan Hajnoczi, Thomas Lendacky, Borislav Petkov,
Alexander Graf, Bruce Rogers, Brijesh Singh, Richard Henderson
When SEV is enabled, CPUID 0x8000_001F should provide additional
information regarding the feature (such as which page table bit is used
to mark the pages as encrypted etc).
The details for memory encryption CPUID is available in AMD APM
(https://support.amd.com/TechDocs/24594.pdf) Section E.4.17
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
target/i386/cpu.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 2c04645ceac9..647f792ba123 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -26,6 +26,7 @@
#include "sysemu/hvf.h"
#include "sysemu/cpus.h"
#include "kvm_i386.h"
+#include "sev_i386.h"
#include "qemu/error-report.h"
#include "qemu/option.h"
@@ -3612,6 +3613,13 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count,
*ecx = 0;
*edx = 0;
break;
+ case 0x8000001F:
+ *eax = sev_enabled() ? 0x2 : 0;
+ *ebx = sev_get_cbit_position();
+ *ebx |= sev_get_reduced_phys_bits() << 6;
+ *ecx = 0;
+ *edx = 0;
+ break;
default:
/* reserved values: zero */
*eax = 0;
@@ -4041,6 +4049,11 @@ static void x86_cpu_expand_features(X86CPU *cpu, Error **errp)
if (env->features[FEAT_8000_0001_ECX] & CPUID_EXT3_SVM) {
x86_cpu_adjust_level(cpu, &env->cpuid_min_xlevel, 0x8000000A);
}
+
+ /* SEV requires CPUID[0x8000001F] */
+ if (sev_enabled()) {
+ x86_cpu_adjust_level(cpu, &env->cpuid_min_xlevel, 0x8000001F);
+ }
}
/* Set cpuid_*level* based on cpuid_min_*level, if not explicitly set */
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH v12 26/28] qmp: add query-sev-capabilities command
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
@ 2018-03-08 12:48 ` Brijesh Singh
-1 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:48 UTC (permalink / raw)
To: qemu-devel
Cc: Peter Maydell, Brijesh Singh, kvm, Michael S. Tsirkin,
Stefan Hajnoczi, Alexander Graf, Edgar E. Iglesias,
Markus Armbruster, Bruce Rogers, Christian Borntraeger,
Marcel Apfelbaum, Borislav Petkov, Thomas Lendacky,
Eduardo Habkost, Richard Henderson, Dr. David Alan Gilbert,
Alistair Francis, Cornelia Huck, Peter Crosthwaite,
Paolo Bonzini
The command can be used by libvirt to query the SEV capabilities.
Cc: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
monitor.c | 7 +++++++
qapi/misc.json | 42 ++++++++++++++++++++++++++++++++++++++++++
target/i386/monitor.c | 6 ++++++
3 files changed, 55 insertions(+)
diff --git a/monitor.c b/monitor.c
index d53ecc5ddab3..29ce695a80d5 100644
--- a/monitor.c
+++ b/monitor.c
@@ -985,6 +985,7 @@ static void qmp_unregister_commands_hack(void)
qmp_unregister_command(&qmp_commands, "rtc-reset-reinjection");
qmp_unregister_command(&qmp_commands, "query-sev");
qmp_unregister_command(&qmp_commands, "query-sev-launch-measure");
+ qmp_unregister_command(&qmp_commands, "query-sev-capabilities");
#endif
#ifndef TARGET_S390X
qmp_unregister_command(&qmp_commands, "dump-skeys");
@@ -4117,6 +4118,12 @@ SevLaunchMeasureInfo *qmp_query_sev_launch_measure(Error **errp)
error_setg(errp, QERR_FEATURE_DISABLED, "query-sev-launch-measure");
return NULL;
}
+
+SevCapability *qmp_query_sev_capabilities(Error **errp)
+{
+ error_setg(errp, QERR_FEATURE_DISABLED, "query-sev-capabilities");
+ return NULL;
+}
#endif
#ifndef TARGET_S390X
diff --git a/qapi/misc.json b/qapi/misc.json
index a39c43aa64b1..37c89663d8f4 100644
--- a/qapi/misc.json
+++ b/qapi/misc.json
@@ -3306,3 +3306,45 @@
#
##
{ 'command': 'query-sev-launch-measure', 'returns': 'SevLaunchMeasureInfo' }
+
+##
+# @SevCapability:
+#
+# The struct describes capability for a Secure Encrypted Virtualization
+# feature.
+#
+# @pdh: Platform Diffie-Hellman key
+#
+# @cert-chain: PDH certificate chain
+#
+# @cbitpos: C-bit location in page table entry
+#
+# @reduced-phys-bits: Number of physical Address bit reduction when SEV is
+# enabled
+#
+# Since: 2.12
+##
+{ 'struct': 'SevCapability',
+ 'data': { 'pdh': 'str',
+ 'cert-chain': 'str',
+ 'cbitpos': 'int',
+ 'reduced-phys-bits': 'int'} }
+
+##
+# @query-sev-capabilities:
+#
+# This command is used to get the SEV capabilities, and is supported on AMD
+# X86 platforms only.
+#
+# Returns: SevCapability objects.
+#
+# Since: 2.12
+#
+# Example:
+#
+# -> { "execute": "query-sev-capabilities" }
+# <- { "return": { "pdh": "8CCDD8DDD", "cert-chain": "888CCCDDDEE",
+# "cbitpos": 47, "reduced-phys-bits": 5}}
+#
+##
+{ 'command': 'query-sev-capabilities', 'returns': 'SevCapability' }
diff --git a/target/i386/monitor.c b/target/i386/monitor.c
index e5596bbc0fc2..33e6bade693b 100644
--- a/target/i386/monitor.c
+++ b/target/i386/monitor.c
@@ -737,3 +737,9 @@ SevLaunchMeasureInfo *qmp_query_sev_launch_measure(Error **errp)
return info;
}
+
+SevCapability *qmp_query_sev_capabilities(Error **errp)
+{
+ error_setg(errp, "SEV feature is not available");
+ return NULL;
+}
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [Qemu-devel] [PATCH v12 26/28] qmp: add query-sev-capabilities command
@ 2018-03-08 12:48 ` Brijesh Singh
0 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:48 UTC (permalink / raw)
To: qemu-devel
Cc: Alistair Francis, Christian Borntraeger, Cornelia Huck,
Daniel P . Berrange, Dr. David Alan Gilbert, Michael S. Tsirkin,
Edgar E. Iglesias, Eduardo Habkost, Eric Blake, kvm,
Marcel Apfelbaum, Markus Armbruster, Paolo Bonzini,
Peter Crosthwaite, Peter Maydell, Richard Henderson,
Stefan Hajnoczi, Thomas Lendacky, Borislav Petkov,
Alexander Graf, Bruce Rogers, Brijesh Singh
The command can be used by libvirt to query the SEV capabilities.
Cc: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
monitor.c | 7 +++++++
qapi/misc.json | 42 ++++++++++++++++++++++++++++++++++++++++++
target/i386/monitor.c | 6 ++++++
3 files changed, 55 insertions(+)
diff --git a/monitor.c b/monitor.c
index d53ecc5ddab3..29ce695a80d5 100644
--- a/monitor.c
+++ b/monitor.c
@@ -985,6 +985,7 @@ static void qmp_unregister_commands_hack(void)
qmp_unregister_command(&qmp_commands, "rtc-reset-reinjection");
qmp_unregister_command(&qmp_commands, "query-sev");
qmp_unregister_command(&qmp_commands, "query-sev-launch-measure");
+ qmp_unregister_command(&qmp_commands, "query-sev-capabilities");
#endif
#ifndef TARGET_S390X
qmp_unregister_command(&qmp_commands, "dump-skeys");
@@ -4117,6 +4118,12 @@ SevLaunchMeasureInfo *qmp_query_sev_launch_measure(Error **errp)
error_setg(errp, QERR_FEATURE_DISABLED, "query-sev-launch-measure");
return NULL;
}
+
+SevCapability *qmp_query_sev_capabilities(Error **errp)
+{
+ error_setg(errp, QERR_FEATURE_DISABLED, "query-sev-capabilities");
+ return NULL;
+}
#endif
#ifndef TARGET_S390X
diff --git a/qapi/misc.json b/qapi/misc.json
index a39c43aa64b1..37c89663d8f4 100644
--- a/qapi/misc.json
+++ b/qapi/misc.json
@@ -3306,3 +3306,45 @@
#
##
{ 'command': 'query-sev-launch-measure', 'returns': 'SevLaunchMeasureInfo' }
+
+##
+# @SevCapability:
+#
+# The struct describes capability for a Secure Encrypted Virtualization
+# feature.
+#
+# @pdh: Platform Diffie-Hellman key
+#
+# @cert-chain: PDH certificate chain
+#
+# @cbitpos: C-bit location in page table entry
+#
+# @reduced-phys-bits: Number of physical Address bit reduction when SEV is
+# enabled
+#
+# Since: 2.12
+##
+{ 'struct': 'SevCapability',
+ 'data': { 'pdh': 'str',
+ 'cert-chain': 'str',
+ 'cbitpos': 'int',
+ 'reduced-phys-bits': 'int'} }
+
+##
+# @query-sev-capabilities:
+#
+# This command is used to get the SEV capabilities, and is supported on AMD
+# X86 platforms only.
+#
+# Returns: SevCapability objects.
+#
+# Since: 2.12
+#
+# Example:
+#
+# -> { "execute": "query-sev-capabilities" }
+# <- { "return": { "pdh": "8CCDD8DDD", "cert-chain": "888CCCDDDEE",
+# "cbitpos": 47, "reduced-phys-bits": 5}}
+#
+##
+{ 'command': 'query-sev-capabilities', 'returns': 'SevCapability' }
diff --git a/target/i386/monitor.c b/target/i386/monitor.c
index e5596bbc0fc2..33e6bade693b 100644
--- a/target/i386/monitor.c
+++ b/target/i386/monitor.c
@@ -737,3 +737,9 @@ SevLaunchMeasureInfo *qmp_query_sev_launch_measure(Error **errp)
return info;
}
+
+SevCapability *qmp_query_sev_capabilities(Error **errp)
+{
+ error_setg(errp, "SEV feature is not available");
+ return NULL;
+}
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH v12 27/28] sev/i386: add sev_get_capabilities()
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
@ 2018-03-08 12:49 ` Brijesh Singh
-1 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:49 UTC (permalink / raw)
To: qemu-devel
Cc: Peter Maydell, Brijesh Singh, kvm, Michael S. Tsirkin,
Stefan Hajnoczi, Alexander Graf, Edgar E. Iglesias,
Markus Armbruster, Bruce Rogers, Christian Borntraeger,
Marcel Apfelbaum, Borislav Petkov, Thomas Lendacky,
Eduardo Habkost, Richard Henderson, Dr. David Alan Gilbert,
Alistair Francis, Cornelia Huck, Richard Henderson,
Peter Crosthwaite, Paolo Bonzini
The function can be used to get the current SEV capabilities.
The capabilities include platform diffie-hellman key (pdh) and certificate
chain. The key can be provided to the external entities which wants to
establish a trusted channel between SEV firmware and guest owner.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
target/i386/monitor.c | 11 +++++--
target/i386/sev-stub.c | 5 +++
target/i386/sev.c | 83 ++++++++++++++++++++++++++++++++++++++++++++++++++
target/i386/sev_i386.h | 1 +
4 files changed, 98 insertions(+), 2 deletions(-)
diff --git a/target/i386/monitor.c b/target/i386/monitor.c
index 33e6bade693b..79fa9bd7a3e3 100644
--- a/target/i386/monitor.c
+++ b/target/i386/monitor.c
@@ -740,6 +740,13 @@ SevLaunchMeasureInfo *qmp_query_sev_launch_measure(Error **errp)
SevCapability *qmp_query_sev_capabilities(Error **errp)
{
- error_setg(errp, "SEV feature is not available");
- return NULL;
+ SevCapability *data;
+
+ data = sev_get_capabilities();
+ if (!data) {
+ error_setg(errp, "SEV feature is not available");
+ return NULL;
+ }
+
+ return data;
}
diff --git a/target/i386/sev-stub.c b/target/i386/sev-stub.c
index 2f61c32ec975..59a003a4ebe6 100644
--- a/target/i386/sev-stub.c
+++ b/target/i386/sev-stub.c
@@ -44,3 +44,8 @@ char *sev_get_launch_measurement(void)
{
return NULL;
}
+
+SevCapability *sev_get_capabilities(void)
+{
+ return NULL;
+}
diff --git a/target/i386/sev.c b/target/i386/sev.c
index b9bfce95246a..1d0cb8435e0f 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -427,6 +427,89 @@ sev_get_info(void)
return info;
}
+static int
+sev_get_pdh_info(int fd, guchar **pdh, size_t *pdh_len, guchar **cert_chain,
+ size_t *cert_chain_len)
+{
+ guchar *pdh_data, *cert_chain_data;
+ struct sev_user_data_pdh_cert_export export = {};
+ int err, r;
+
+ /* query the certificate length */
+ r = sev_platform_ioctl(fd, SEV_PDH_CERT_EXPORT, &export, &err);
+ if (r < 0) {
+ if (err != SEV_RET_INVALID_LEN) {
+ error_report("failed to export PDH cert ret=%d fw_err=%d (%s)",
+ r, err, fw_error_to_str(err));
+ return 1;
+ }
+ }
+
+ pdh_data = g_new(guchar, export.pdh_cert_len);
+ cert_chain_data = g_new(guchar, export.cert_chain_len);
+ export.pdh_cert_address = (unsigned long)pdh_data;
+ export.cert_chain_address = (unsigned long)cert_chain_data;
+
+ r = sev_platform_ioctl(fd, SEV_PDH_CERT_EXPORT, &export, &err);
+ if (r < 0) {
+ error_report("failed to export PDH cert ret=%d fw_err=%d (%s)",
+ r, err, fw_error_to_str(err));
+ goto e_free;
+ }
+
+ *pdh = pdh_data;
+ *pdh_len = export.pdh_cert_len;
+ *cert_chain = cert_chain_data;
+ *cert_chain_len = export.cert_chain_len;
+ return 0;
+
+e_free:
+ g_free(pdh_data);
+ g_free(cert_chain_data);
+ return 1;
+}
+
+SevCapability *
+sev_get_capabilities(void)
+{
+ SevCapability *cap;
+ guchar *pdh_data, *cert_chain_data;
+ size_t pdh_len = 0, cert_chain_len = 0;
+ uint32_t ebx;
+ int fd;
+
+ fd = open(DEFAULT_SEV_DEVICE, O_RDWR);
+ if (fd < 0) {
+ error_report("%s: Failed to open %s '%s'", __func__,
+ DEFAULT_SEV_DEVICE, strerror(errno));
+ return NULL;
+ }
+
+ if (sev_get_pdh_info(fd, &pdh_data, &pdh_len,
+ &cert_chain_data, &cert_chain_len)) {
+ return NULL;
+ }
+
+ cap = g_new0(SevCapability, 1);
+ cap->pdh = g_base64_encode(pdh_data, pdh_len);
+ cap->cert_chain = g_base64_encode(cert_chain_data, cert_chain_len);
+
+ host_cpuid(0x8000001F, 0, NULL, &ebx, NULL, NULL);
+ cap->cbitpos = ebx & 0x3f;
+
+ /*
+ * When SEV feature is enabled, we loose one bit in guest physical
+ * addressing.
+ */
+ cap->reduced_phys_bits = 1;
+
+ g_free(pdh_data);
+ g_free(cert_chain_data);
+
+ close(fd);
+ return cap;
+}
+
static int
sev_read_file_base64(const char *filename, guchar **data, gsize *len)
{
diff --git a/target/i386/sev_i386.h b/target/i386/sev_i386.h
index 6e370775770e..b8622dfb1e49 100644
--- a/target/i386/sev_i386.h
+++ b/target/i386/sev_i386.h
@@ -38,6 +38,7 @@ extern SevInfo *sev_get_info(void);
extern uint32_t sev_get_cbit_position(void);
extern uint32_t sev_get_reduced_phys_bits(void);
extern char *sev_get_launch_measurement(void);
+extern SevCapability *sev_get_capabilities(void);
typedef struct QSevGuestInfo QSevGuestInfo;
typedef struct QSevGuestInfoClass QSevGuestInfoClass;
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [Qemu-devel] [PATCH v12 27/28] sev/i386: add sev_get_capabilities()
@ 2018-03-08 12:49 ` Brijesh Singh
0 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:49 UTC (permalink / raw)
To: qemu-devel
Cc: Alistair Francis, Christian Borntraeger, Cornelia Huck,
Daniel P . Berrange, Dr. David Alan Gilbert, Michael S. Tsirkin,
Edgar E. Iglesias, Eduardo Habkost, Eric Blake, kvm,
Marcel Apfelbaum, Markus Armbruster, Paolo Bonzini,
Peter Crosthwaite, Peter Maydell, Richard Henderson,
Stefan Hajnoczi, Thomas Lendacky, Borislav Petkov,
Alexander Graf, Bruce Rogers, Brijesh Singh, Richard Henderson
The function can be used to get the current SEV capabilities.
The capabilities include platform diffie-hellman key (pdh) and certificate
chain. The key can be provided to the external entities which wants to
establish a trusted channel between SEV firmware and guest owner.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
target/i386/monitor.c | 11 +++++--
target/i386/sev-stub.c | 5 +++
target/i386/sev.c | 83 ++++++++++++++++++++++++++++++++++++++++++++++++++
target/i386/sev_i386.h | 1 +
4 files changed, 98 insertions(+), 2 deletions(-)
diff --git a/target/i386/monitor.c b/target/i386/monitor.c
index 33e6bade693b..79fa9bd7a3e3 100644
--- a/target/i386/monitor.c
+++ b/target/i386/monitor.c
@@ -740,6 +740,13 @@ SevLaunchMeasureInfo *qmp_query_sev_launch_measure(Error **errp)
SevCapability *qmp_query_sev_capabilities(Error **errp)
{
- error_setg(errp, "SEV feature is not available");
- return NULL;
+ SevCapability *data;
+
+ data = sev_get_capabilities();
+ if (!data) {
+ error_setg(errp, "SEV feature is not available");
+ return NULL;
+ }
+
+ return data;
}
diff --git a/target/i386/sev-stub.c b/target/i386/sev-stub.c
index 2f61c32ec975..59a003a4ebe6 100644
--- a/target/i386/sev-stub.c
+++ b/target/i386/sev-stub.c
@@ -44,3 +44,8 @@ char *sev_get_launch_measurement(void)
{
return NULL;
}
+
+SevCapability *sev_get_capabilities(void)
+{
+ return NULL;
+}
diff --git a/target/i386/sev.c b/target/i386/sev.c
index b9bfce95246a..1d0cb8435e0f 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -427,6 +427,89 @@ sev_get_info(void)
return info;
}
+static int
+sev_get_pdh_info(int fd, guchar **pdh, size_t *pdh_len, guchar **cert_chain,
+ size_t *cert_chain_len)
+{
+ guchar *pdh_data, *cert_chain_data;
+ struct sev_user_data_pdh_cert_export export = {};
+ int err, r;
+
+ /* query the certificate length */
+ r = sev_platform_ioctl(fd, SEV_PDH_CERT_EXPORT, &export, &err);
+ if (r < 0) {
+ if (err != SEV_RET_INVALID_LEN) {
+ error_report("failed to export PDH cert ret=%d fw_err=%d (%s)",
+ r, err, fw_error_to_str(err));
+ return 1;
+ }
+ }
+
+ pdh_data = g_new(guchar, export.pdh_cert_len);
+ cert_chain_data = g_new(guchar, export.cert_chain_len);
+ export.pdh_cert_address = (unsigned long)pdh_data;
+ export.cert_chain_address = (unsigned long)cert_chain_data;
+
+ r = sev_platform_ioctl(fd, SEV_PDH_CERT_EXPORT, &export, &err);
+ if (r < 0) {
+ error_report("failed to export PDH cert ret=%d fw_err=%d (%s)",
+ r, err, fw_error_to_str(err));
+ goto e_free;
+ }
+
+ *pdh = pdh_data;
+ *pdh_len = export.pdh_cert_len;
+ *cert_chain = cert_chain_data;
+ *cert_chain_len = export.cert_chain_len;
+ return 0;
+
+e_free:
+ g_free(pdh_data);
+ g_free(cert_chain_data);
+ return 1;
+}
+
+SevCapability *
+sev_get_capabilities(void)
+{
+ SevCapability *cap;
+ guchar *pdh_data, *cert_chain_data;
+ size_t pdh_len = 0, cert_chain_len = 0;
+ uint32_t ebx;
+ int fd;
+
+ fd = open(DEFAULT_SEV_DEVICE, O_RDWR);
+ if (fd < 0) {
+ error_report("%s: Failed to open %s '%s'", __func__,
+ DEFAULT_SEV_DEVICE, strerror(errno));
+ return NULL;
+ }
+
+ if (sev_get_pdh_info(fd, &pdh_data, &pdh_len,
+ &cert_chain_data, &cert_chain_len)) {
+ return NULL;
+ }
+
+ cap = g_new0(SevCapability, 1);
+ cap->pdh = g_base64_encode(pdh_data, pdh_len);
+ cap->cert_chain = g_base64_encode(cert_chain_data, cert_chain_len);
+
+ host_cpuid(0x8000001F, 0, NULL, &ebx, NULL, NULL);
+ cap->cbitpos = ebx & 0x3f;
+
+ /*
+ * When SEV feature is enabled, we loose one bit in guest physical
+ * addressing.
+ */
+ cap->reduced_phys_bits = 1;
+
+ g_free(pdh_data);
+ g_free(cert_chain_data);
+
+ close(fd);
+ return cap;
+}
+
static int
sev_read_file_base64(const char *filename, guchar **data, gsize *len)
{
diff --git a/target/i386/sev_i386.h b/target/i386/sev_i386.h
index 6e370775770e..b8622dfb1e49 100644
--- a/target/i386/sev_i386.h
+++ b/target/i386/sev_i386.h
@@ -38,6 +38,7 @@ extern SevInfo *sev_get_info(void);
extern uint32_t sev_get_cbit_position(void);
extern uint32_t sev_get_reduced_phys_bits(void);
extern char *sev_get_launch_measurement(void);
+extern SevCapability *sev_get_capabilities(void);
typedef struct QSevGuestInfo QSevGuestInfo;
typedef struct QSevGuestInfoClass QSevGuestInfoClass;
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH v12 28/28] tests/qmp-test: blacklist sev specific qmp commands
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
@ 2018-03-08 12:49 ` Brijesh Singh
-1 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:49 UTC (permalink / raw)
To: qemu-devel
Cc: Peter Maydell, Brijesh Singh, kvm, Michael S. Tsirkin,
Stefan Hajnoczi, Alexander Graf, Edgar E. Iglesias,
Markus Armbruster, Bruce Rogers, Christian Borntraeger,
Marcel Apfelbaum, Borislav Petkov, Thomas Lendacky,
Eduardo Habkost, Richard Henderson, Dr. David Alan Gilbert,
Alistair Francis, Cornelia Huck, Peter Crosthwaite,
Paolo Bonzini
Blacklist the following commands to fix the 'make check' failure.
query-sev-launch-measure: it returns meaninful data only when we launch
SEV guest otherwise the command returns an error.
query-sev: it return an error when SEV is not available on host (e.g non
X86 platform or KVM is disabled at the build time)
query-sev-capabilities: it returns an error when SEV feature is not
available on host machine.
Cc: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: Markus Armbruster <armbru@redhat.com>
Reviewed-by: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
tests/qmp-test.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/tests/qmp-test.c b/tests/qmp-test.c
index 22445d9ec258..7470c6b754bc 100644
--- a/tests/qmp-test.c
+++ b/tests/qmp-test.c
@@ -204,6 +204,11 @@ static bool query_is_blacklisted(const char *cmd)
"query-gic-capabilities", /* arm */
/* Success depends on target-specific build configuration: */
"query-pci", /* CONFIG_PCI */
+ /* Success depends on launching SEV guest */
+ "query-sev-launch-measure",
+ /* Success depends on Host or Hypervisor SEV support */
+ "query-sev",
+ "query-sev-capabilities",
NULL
};
int i;
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [Qemu-devel] [PATCH v12 28/28] tests/qmp-test: blacklist sev specific qmp commands
@ 2018-03-08 12:49 ` Brijesh Singh
0 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 12:49 UTC (permalink / raw)
To: qemu-devel
Cc: Alistair Francis, Christian Borntraeger, Cornelia Huck,
Daniel P . Berrange, Dr. David Alan Gilbert, Michael S. Tsirkin,
Edgar E. Iglesias, Eduardo Habkost, Eric Blake, kvm,
Marcel Apfelbaum, Markus Armbruster, Paolo Bonzini,
Peter Crosthwaite, Peter Maydell, Richard Henderson,
Stefan Hajnoczi, Thomas Lendacky, Borislav Petkov,
Alexander Graf, Bruce Rogers, Brijesh Singh
Blacklist the following commands to fix the 'make check' failure.
query-sev-launch-measure: it returns meaninful data only when we launch
SEV guest otherwise the command returns an error.
query-sev: it return an error when SEV is not available on host (e.g non
X86 platform or KVM is disabled at the build time)
query-sev-capabilities: it returns an error when SEV feature is not
available on host machine.
Cc: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: Markus Armbruster <armbru@redhat.com>
Reviewed-by: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
tests/qmp-test.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/tests/qmp-test.c b/tests/qmp-test.c
index 22445d9ec258..7470c6b754bc 100644
--- a/tests/qmp-test.c
+++ b/tests/qmp-test.c
@@ -204,6 +204,11 @@ static bool query_is_blacklisted(const char *cmd)
"query-gic-capabilities", /* arm */
/* Success depends on target-specific build configuration: */
"query-pci", /* CONFIG_PCI */
+ /* Success depends on launching SEV guest */
+ "query-sev-launch-measure",
+ /* Success depends on Host or Hypervisor SEV support */
+ "query-sev",
+ "query-sev-capabilities",
NULL
};
int i;
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* Re: [PATCH v12 05/28] machine: add -memory-encryption property
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
@ 2018-03-08 16:43 ` Daniel P. Berrangé
-1 siblings, 0 replies; 114+ messages in thread
From: Daniel P. Berrangé @ 2018-03-08 16:43 UTC (permalink / raw)
To: Brijesh Singh
Cc: Edgar E. Iglesias, Peter Maydell, Borislav Petkov,
Eduardo Habkost, kvm, Michael S. Tsirkin, Marcel Apfelbaum,
Markus Armbruster, Peter Crosthwaite, Richard Henderson,
qemu-devel, Dr. David Alan Gilbert, Christian Borntraeger,
Alexander Graf, Stefan Hajnoczi, Cornelia Huck, Paolo Bonzini,
Thomas Lendacky, Alistair Francis, Bruce Rogers
Nitpick: the subject makes it seem like you're adding
"-memory-encryption" as a CLI arg, but actually its
adding support for 'memory-encryption=$VAL' property
to the '-machine' CLI arg.
Sufficient to just s/-memory-encryption/"memory-encryption"/
On Thu, Mar 08, 2018 at 06:48:38AM -0600, Brijesh Singh wrote:
> When CPU supports memory encryption feature, the property can be used to
> specify the encryption object to use when launching an encrypted guest.
>
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Cc: Eduardo Habkost <ehabkost@redhat.com>
> Cc: Marcel Apfelbaum <marcel@redhat.com>
> Cc: Stefan Hajnoczi <stefanha@gmail.com>
> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
> ---
> hw/core/machine.c | 22 ++++++++++++++++++++++
> include/hw/boards.h | 1 +
> qemu-options.hx | 5 ++++-
> 3 files changed, 27 insertions(+), 1 deletion(-)
>
> diff --git a/hw/core/machine.c b/hw/core/machine.c
> index 5e2bbcdacedb..2040177664d5 100644
> --- a/hw/core/machine.c
> +++ b/hw/core/machine.c
> @@ -334,6 +334,22 @@ static bool machine_get_enforce_config_section(Object *obj, Error **errp)
> return ms->enforce_config_section;
> }
>
> +static char *machine_get_memory_encryption(Object *obj, Error **errp)
> +{
> + MachineState *ms = MACHINE(obj);
> +
> + return g_strdup(ms->memory_encryption);
> +}
> +
> +static void machine_set_memory_encryption(Object *obj, const char *value,
> + Error **errp)
> +{
> + MachineState *ms = MACHINE(obj);
> +
> + g_free(ms->memory_encryption);
> + ms->memory_encryption = g_strdup(value);
> +}
> +
> void machine_class_allow_dynamic_sysbus_dev(MachineClass *mc, const char *type)
> {
> strList *item = g_new0(strList, 1);
> @@ -612,6 +628,12 @@ static void machine_class_init(ObjectClass *oc, void *data)
> &error_abort);
> object_class_property_set_description(oc, "enforce-config-section",
> "Set on to enforce configuration section migration", &error_abort);
> +
> + object_class_property_add_str(oc, "memory-encryption",
> + machine_get_memory_encryption, machine_set_memory_encryption,
> + &error_abort);
> + object_class_property_set_description(oc, "memory-encryption",
> + "Set memory encyption object to use", &error_abort);
> }
>
> static void machine_class_base_init(ObjectClass *oc, void *data)
> diff --git a/include/hw/boards.h b/include/hw/boards.h
> index efb0a9edfdf1..8ce9a7a21d3d 100644
> --- a/include/hw/boards.h
> +++ b/include/hw/boards.h
> @@ -243,6 +243,7 @@ struct MachineState {
> bool suppress_vmdesc;
> bool enforce_config_section;
> bool enable_graphics;
> + char *memory_encryption;
>
> ram_addr_t ram_size;
> ram_addr_t maxram_size;
> diff --git a/qemu-options.hx b/qemu-options.hx
> index 6585058c6cde..4c280142c52c 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -43,7 +43,8 @@ DEF("machine", HAS_ARG, QEMU_OPTION_machine, \
> " suppress-vmdesc=on|off disables self-describing migration (default=off)\n"
> " nvdimm=on|off controls NVDIMM support (default=off)\n"
> " enforce-config-section=on|off enforce configuration section migration (default=off)\n"
> - " s390-squash-mcss=on|off (deprecated) controls support for squashing into default css (default=off)\n",
> + " s390-squash-mcss=on|off (deprecated) controls support for squashing into default css (default=off)\n"
> + " memory-encryption=@var{} memory encryption object to use (default=none)\n",
> QEMU_ARCH_ALL)
> STEXI
> @item -machine [type=]@var{name}[,prop=@var{value}[,...]]
> @@ -110,6 +111,8 @@ code to send configuration section even if the machine-type sets the
> @option{migration.send-configuration} property to @var{off}.
> NOTE: this parameter is deprecated. Please use @option{-global}
> @option{migration.send-configuration}=@var{on|off} instead.
> +@item memory-encryption=@var{}
> +Memory encryption object to use. The default is none.
> @end table
> ETEXI
>
> --
> 2.14.3
>
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [Qemu-devel] [PATCH v12 05/28] machine: add -memory-encryption property
@ 2018-03-08 16:43 ` Daniel P. Berrangé
0 siblings, 0 replies; 114+ messages in thread
From: Daniel P. Berrangé @ 2018-03-08 16:43 UTC (permalink / raw)
To: Brijesh Singh
Cc: qemu-devel, Alistair Francis, Christian Borntraeger,
Cornelia Huck, Dr. David Alan Gilbert, Michael S. Tsirkin,
Edgar E. Iglesias, Eduardo Habkost, Eric Blake, kvm,
Marcel Apfelbaum, Markus Armbruster, Paolo Bonzini,
Peter Crosthwaite, Peter Maydell, Richard Henderson,
Stefan Hajnoczi, Thomas Lendacky, Borislav Petkov,
Alexander Graf, Bruce Rogers
Nitpick: the subject makes it seem like you're adding
"-memory-encryption" as a CLI arg, but actually its
adding support for 'memory-encryption=$VAL' property
to the '-machine' CLI arg.
Sufficient to just s/-memory-encryption/"memory-encryption"/
On Thu, Mar 08, 2018 at 06:48:38AM -0600, Brijesh Singh wrote:
> When CPU supports memory encryption feature, the property can be used to
> specify the encryption object to use when launching an encrypted guest.
>
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Cc: Eduardo Habkost <ehabkost@redhat.com>
> Cc: Marcel Apfelbaum <marcel@redhat.com>
> Cc: Stefan Hajnoczi <stefanha@gmail.com>
> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
> ---
> hw/core/machine.c | 22 ++++++++++++++++++++++
> include/hw/boards.h | 1 +
> qemu-options.hx | 5 ++++-
> 3 files changed, 27 insertions(+), 1 deletion(-)
>
> diff --git a/hw/core/machine.c b/hw/core/machine.c
> index 5e2bbcdacedb..2040177664d5 100644
> --- a/hw/core/machine.c
> +++ b/hw/core/machine.c
> @@ -334,6 +334,22 @@ static bool machine_get_enforce_config_section(Object *obj, Error **errp)
> return ms->enforce_config_section;
> }
>
> +static char *machine_get_memory_encryption(Object *obj, Error **errp)
> +{
> + MachineState *ms = MACHINE(obj);
> +
> + return g_strdup(ms->memory_encryption);
> +}
> +
> +static void machine_set_memory_encryption(Object *obj, const char *value,
> + Error **errp)
> +{
> + MachineState *ms = MACHINE(obj);
> +
> + g_free(ms->memory_encryption);
> + ms->memory_encryption = g_strdup(value);
> +}
> +
> void machine_class_allow_dynamic_sysbus_dev(MachineClass *mc, const char *type)
> {
> strList *item = g_new0(strList, 1);
> @@ -612,6 +628,12 @@ static void machine_class_init(ObjectClass *oc, void *data)
> &error_abort);
> object_class_property_set_description(oc, "enforce-config-section",
> "Set on to enforce configuration section migration", &error_abort);
> +
> + object_class_property_add_str(oc, "memory-encryption",
> + machine_get_memory_encryption, machine_set_memory_encryption,
> + &error_abort);
> + object_class_property_set_description(oc, "memory-encryption",
> + "Set memory encyption object to use", &error_abort);
> }
>
> static void machine_class_base_init(ObjectClass *oc, void *data)
> diff --git a/include/hw/boards.h b/include/hw/boards.h
> index efb0a9edfdf1..8ce9a7a21d3d 100644
> --- a/include/hw/boards.h
> +++ b/include/hw/boards.h
> @@ -243,6 +243,7 @@ struct MachineState {
> bool suppress_vmdesc;
> bool enforce_config_section;
> bool enable_graphics;
> + char *memory_encryption;
>
> ram_addr_t ram_size;
> ram_addr_t maxram_size;
> diff --git a/qemu-options.hx b/qemu-options.hx
> index 6585058c6cde..4c280142c52c 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -43,7 +43,8 @@ DEF("machine", HAS_ARG, QEMU_OPTION_machine, \
> " suppress-vmdesc=on|off disables self-describing migration (default=off)\n"
> " nvdimm=on|off controls NVDIMM support (default=off)\n"
> " enforce-config-section=on|off enforce configuration section migration (default=off)\n"
> - " s390-squash-mcss=on|off (deprecated) controls support for squashing into default css (default=off)\n",
> + " s390-squash-mcss=on|off (deprecated) controls support for squashing into default css (default=off)\n"
> + " memory-encryption=@var{} memory encryption object to use (default=none)\n",
> QEMU_ARCH_ALL)
> STEXI
> @item -machine [type=]@var{name}[,prop=@var{value}[,...]]
> @@ -110,6 +111,8 @@ code to send configuration section even if the machine-type sets the
> @option{migration.send-configuration} property to @var{off}.
> NOTE: this parameter is deprecated. Please use @option{-global}
> @option{migration.send-configuration}=@var{on|off} instead.
> +@item memory-encryption=@var{}
> +Memory encryption object to use. The default is none.
> @end table
> ETEXI
>
> --
> 2.14.3
>
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v12 08/28] target/i386: add Secure Encrypted Virtulization (SEV) object
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
@ 2018-03-08 16:49 ` Daniel P. Berrangé
-1 siblings, 0 replies; 114+ messages in thread
From: Daniel P. Berrangé @ 2018-03-08 16:49 UTC (permalink / raw)
To: Brijesh Singh
Cc: Peter Maydell, kvm, Michael S. Tsirkin, Stefan Hajnoczi,
qemu-devel, Alexander Graf, Edgar E. Iglesias, Markus Armbruster,
Bruce Rogers, Christian Borntraeger, Marcel Apfelbaum,
Borislav Petkov, Thomas Lendacky, Eduardo Habkost,
Richard Henderson, Dr. David Alan Gilbert, Alistair Francis,
Cornelia Huck, Richard Henderson, Peter Crosthwaite,
Paolo Bonzini
On Thu, Mar 08, 2018 at 06:48:41AM -0600, Brijesh Singh wrote:
> Add a new memory encryption object 'sev-guest'. The object will be used
> to create enrypted VMs on AMD EPYC CPU. The object provides the properties
> to pass guest owner's public Diffie-hellman key, guest policy and session
> information required to create the memory encryption context within the
> SEV firmware.
>
> e.g to launch SEV guest
> # $QEMU \
> -object sev-guest,id=sev0 \
> -machine ....,memory-encryption=sev0
>
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Cc: Richard Henderson <rth@twiddle.net>
> Cc: Eduardo Habkost <ehabkost@redhat.com>
> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
> diff --git a/qemu-options.hx b/qemu-options.hx
> index 4c280142c52c..6113bce08a8c 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -4353,6 +4353,50 @@ contents of @code{iv.b64} to the second secret
> data=$SECRET,iv=$(<iv.b64)
> @end example
>
> +@item -object sev-guest,id=@var{id},cbitpos=@var{cbitpos},reduced-phys-bits=@var{val},[sev-device=@var{string},policy=@var{policy},handle=@var{handle},dh-cert-file=@var{file},session-file=@var{file}]
> +
> +Create a Secure Encrypted Virtualization (SEV) guest object, which can be used
> +to provide the guest memory encryption support on AMD processors.
> +
> +When memory encryption is enabled, one of the physical address bit (aka the
> +C-bit) is utilized to mark if a memory page is protected. The @option{cbitpos}
> +is used to provide the C-bit position. The C-bit position is Host family dependent
> +hence user must provide this value. On EPYC, the value should be 47.
> +
> +When memory encryption is enabled, we loose certain bits in physical address space.
> +The @option{reduced-phys-bits} is used to provide the number of bits we loose in
> +physical address space. Similar to C-bit, the value is Host family dependent.
> +On EPYC, the value should be 5.
Is it valid to specify a different value for either of these properties ?
eg what happens if I pass cbitpos=45 instead of 47 on an EPYC host ?
In particular I thinking about possible migration scenario, where EPYC
uses 47 by default but some $NEXT AMD CPU uses 48 by default. In that
case we might want to use '47' on both CPUs if we need ability to live
migrate between different host CPU generations. Would that be valid ?
On the flip side, if the value really it strictly tied to the host
CPU family and no deviation is permitted, could the kernel not just
pick the right value automatically avoiding the config option ?
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [Qemu-devel] [PATCH v12 08/28] target/i386: add Secure Encrypted Virtulization (SEV) object
@ 2018-03-08 16:49 ` Daniel P. Berrangé
0 siblings, 0 replies; 114+ messages in thread
From: Daniel P. Berrangé @ 2018-03-08 16:49 UTC (permalink / raw)
To: Brijesh Singh
Cc: qemu-devel, Alistair Francis, Christian Borntraeger,
Cornelia Huck, Dr. David Alan Gilbert, Michael S. Tsirkin,
Edgar E. Iglesias, Eduardo Habkost, Eric Blake, kvm,
Marcel Apfelbaum, Markus Armbruster, Paolo Bonzini,
Peter Crosthwaite, Peter Maydell, Richard Henderson,
Stefan Hajnoczi, Thomas Lendacky, Borislav Petkov,
Alexander Graf, Bruce Rogers, Richard Henderson
On Thu, Mar 08, 2018 at 06:48:41AM -0600, Brijesh Singh wrote:
> Add a new memory encryption object 'sev-guest'. The object will be used
> to create enrypted VMs on AMD EPYC CPU. The object provides the properties
> to pass guest owner's public Diffie-hellman key, guest policy and session
> information required to create the memory encryption context within the
> SEV firmware.
>
> e.g to launch SEV guest
> # $QEMU \
> -object sev-guest,id=sev0 \
> -machine ....,memory-encryption=sev0
>
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Cc: Richard Henderson <rth@twiddle.net>
> Cc: Eduardo Habkost <ehabkost@redhat.com>
> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
> diff --git a/qemu-options.hx b/qemu-options.hx
> index 4c280142c52c..6113bce08a8c 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -4353,6 +4353,50 @@ contents of @code{iv.b64} to the second secret
> data=$SECRET,iv=$(<iv.b64)
> @end example
>
> +@item -object sev-guest,id=@var{id},cbitpos=@var{cbitpos},reduced-phys-bits=@var{val},[sev-device=@var{string},policy=@var{policy},handle=@var{handle},dh-cert-file=@var{file},session-file=@var{file}]
> +
> +Create a Secure Encrypted Virtualization (SEV) guest object, which can be used
> +to provide the guest memory encryption support on AMD processors.
> +
> +When memory encryption is enabled, one of the physical address bit (aka the
> +C-bit) is utilized to mark if a memory page is protected. The @option{cbitpos}
> +is used to provide the C-bit position. The C-bit position is Host family dependent
> +hence user must provide this value. On EPYC, the value should be 47.
> +
> +When memory encryption is enabled, we loose certain bits in physical address space.
> +The @option{reduced-phys-bits} is used to provide the number of bits we loose in
> +physical address space. Similar to C-bit, the value is Host family dependent.
> +On EPYC, the value should be 5.
Is it valid to specify a different value for either of these properties ?
eg what happens if I pass cbitpos=45 instead of 47 on an EPYC host ?
In particular I thinking about possible migration scenario, where EPYC
uses 47 by default but some $NEXT AMD CPU uses 48 by default. In that
case we might want to use '47' on both CPUs if we need ability to live
migrate between different host CPU generations. Would that be valid ?
On the flip side, if the value really it strictly tied to the host
CPU family and no deviation is permitted, could the kernel not just
pick the right value automatically avoiding the config option ?
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v12 09/28] qmp: add query-sev command
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
@ 2018-03-08 16:52 ` Daniel P. Berrangé
-1 siblings, 0 replies; 114+ messages in thread
From: Daniel P. Berrangé @ 2018-03-08 16:52 UTC (permalink / raw)
To: Brijesh Singh
Cc: Edgar E. Iglesias, Peter Maydell, Borislav Petkov,
Eduardo Habkost, kvm, Michael S. Tsirkin, Marcel Apfelbaum,
Markus Armbruster, Peter Crosthwaite, Richard Henderson,
qemu-devel, Dr. David Alan Gilbert, Christian Borntraeger,
Alexander Graf, Stefan Hajnoczi, Cornelia Huck, Paolo Bonzini,
Thomas Lendacky, Alistair Francis, Bruce Rogers
On Thu, Mar 08, 2018 at 06:48:42AM -0600, Brijesh Singh wrote:
> The QMP query command can used to retrieve the SEV information when
> memory encryption is enabled on AMD platform.
>
> Cc: Eric Blake <eblake@redhat.com>
> Cc: "Daniel P. Berrangé" <berrange@redhat.com>
> Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
> Cc: Markus Armbruster <armbru@redhat.com>
> Reviewed-by: Eric Blake <eblake@redhat.com>
> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
> ---
> monitor.c | 7 +++++
> qapi/misc.json | 76 +++++++++++++++++++++++++++++++++++++++++++++++++++
> target/i386/monitor.c | 8 ++++++
> 3 files changed, 91 insertions(+)
> diff --git a/qapi/misc.json b/qapi/misc.json
> index bd04469a4ba2..14681729f8fc 100644
> --- a/qapi/misc.json
> +++ b/qapi/misc.json
> @@ -3201,3 +3201,79 @@
> # Since: 2.9
> ##
> { 'command': 'query-vm-generation-id', 'returns': 'GuidInfo' }
> +
> +
> +##
> +# @SevState:
> +#
> +# An enumeration of SEV state information used during @query-sev.
> +#
> +# @uninit: The guest is uninitialized.
> +#
> +# @lupdate: The guest is currently being launched and plaintext and
> +# reigster state is being imported.
Typo s/reigster/register/
> +#
> +# @lsecret: The guest is currently being launched and ciphertext data
> +# are being imported.
> +#
> +# @running: The guest is fully launched or migrated in.
> +#
> +# @supdate: The guest is currently being migrated out to another machine.
> +#
> +# @rupdate: The guest is currently being migrated from another machine.
> +#
> +# Since: 2.12
> +##
> +{ 'enum': 'SevState',
> + 'data': ['uninit', 'lupdate', 'lsecret', 'running', 'supdate', 'rupdate' ] }
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [Qemu-devel] [PATCH v12 09/28] qmp: add query-sev command
@ 2018-03-08 16:52 ` Daniel P. Berrangé
0 siblings, 0 replies; 114+ messages in thread
From: Daniel P. Berrangé @ 2018-03-08 16:52 UTC (permalink / raw)
To: Brijesh Singh
Cc: qemu-devel, Alistair Francis, Christian Borntraeger,
Cornelia Huck, Dr. David Alan Gilbert, Michael S. Tsirkin,
Edgar E. Iglesias, Eduardo Habkost, Eric Blake, kvm,
Marcel Apfelbaum, Markus Armbruster, Paolo Bonzini,
Peter Crosthwaite, Peter Maydell, Richard Henderson,
Stefan Hajnoczi, Thomas Lendacky, Borislav Petkov,
Alexander Graf, Bruce Rogers
On Thu, Mar 08, 2018 at 06:48:42AM -0600, Brijesh Singh wrote:
> The QMP query command can used to retrieve the SEV information when
> memory encryption is enabled on AMD platform.
>
> Cc: Eric Blake <eblake@redhat.com>
> Cc: "Daniel P. Berrangé" <berrange@redhat.com>
> Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
> Cc: Markus Armbruster <armbru@redhat.com>
> Reviewed-by: Eric Blake <eblake@redhat.com>
> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
> ---
> monitor.c | 7 +++++
> qapi/misc.json | 76 +++++++++++++++++++++++++++++++++++++++++++++++++++
> target/i386/monitor.c | 8 ++++++
> 3 files changed, 91 insertions(+)
> diff --git a/qapi/misc.json b/qapi/misc.json
> index bd04469a4ba2..14681729f8fc 100644
> --- a/qapi/misc.json
> +++ b/qapi/misc.json
> @@ -3201,3 +3201,79 @@
> # Since: 2.9
> ##
> { 'command': 'query-vm-generation-id', 'returns': 'GuidInfo' }
> +
> +
> +##
> +# @SevState:
> +#
> +# An enumeration of SEV state information used during @query-sev.
> +#
> +# @uninit: The guest is uninitialized.
> +#
> +# @lupdate: The guest is currently being launched and plaintext and
> +# reigster state is being imported.
Typo s/reigster/register/
> +#
> +# @lsecret: The guest is currently being launched and ciphertext data
> +# are being imported.
> +#
> +# @running: The guest is fully launched or migrated in.
> +#
> +# @supdate: The guest is currently being migrated out to another machine.
> +#
> +# @rupdate: The guest is currently being migrated from another machine.
> +#
> +# Since: 2.12
> +##
> +{ 'enum': 'SevState',
> + 'data': ['uninit', 'lupdate', 'lsecret', 'running', 'supdate', 'rupdate' ] }
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v12 10/28] include: add psp-sev.h header file
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
@ 2018-03-08 16:54 ` Daniel P. Berrangé
-1 siblings, 0 replies; 114+ messages in thread
From: Daniel P. Berrangé @ 2018-03-08 16:54 UTC (permalink / raw)
To: Brijesh Singh
Cc: Peter Maydell, kvm, Michael S. Tsirkin, Stefan Hajnoczi,
qemu-devel, Alexander Graf, Edgar E. Iglesias, Markus Armbruster,
Bruce Rogers, Christian Borntraeger, Marcel Apfelbaum,
Borislav Petkov, Thomas Lendacky, Eduardo Habkost,
Richard Henderson, Dr. David Alan Gilbert, Alistair Francis,
Cornelia Huck, Richard Henderson, Peter Crosthwaite,
Paolo Bonzini
On Thu, Mar 08, 2018 at 06:48:43AM -0600, Brijesh Singh wrote:
> The header file provide the ioctl command and structure to communicate
> with /dev/sev device.
>
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Cc: Richard Henderson <rth@twiddle.net>
> Cc: Eduardo Habkost <ehabkost@redhat.com>
> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
> ---
> linux-headers/linux/psp-sev.h | 142 ++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 142 insertions(+)
> create mode 100644 linux-headers/linux/psp-sev.h
>
> diff --git a/linux-headers/linux/psp-sev.h b/linux-headers/linux/psp-sev.h
> new file mode 100644
> index 000000000000..33e247471ae0
> --- /dev/null
> +++ b/linux-headers/linux/psp-sev.h
> @@ -0,0 +1,142 @@
> +/*
> + * Userspace interface for AMD Secure Encrypted Virtualization (SEV)
> + * platform management commands.
> + *
> + * Copyright (C) 2016-2017 Advanced Micro Devices, Inc.
> + *
> + * Author: Brijesh Singh <brijesh.singh@amd.com>
> + *
> + * SEV spec 0.14 is available at:
> + * http://support.amd.com/TechDocs/55766_SEV-KM%20API_Specification.pdf
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
Most of the files you've added are GPLv2-or-later. Is this one intentionally
GPLv2-only instead ?
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [Qemu-devel] [PATCH v12 10/28] include: add psp-sev.h header file
@ 2018-03-08 16:54 ` Daniel P. Berrangé
0 siblings, 0 replies; 114+ messages in thread
From: Daniel P. Berrangé @ 2018-03-08 16:54 UTC (permalink / raw)
To: Brijesh Singh
Cc: qemu-devel, Alistair Francis, Christian Borntraeger,
Cornelia Huck, Dr. David Alan Gilbert, Michael S. Tsirkin,
Edgar E. Iglesias, Eduardo Habkost, Eric Blake, kvm,
Marcel Apfelbaum, Markus Armbruster, Paolo Bonzini,
Peter Crosthwaite, Peter Maydell, Richard Henderson,
Stefan Hajnoczi, Thomas Lendacky, Borislav Petkov,
Alexander Graf, Bruce Rogers, Richard Henderson
On Thu, Mar 08, 2018 at 06:48:43AM -0600, Brijesh Singh wrote:
> The header file provide the ioctl command and structure to communicate
> with /dev/sev device.
>
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Cc: Richard Henderson <rth@twiddle.net>
> Cc: Eduardo Habkost <ehabkost@redhat.com>
> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
> ---
> linux-headers/linux/psp-sev.h | 142 ++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 142 insertions(+)
> create mode 100644 linux-headers/linux/psp-sev.h
>
> diff --git a/linux-headers/linux/psp-sev.h b/linux-headers/linux/psp-sev.h
> new file mode 100644
> index 000000000000..33e247471ae0
> --- /dev/null
> +++ b/linux-headers/linux/psp-sev.h
> @@ -0,0 +1,142 @@
> +/*
> + * Userspace interface for AMD Secure Encrypted Virtualization (SEV)
> + * platform management commands.
> + *
> + * Copyright (C) 2016-2017 Advanced Micro Devices, Inc.
> + *
> + * Author: Brijesh Singh <brijesh.singh@amd.com>
> + *
> + * SEV spec 0.14 is available at:
> + * http://support.amd.com/TechDocs/55766_SEV-KM%20API_Specification.pdf
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
Most of the files you've added are GPLv2-or-later. Is this one intentionally
GPLv2-only instead ?
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v12 11/28] sev/i386: add command to initialize the memory encryption context
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
@ 2018-03-08 16:57 ` Daniel P. Berrangé
-1 siblings, 0 replies; 114+ messages in thread
From: Daniel P. Berrangé @ 2018-03-08 16:57 UTC (permalink / raw)
To: Brijesh Singh
Cc: Peter Maydell, kvm, Michael S. Tsirkin, Stefan Hajnoczi,
qemu-devel, Alexander Graf, Edgar E. Iglesias, Markus Armbruster,
Bruce Rogers, Christian Borntraeger, Marcel Apfelbaum,
Borislav Petkov, Thomas Lendacky, Eduardo Habkost,
Richard Henderson, Dr. David Alan Gilbert, Alistair Francis,
Cornelia Huck, Richard Henderson, Peter Crosthwaite,
Paolo Bonzini
On Thu, Mar 08, 2018 at 06:48:44AM -0600, Brijesh Singh wrote:
> When memory encryption is enabled, KVM_SEV_INIT command is used to
> initialize the platform. The command loads the SEV related persistent
> data from non-volatile storage and initializes the platform context.
> This command should be first issued before invoking any other guest
> commands provided by the SEV firmware.
>
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Cc: Richard Henderson <rth@twiddle.net>
> Cc: Eduardo Habkost <ehabkost@redhat.com>
> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
> ---
> accel/kvm/kvm-all.c | 16 ++++
> include/sysemu/sev.h | 22 +++++
> stubs/Makefile.objs | 1 +
> stubs/sev.c | 21 +++++
> target/i386/Makefile.objs | 2 +-
> target/i386/monitor.c | 11 ++-
> target/i386/sev-stub.c | 41 +++++++++
> target/i386/sev.c | 224 ++++++++++++++++++++++++++++++++++++++++++++++
> target/i386/sev_i386.h | 24 +++++
> target/i386/trace-events | 3 +
> 10 files changed, 362 insertions(+), 3 deletions(-)
> create mode 100644 include/sysemu/sev.h
> create mode 100644 stubs/sev.c
> create mode 100644 target/i386/sev-stub.c
>
> +static const char *const sev_fw_errlist[] = {
> + "",
> + "Platform state is invalid",
> + "Guest state is invalid",
> + "Platform configuration is invalid",
> + "Buffer too small",
> + "Platform is already owned",
> + "Certificate is invalid",
> + "Policy is not allowed",
> + "Guest is not active",
> + "Invalid address",
> + "Bad signature",
> + "Bad measurement",
> + "Asid is already owned",
> + "Invalid ASID",
> + "WBINVD is required",
> + "DF_FLUSH is required",
> + "Guest handle is invalid",
> + "Invalid command",
> + "Guest is active",
> + "Hardware error",
> + "Hardware unsafe",
> + "Feature not supported",
> + "Invalid parameter"
> +};
> +
> +#define SEV_FW_MAX_ERROR ARRAY_SIZE(sev_fw_errlist)
> +
> +static const char *
> +fw_error_to_str(int code)
> +{
> + if (code >= SEV_FW_MAX_ERROR) {
> + return "unknown error";
Seems '0' is not an error, and negative numbers are invalid
too, so augment this with '|| code <= 0' to avoid bad array
access on negative numbers
> + }
> +
> + return sev_fw_errlist[code];
> +}
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [Qemu-devel] [PATCH v12 11/28] sev/i386: add command to initialize the memory encryption context
@ 2018-03-08 16:57 ` Daniel P. Berrangé
0 siblings, 0 replies; 114+ messages in thread
From: Daniel P. Berrangé @ 2018-03-08 16:57 UTC (permalink / raw)
To: Brijesh Singh
Cc: qemu-devel, Alistair Francis, Christian Borntraeger,
Cornelia Huck, Dr. David Alan Gilbert, Michael S. Tsirkin,
Edgar E. Iglesias, Eduardo Habkost, Eric Blake, kvm,
Marcel Apfelbaum, Markus Armbruster, Paolo Bonzini,
Peter Crosthwaite, Peter Maydell, Richard Henderson,
Stefan Hajnoczi, Thomas Lendacky, Borislav Petkov,
Alexander Graf, Bruce Rogers, Richard Henderson
On Thu, Mar 08, 2018 at 06:48:44AM -0600, Brijesh Singh wrote:
> When memory encryption is enabled, KVM_SEV_INIT command is used to
> initialize the platform. The command loads the SEV related persistent
> data from non-volatile storage and initializes the platform context.
> This command should be first issued before invoking any other guest
> commands provided by the SEV firmware.
>
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Cc: Richard Henderson <rth@twiddle.net>
> Cc: Eduardo Habkost <ehabkost@redhat.com>
> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
> ---
> accel/kvm/kvm-all.c | 16 ++++
> include/sysemu/sev.h | 22 +++++
> stubs/Makefile.objs | 1 +
> stubs/sev.c | 21 +++++
> target/i386/Makefile.objs | 2 +-
> target/i386/monitor.c | 11 ++-
> target/i386/sev-stub.c | 41 +++++++++
> target/i386/sev.c | 224 ++++++++++++++++++++++++++++++++++++++++++++++
> target/i386/sev_i386.h | 24 +++++
> target/i386/trace-events | 3 +
> 10 files changed, 362 insertions(+), 3 deletions(-)
> create mode 100644 include/sysemu/sev.h
> create mode 100644 stubs/sev.c
> create mode 100644 target/i386/sev-stub.c
>
> +static const char *const sev_fw_errlist[] = {
> + "",
> + "Platform state is invalid",
> + "Guest state is invalid",
> + "Platform configuration is invalid",
> + "Buffer too small",
> + "Platform is already owned",
> + "Certificate is invalid",
> + "Policy is not allowed",
> + "Guest is not active",
> + "Invalid address",
> + "Bad signature",
> + "Bad measurement",
> + "Asid is already owned",
> + "Invalid ASID",
> + "WBINVD is required",
> + "DF_FLUSH is required",
> + "Guest handle is invalid",
> + "Invalid command",
> + "Guest is active",
> + "Hardware error",
> + "Hardware unsafe",
> + "Feature not supported",
> + "Invalid parameter"
> +};
> +
> +#define SEV_FW_MAX_ERROR ARRAY_SIZE(sev_fw_errlist)
> +
> +static const char *
> +fw_error_to_str(int code)
> +{
> + if (code >= SEV_FW_MAX_ERROR) {
> + return "unknown error";
Seems '0' is not an error, and negative numbers are invalid
too, so augment this with '|| code <= 0' to avoid bad array
access on negative numbers
> + }
> +
> + return sev_fw_errlist[code];
> +}
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v12 23/28] qmp: add query-sev-launch-measure command
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
@ 2018-03-08 17:03 ` Daniel P. Berrangé
-1 siblings, 0 replies; 114+ messages in thread
From: Daniel P. Berrangé @ 2018-03-08 17:03 UTC (permalink / raw)
To: Brijesh Singh
Cc: Edgar E. Iglesias, Peter Maydell, Borislav Petkov,
Eduardo Habkost, kvm, Michael S. Tsirkin, Marcel Apfelbaum,
Markus Armbruster, Peter Crosthwaite, Richard Henderson,
qemu-devel, Dr. David Alan Gilbert, Christian Borntraeger,
Alexander Graf, Stefan Hajnoczi, Cornelia Huck, Paolo Bonzini,
Thomas Lendacky, Alistair Francis, Bruce Rogers
On Thu, Mar 08, 2018 at 06:48:56AM -0600, Brijesh Singh wrote:
> The command can be used by libvirt to retrieve the measurement of SEV guest.
> This measurement is a signature of the memory contents that was encrypted
> through the LAUNCH_UPDATE_DATA.
>
> Cc: "Daniel P. Berrangé" <berrange@redhat.com>
> Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
> Cc: Markus Armbruster <armbru@redhat.com>
> Reviewed-by: Eric Blake <eblake@redhat.com>
> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
> ---
> monitor.c | 7 +++++++
> qapi/misc.json | 29 +++++++++++++++++++++++++++++
> target/i386/monitor.c | 17 +++++++++++++++++
> 3 files changed, 53 insertions(+)
>
> diff --git a/monitor.c b/monitor.c
> index 2225cf5030dc..d53ecc5ddab3 100644
> --- a/monitor.c
> +++ b/monitor.c
> @@ -984,6 +984,7 @@ static void qmp_unregister_commands_hack(void)
> #ifndef TARGET_I386
> qmp_unregister_command(&qmp_commands, "rtc-reset-reinjection");
> qmp_unregister_command(&qmp_commands, "query-sev");
> + qmp_unregister_command(&qmp_commands, "query-sev-launch-measure");
> #endif
> #ifndef TARGET_S390X
> qmp_unregister_command(&qmp_commands, "dump-skeys");
> @@ -4110,6 +4111,12 @@ SevInfo *qmp_query_sev(Error **errp)
> error_setg(errp, QERR_FEATURE_DISABLED, "query-sev");
> return NULL;
> }
> +
> +SevLaunchMeasureInfo *qmp_query_sev_launch_measure(Error **errp)
> +{
> + error_setg(errp, QERR_FEATURE_DISABLED, "query-sev-launch-measure");
> + return NULL;
> +}
> #endif
>
> #ifndef TARGET_S390X
> diff --git a/qapi/misc.json b/qapi/misc.json
> index 14681729f8fc..a39c43aa64b1 100644
> --- a/qapi/misc.json
> +++ b/qapi/misc.json
> @@ -3277,3 +3277,32 @@
> #
> ##
> { 'command': 'query-sev', 'returns': 'SevInfo' }
> +
> +##
> +# @SevLaunchMeasureInfo:
> +#
> +# SEV Guest Launch measurement information
> +#
> +# @data: the measurement value encoded in base64
> +#
> +# Since: 2.12
> +#
> +##
> +{ 'struct': 'SevLaunchMeasureInfo', 'data': {'data': 'str'} }
> +
> +##
> +# @query-sev-launch-measure:
> +#
> +# Query the SEV guest launch information.
> +#
> +# Returns: The @SevLaunchMeasureInfo for the guest
> +#
> +# Since: 2.12
> +#
> +# Example:
> +#
> +# -> { "execute": "query-sev-launch-measure" }
> +# <- { "return": { "data": "4l8LXeNlSPUDlXPJG5966/8%YZ" } }
> +#
> +##
> +{ 'command': 'query-sev-launch-measure', 'returns': 'SevLaunchMeasureInfo' }
> diff --git a/target/i386/monitor.c b/target/i386/monitor.c
> index 7df31c3cdf1b..e5596bbc0fc2 100644
> --- a/target/i386/monitor.c
> +++ b/target/i386/monitor.c
> @@ -720,3 +720,20 @@ void hmp_info_sev(Monitor *mon, const QDict *qdict)
> monitor_printf(mon, "SEV is not enabled\n");
> }
> }
> +
> +SevLaunchMeasureInfo *qmp_query_sev_launch_measure(Error **errp)
> +{
> + char *data;
> + SevLaunchMeasureInfo *info;
> +
> + data = sev_get_launch_measurement();
> + if (!data) {
> + error_setg(errp, "Measurement is not available");
> + return NULL;
> + }
> +
> + info = g_malloc0(sizeof(*info));
Minor preference for g_new0(SevLaunchMeasureInfo, 1);
> + info->data = data;
> +
> + return info;
> +}
Regardless though
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [Qemu-devel] [PATCH v12 23/28] qmp: add query-sev-launch-measure command
@ 2018-03-08 17:03 ` Daniel P. Berrangé
0 siblings, 0 replies; 114+ messages in thread
From: Daniel P. Berrangé @ 2018-03-08 17:03 UTC (permalink / raw)
To: Brijesh Singh
Cc: qemu-devel, Alistair Francis, Christian Borntraeger,
Cornelia Huck, Dr. David Alan Gilbert, Michael S. Tsirkin,
Edgar E. Iglesias, Eduardo Habkost, Eric Blake, kvm,
Marcel Apfelbaum, Markus Armbruster, Paolo Bonzini,
Peter Crosthwaite, Peter Maydell, Richard Henderson,
Stefan Hajnoczi, Thomas Lendacky, Borislav Petkov,
Alexander Graf, Bruce Rogers
On Thu, Mar 08, 2018 at 06:48:56AM -0600, Brijesh Singh wrote:
> The command can be used by libvirt to retrieve the measurement of SEV guest.
> This measurement is a signature of the memory contents that was encrypted
> through the LAUNCH_UPDATE_DATA.
>
> Cc: "Daniel P. Berrangé" <berrange@redhat.com>
> Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
> Cc: Markus Armbruster <armbru@redhat.com>
> Reviewed-by: Eric Blake <eblake@redhat.com>
> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
> ---
> monitor.c | 7 +++++++
> qapi/misc.json | 29 +++++++++++++++++++++++++++++
> target/i386/monitor.c | 17 +++++++++++++++++
> 3 files changed, 53 insertions(+)
>
> diff --git a/monitor.c b/monitor.c
> index 2225cf5030dc..d53ecc5ddab3 100644
> --- a/monitor.c
> +++ b/monitor.c
> @@ -984,6 +984,7 @@ static void qmp_unregister_commands_hack(void)
> #ifndef TARGET_I386
> qmp_unregister_command(&qmp_commands, "rtc-reset-reinjection");
> qmp_unregister_command(&qmp_commands, "query-sev");
> + qmp_unregister_command(&qmp_commands, "query-sev-launch-measure");
> #endif
> #ifndef TARGET_S390X
> qmp_unregister_command(&qmp_commands, "dump-skeys");
> @@ -4110,6 +4111,12 @@ SevInfo *qmp_query_sev(Error **errp)
> error_setg(errp, QERR_FEATURE_DISABLED, "query-sev");
> return NULL;
> }
> +
> +SevLaunchMeasureInfo *qmp_query_sev_launch_measure(Error **errp)
> +{
> + error_setg(errp, QERR_FEATURE_DISABLED, "query-sev-launch-measure");
> + return NULL;
> +}
> #endif
>
> #ifndef TARGET_S390X
> diff --git a/qapi/misc.json b/qapi/misc.json
> index 14681729f8fc..a39c43aa64b1 100644
> --- a/qapi/misc.json
> +++ b/qapi/misc.json
> @@ -3277,3 +3277,32 @@
> #
> ##
> { 'command': 'query-sev', 'returns': 'SevInfo' }
> +
> +##
> +# @SevLaunchMeasureInfo:
> +#
> +# SEV Guest Launch measurement information
> +#
> +# @data: the measurement value encoded in base64
> +#
> +# Since: 2.12
> +#
> +##
> +{ 'struct': 'SevLaunchMeasureInfo', 'data': {'data': 'str'} }
> +
> +##
> +# @query-sev-launch-measure:
> +#
> +# Query the SEV guest launch information.
> +#
> +# Returns: The @SevLaunchMeasureInfo for the guest
> +#
> +# Since: 2.12
> +#
> +# Example:
> +#
> +# -> { "execute": "query-sev-launch-measure" }
> +# <- { "return": { "data": "4l8LXeNlSPUDlXPJG5966/8%YZ" } }
> +#
> +##
> +{ 'command': 'query-sev-launch-measure', 'returns': 'SevLaunchMeasureInfo' }
> diff --git a/target/i386/monitor.c b/target/i386/monitor.c
> index 7df31c3cdf1b..e5596bbc0fc2 100644
> --- a/target/i386/monitor.c
> +++ b/target/i386/monitor.c
> @@ -720,3 +720,20 @@ void hmp_info_sev(Monitor *mon, const QDict *qdict)
> monitor_printf(mon, "SEV is not enabled\n");
> }
> }
> +
> +SevLaunchMeasureInfo *qmp_query_sev_launch_measure(Error **errp)
> +{
> + char *data;
> + SevLaunchMeasureInfo *info;
> +
> + data = sev_get_launch_measurement();
> + if (!data) {
> + error_setg(errp, "Measurement is not available");
> + return NULL;
> + }
> +
> + info = g_malloc0(sizeof(*info));
Minor preference for g_new0(SevLaunchMeasureInfo, 1);
> + info->data = data;
> +
> + return info;
> +}
Regardless though
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v12 26/28] qmp: add query-sev-capabilities command
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
@ 2018-03-08 17:05 ` Daniel P. Berrangé
-1 siblings, 0 replies; 114+ messages in thread
From: Daniel P. Berrangé @ 2018-03-08 17:05 UTC (permalink / raw)
To: Brijesh Singh
Cc: Edgar E. Iglesias, Peter Maydell, Borislav Petkov,
Eduardo Habkost, kvm, Michael S. Tsirkin, Marcel Apfelbaum,
Markus Armbruster, Peter Crosthwaite, Richard Henderson,
qemu-devel, Dr. David Alan Gilbert, Christian Borntraeger,
Alexander Graf, Stefan Hajnoczi, Cornelia Huck, Paolo Bonzini,
Thomas Lendacky, Alistair Francis, Bruce Rogers
On Thu, Mar 08, 2018 at 06:48:59AM -0600, Brijesh Singh wrote:
> The command can be used by libvirt to query the SEV capabilities.
>
> Cc: "Daniel P. Berrangé" <berrange@redhat.com>
> Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
> Cc: Markus Armbruster <armbru@redhat.com>
> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
> ---
> monitor.c | 7 +++++++
> qapi/misc.json | 42 ++++++++++++++++++++++++++++++++++++++++++
> target/i386/monitor.c | 6 ++++++
> 3 files changed, 55 insertions(+)
>
> diff --git a/monitor.c b/monitor.c
> index d53ecc5ddab3..29ce695a80d5 100644
> --- a/monitor.c
> +++ b/monitor.c
> @@ -985,6 +985,7 @@ static void qmp_unregister_commands_hack(void)
> qmp_unregister_command(&qmp_commands, "rtc-reset-reinjection");
> qmp_unregister_command(&qmp_commands, "query-sev");
> qmp_unregister_command(&qmp_commands, "query-sev-launch-measure");
> + qmp_unregister_command(&qmp_commands, "query-sev-capabilities");
> #endif
> #ifndef TARGET_S390X
> qmp_unregister_command(&qmp_commands, "dump-skeys");
> @@ -4117,6 +4118,12 @@ SevLaunchMeasureInfo *qmp_query_sev_launch_measure(Error **errp)
> error_setg(errp, QERR_FEATURE_DISABLED, "query-sev-launch-measure");
> return NULL;
> }
> +
> +SevCapability *qmp_query_sev_capabilities(Error **errp)
> +{
> + error_setg(errp, QERR_FEATURE_DISABLED, "query-sev-capabilities");
> + return NULL;
> +}
> #endif
>
> #ifndef TARGET_S390X
> diff --git a/qapi/misc.json b/qapi/misc.json
> index a39c43aa64b1..37c89663d8f4 100644
> --- a/qapi/misc.json
> +++ b/qapi/misc.json
> @@ -3306,3 +3306,45 @@
> #
> ##
> { 'command': 'query-sev-launch-measure', 'returns': 'SevLaunchMeasureInfo' }
> +
> +##
> +# @SevCapability:
> +#
> +# The struct describes capability for a Secure Encrypted Virtualization
> +# feature.
> +#
> +# @pdh: Platform Diffie-Hellman key
> +#
> +# @cert-chain: PDH certificate chain
Are either of these base64 encoded ? If so nice to document that.
> +#
> +# @cbitpos: C-bit location in page table entry
> +#
> +# @reduced-phys-bits: Number of physical Address bit reduction when SEV is
> +# enabled
> +#
> +# Since: 2.12
> +##
> +{ 'struct': 'SevCapability',
> + 'data': { 'pdh': 'str',
> + 'cert-chain': 'str',
> + 'cbitpos': 'int',
> + 'reduced-phys-bits': 'int'} }
Regardless of answer to above Q,
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [Qemu-devel] [PATCH v12 26/28] qmp: add query-sev-capabilities command
@ 2018-03-08 17:05 ` Daniel P. Berrangé
0 siblings, 0 replies; 114+ messages in thread
From: Daniel P. Berrangé @ 2018-03-08 17:05 UTC (permalink / raw)
To: Brijesh Singh
Cc: qemu-devel, Alistair Francis, Christian Borntraeger,
Cornelia Huck, Dr. David Alan Gilbert, Michael S. Tsirkin,
Edgar E. Iglesias, Eduardo Habkost, Eric Blake, kvm,
Marcel Apfelbaum, Markus Armbruster, Paolo Bonzini,
Peter Crosthwaite, Peter Maydell, Richard Henderson,
Stefan Hajnoczi, Thomas Lendacky, Borislav Petkov,
Alexander Graf, Bruce Rogers
On Thu, Mar 08, 2018 at 06:48:59AM -0600, Brijesh Singh wrote:
> The command can be used by libvirt to query the SEV capabilities.
>
> Cc: "Daniel P. Berrangé" <berrange@redhat.com>
> Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
> Cc: Markus Armbruster <armbru@redhat.com>
> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
> ---
> monitor.c | 7 +++++++
> qapi/misc.json | 42 ++++++++++++++++++++++++++++++++++++++++++
> target/i386/monitor.c | 6 ++++++
> 3 files changed, 55 insertions(+)
>
> diff --git a/monitor.c b/monitor.c
> index d53ecc5ddab3..29ce695a80d5 100644
> --- a/monitor.c
> +++ b/monitor.c
> @@ -985,6 +985,7 @@ static void qmp_unregister_commands_hack(void)
> qmp_unregister_command(&qmp_commands, "rtc-reset-reinjection");
> qmp_unregister_command(&qmp_commands, "query-sev");
> qmp_unregister_command(&qmp_commands, "query-sev-launch-measure");
> + qmp_unregister_command(&qmp_commands, "query-sev-capabilities");
> #endif
> #ifndef TARGET_S390X
> qmp_unregister_command(&qmp_commands, "dump-skeys");
> @@ -4117,6 +4118,12 @@ SevLaunchMeasureInfo *qmp_query_sev_launch_measure(Error **errp)
> error_setg(errp, QERR_FEATURE_DISABLED, "query-sev-launch-measure");
> return NULL;
> }
> +
> +SevCapability *qmp_query_sev_capabilities(Error **errp)
> +{
> + error_setg(errp, QERR_FEATURE_DISABLED, "query-sev-capabilities");
> + return NULL;
> +}
> #endif
>
> #ifndef TARGET_S390X
> diff --git a/qapi/misc.json b/qapi/misc.json
> index a39c43aa64b1..37c89663d8f4 100644
> --- a/qapi/misc.json
> +++ b/qapi/misc.json
> @@ -3306,3 +3306,45 @@
> #
> ##
> { 'command': 'query-sev-launch-measure', 'returns': 'SevLaunchMeasureInfo' }
> +
> +##
> +# @SevCapability:
> +#
> +# The struct describes capability for a Secure Encrypted Virtualization
> +# feature.
> +#
> +# @pdh: Platform Diffie-Hellman key
> +#
> +# @cert-chain: PDH certificate chain
Are either of these base64 encoded ? If so nice to document that.
> +#
> +# @cbitpos: C-bit location in page table entry
> +#
> +# @reduced-phys-bits: Number of physical Address bit reduction when SEV is
> +# enabled
> +#
> +# Since: 2.12
> +##
> +{ 'struct': 'SevCapability',
> + 'data': { 'pdh': 'str',
> + 'cert-chain': 'str',
> + 'cbitpos': 'int',
> + 'reduced-phys-bits': 'int'} }
Regardless of answer to above Q,
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v12 28/28] tests/qmp-test: blacklist sev specific qmp commands
2018-03-08 12:49 ` [Qemu-devel] " Brijesh Singh
@ 2018-03-08 17:08 ` Daniel P. Berrangé
-1 siblings, 0 replies; 114+ messages in thread
From: Daniel P. Berrangé @ 2018-03-08 17:08 UTC (permalink / raw)
To: Brijesh Singh
Cc: Edgar E. Iglesias, Peter Maydell, Borislav Petkov,
Eduardo Habkost, kvm, Michael S. Tsirkin, Marcel Apfelbaum,
Markus Armbruster, Peter Crosthwaite, Richard Henderson,
qemu-devel, Dr. David Alan Gilbert, Christian Borntraeger,
Alexander Graf, Stefan Hajnoczi, Cornelia Huck, Paolo Bonzini,
Thomas Lendacky, Alistair Francis, Bruce Rogers
On Thu, Mar 08, 2018 at 06:49:01AM -0600, Brijesh Singh wrote:
> Blacklist the following commands to fix the 'make check' failure.
>
> query-sev-launch-measure: it returns meaninful data only when we launch
> SEV guest otherwise the command returns an error.
>
> query-sev: it return an error when SEV is not available on host (e.g non
> X86 platform or KVM is disabled at the build time)
>
> query-sev-capabilities: it returns an error when SEV feature is not
> available on host machine.
We generally expect 'make check' to succeed on every single patch
in a series, so that 'git bisect' doesn't break.
So you should add each command to the blacklist in the same commit
that introduced the failure in the first place.
>
> Cc: "Daniel P. Berrangé" <berrange@redhat.com>
> Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
> Cc: Markus Armbruster <armbru@redhat.com>
> Reviewed-by: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
> ---
> tests/qmp-test.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/tests/qmp-test.c b/tests/qmp-test.c
> index 22445d9ec258..7470c6b754bc 100644
> --- a/tests/qmp-test.c
> +++ b/tests/qmp-test.c
> @@ -204,6 +204,11 @@ static bool query_is_blacklisted(const char *cmd)
> "query-gic-capabilities", /* arm */
> /* Success depends on target-specific build configuration: */
> "query-pci", /* CONFIG_PCI */
> + /* Success depends on launching SEV guest */
> + "query-sev-launch-measure",
> + /* Success depends on Host or Hypervisor SEV support */
> + "query-sev",
> + "query-sev-capabilities",
> NULL
> };
> int i;
> --
> 2.14.3
>
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [Qemu-devel] [PATCH v12 28/28] tests/qmp-test: blacklist sev specific qmp commands
@ 2018-03-08 17:08 ` Daniel P. Berrangé
0 siblings, 0 replies; 114+ messages in thread
From: Daniel P. Berrangé @ 2018-03-08 17:08 UTC (permalink / raw)
To: Brijesh Singh
Cc: qemu-devel, Alistair Francis, Christian Borntraeger,
Cornelia Huck, Dr. David Alan Gilbert, Michael S. Tsirkin,
Edgar E. Iglesias, Eduardo Habkost, Eric Blake, kvm,
Marcel Apfelbaum, Markus Armbruster, Paolo Bonzini,
Peter Crosthwaite, Peter Maydell, Richard Henderson,
Stefan Hajnoczi, Thomas Lendacky, Borislav Petkov,
Alexander Graf, Bruce Rogers
On Thu, Mar 08, 2018 at 06:49:01AM -0600, Brijesh Singh wrote:
> Blacklist the following commands to fix the 'make check' failure.
>
> query-sev-launch-measure: it returns meaninful data only when we launch
> SEV guest otherwise the command returns an error.
>
> query-sev: it return an error when SEV is not available on host (e.g non
> X86 platform or KVM is disabled at the build time)
>
> query-sev-capabilities: it returns an error when SEV feature is not
> available on host machine.
We generally expect 'make check' to succeed on every single patch
in a series, so that 'git bisect' doesn't break.
So you should add each command to the blacklist in the same commit
that introduced the failure in the first place.
>
> Cc: "Daniel P. Berrangé" <berrange@redhat.com>
> Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
> Cc: Markus Armbruster <armbru@redhat.com>
> Reviewed-by: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
> ---
> tests/qmp-test.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/tests/qmp-test.c b/tests/qmp-test.c
> index 22445d9ec258..7470c6b754bc 100644
> --- a/tests/qmp-test.c
> +++ b/tests/qmp-test.c
> @@ -204,6 +204,11 @@ static bool query_is_blacklisted(const char *cmd)
> "query-gic-capabilities", /* arm */
> /* Success depends on target-specific build configuration: */
> "query-pci", /* CONFIG_PCI */
> + /* Success depends on launching SEV guest */
> + "query-sev-launch-measure",
> + /* Success depends on Host or Hypervisor SEV support */
> + "query-sev",
> + "query-sev-capabilities",
> NULL
> };
> int i;
> --
> 2.14.3
>
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v12 28/28] tests/qmp-test: blacklist sev specific qmp commands
2018-03-08 17:08 ` [Qemu-devel] " Daniel P. Berrangé
@ 2018-03-08 20:18 ` Brijesh Singh
-1 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 20:18 UTC (permalink / raw)
To: Daniel P. Berrangé
Cc: Peter Maydell, brijesh.singh, kvm, Michael S. Tsirkin,
Stefan Hajnoczi, qemu-devel, Alexander Graf, Edgar E. Iglesias,
Markus Armbruster, Bruce Rogers, Christian Borntraeger,
Marcel Apfelbaum, Borislav Petkov, Thomas Lendacky,
Eduardo Habkost, Richard Henderson, Dr. David Alan Gilbert,
Alistair Francis, Cornelia Huck, Peter Crosthwaite,
Paolo Bonzini
On 3/8/18 11:08 AM, Daniel P. Berrangé wrote:
> On Thu, Mar 08, 2018 at 06:49:01AM -0600, Brijesh Singh wrote:
>> Blacklist the following commands to fix the 'make check' failure.
>>
>> query-sev-launch-measure: it returns meaninful data only when we launch
>> SEV guest otherwise the command returns an error.
>>
>> query-sev: it return an error when SEV is not available on host (e.g non
>> X86 platform or KVM is disabled at the build time)
>>
>> query-sev-capabilities: it returns an error when SEV feature is not
>> available on host machine.
> We generally expect 'make check' to succeed on every single patch
> in a series, so that 'git bisect' doesn't break.
>
> So you should add each command to the blacklist in the same commit
> that introduced the failure in the first place.
Sure, I can quickly send the updated patch series to address your this
concern, but before spamming everyone's inbox I was wondering if I can
get some indication whether this series will make into 2.12 merge.
Paolo, Eduardo and Richard,
Most of the changes are in x86 directory hence any thought if you are
considering this series for 2.12 ? I have been testing the series with
and without SEV support and so far have not ran into any issue. if you
are not planning to pull this series in 2.12 then I will wait a bit
longer to get more feedback before sending the updates to address
Daniel's comment. thanks
>> Cc: "Daniel P. Berrangé" <berrange@redhat.com>
>> Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
>> Cc: Markus Armbruster <armbru@redhat.com>
>> Reviewed-by: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
>> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
>> ---
>> tests/qmp-test.c | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/tests/qmp-test.c b/tests/qmp-test.c
>> index 22445d9ec258..7470c6b754bc 100644
>> --- a/tests/qmp-test.c
>> +++ b/tests/qmp-test.c
>> @@ -204,6 +204,11 @@ static bool query_is_blacklisted(const char *cmd)
>> "query-gic-capabilities", /* arm */
>> /* Success depends on target-specific build configuration: */
>> "query-pci", /* CONFIG_PCI */
>> + /* Success depends on launching SEV guest */
>> + "query-sev-launch-measure",
>> + /* Success depends on Host or Hypervisor SEV support */
>> + "query-sev",
>> + "query-sev-capabilities",
>> NULL
>> };
>> int i;
>> --
>> 2.14.3
>>
> Regards,
> Daniel
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [Qemu-devel] [PATCH v12 28/28] tests/qmp-test: blacklist sev specific qmp commands
@ 2018-03-08 20:18 ` Brijesh Singh
0 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 20:18 UTC (permalink / raw)
To: Daniel P. Berrangé
Cc: brijesh.singh, qemu-devel, Alistair Francis,
Christian Borntraeger, Cornelia Huck, Dr. David Alan Gilbert,
Michael S. Tsirkin, Edgar E. Iglesias, Eduardo Habkost,
Eric Blake, kvm, Marcel Apfelbaum, Markus Armbruster,
Paolo Bonzini, Peter Crosthwaite, Peter Maydell,
Richard Henderson, Stefan Hajnoczi, Thomas Lendacky,
Borislav Petkov, Alexander Graf, Bruce Rogers
On 3/8/18 11:08 AM, Daniel P. Berrangé wrote:
> On Thu, Mar 08, 2018 at 06:49:01AM -0600, Brijesh Singh wrote:
>> Blacklist the following commands to fix the 'make check' failure.
>>
>> query-sev-launch-measure: it returns meaninful data only when we launch
>> SEV guest otherwise the command returns an error.
>>
>> query-sev: it return an error when SEV is not available on host (e.g non
>> X86 platform or KVM is disabled at the build time)
>>
>> query-sev-capabilities: it returns an error when SEV feature is not
>> available on host machine.
> We generally expect 'make check' to succeed on every single patch
> in a series, so that 'git bisect' doesn't break.
>
> So you should add each command to the blacklist in the same commit
> that introduced the failure in the first place.
Sure, I can quickly send the updated patch series to address your this
concern, but before spamming everyone's inbox I was wondering if I can
get some indication whether this series will make into 2.12 merge.
Paolo, Eduardo and Richard,
Most of the changes are in x86 directory hence any thought if you are
considering this series for 2.12 ? I have been testing the series with
and without SEV support and so far have not ran into any issue. if you
are not planning to pull this series in 2.12 then I will wait a bit
longer to get more feedback before sending the updates to address
Daniel's comment. thanks
>> Cc: "Daniel P. Berrangé" <berrange@redhat.com>
>> Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
>> Cc: Markus Armbruster <armbru@redhat.com>
>> Reviewed-by: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
>> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
>> ---
>> tests/qmp-test.c | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/tests/qmp-test.c b/tests/qmp-test.c
>> index 22445d9ec258..7470c6b754bc 100644
>> --- a/tests/qmp-test.c
>> +++ b/tests/qmp-test.c
>> @@ -204,6 +204,11 @@ static bool query_is_blacklisted(const char *cmd)
>> "query-gic-capabilities", /* arm */
>> /* Success depends on target-specific build configuration: */
>> "query-pci", /* CONFIG_PCI */
>> + /* Success depends on launching SEV guest */
>> + "query-sev-launch-measure",
>> + /* Success depends on Host or Hypervisor SEV support */
>> + "query-sev",
>> + "query-sev-capabilities",
>> NULL
>> };
>> int i;
>> --
>> 2.14.3
>>
> Regards,
> Daniel
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v12 28/28] tests/qmp-test: blacklist sev specific qmp commands
2018-03-08 20:18 ` [Qemu-devel] " Brijesh Singh
@ 2018-03-08 21:45 ` Eduardo Habkost
-1 siblings, 0 replies; 114+ messages in thread
From: Eduardo Habkost @ 2018-03-08 21:45 UTC (permalink / raw)
To: Brijesh Singh
Cc: Edgar E. Iglesias, Peter Maydell, Borislav Petkov, kvm,
Michael S. Tsirkin, Marcel Apfelbaum, Markus Armbruster,
Peter Crosthwaite, Richard Henderson, qemu-devel,
Dr. David Alan Gilbert, Christian Borntraeger, Alexander Graf,
Stefan Hajnoczi, Cornelia Huck, Paolo Bonzini, Thomas Lendacky,
Alistair Francis, Bruce Rogers
On Thu, Mar 08, 2018 at 02:18:55PM -0600, Brijesh Singh wrote:
>
>
> On 3/8/18 11:08 AM, Daniel P. Berrangé wrote:
> > On Thu, Mar 08, 2018 at 06:49:01AM -0600, Brijesh Singh wrote:
> >> Blacklist the following commands to fix the 'make check' failure.
> >>
> >> query-sev-launch-measure: it returns meaninful data only when we launch
> >> SEV guest otherwise the command returns an error.
> >>
> >> query-sev: it return an error when SEV is not available on host (e.g non
> >> X86 platform or KVM is disabled at the build time)
> >>
> >> query-sev-capabilities: it returns an error when SEV feature is not
> >> available on host machine.
> > We generally expect 'make check' to succeed on every single patch
> > in a series, so that 'git bisect' doesn't break.
> >
> > So you should add each command to the blacklist in the same commit
> > that introduced the failure in the first place.
>
>
> Sure, I can quickly send the updated patch series to address your this
> concern, but before spamming everyone's inbox I was wondering if I can
> get some indication whether this series will make into 2.12 merge.
>
> Paolo, Eduardo and Richard,
>
> Most of the changes are in x86 directory hence any thought if you are
> considering this series for 2.12 ? I have been testing the series with
> and without SEV support and so far have not ran into any issue. if you
> are not planning to pull this series in 2.12 then I will wait a bit
> longer to get more feedback before sending the updates to address
> Daniel's comment. thanks
Trying to merge it before 2.12 soft freeze (next Tuesday) still
looks like a reasonable goal to me. What do others think?
--
Eduardo
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [Qemu-devel] [PATCH v12 28/28] tests/qmp-test: blacklist sev specific qmp commands
@ 2018-03-08 21:45 ` Eduardo Habkost
0 siblings, 0 replies; 114+ messages in thread
From: Eduardo Habkost @ 2018-03-08 21:45 UTC (permalink / raw)
To: Brijesh Singh
Cc: Daniel P. Berrangé,
qemu-devel, Alistair Francis, Christian Borntraeger,
Cornelia Huck, Dr. David Alan Gilbert, Michael S. Tsirkin,
Edgar E. Iglesias, Eric Blake, kvm, Marcel Apfelbaum,
Markus Armbruster, Paolo Bonzini, Peter Crosthwaite,
Peter Maydell, Richard Henderson, Stefan Hajnoczi,
Thomas Lendacky, Borislav Petkov, Alexander Graf, Bruce Rogers
On Thu, Mar 08, 2018 at 02:18:55PM -0600, Brijesh Singh wrote:
>
>
> On 3/8/18 11:08 AM, Daniel P. Berrangé wrote:
> > On Thu, Mar 08, 2018 at 06:49:01AM -0600, Brijesh Singh wrote:
> >> Blacklist the following commands to fix the 'make check' failure.
> >>
> >> query-sev-launch-measure: it returns meaninful data only when we launch
> >> SEV guest otherwise the command returns an error.
> >>
> >> query-sev: it return an error when SEV is not available on host (e.g non
> >> X86 platform or KVM is disabled at the build time)
> >>
> >> query-sev-capabilities: it returns an error when SEV feature is not
> >> available on host machine.
> > We generally expect 'make check' to succeed on every single patch
> > in a series, so that 'git bisect' doesn't break.
> >
> > So you should add each command to the blacklist in the same commit
> > that introduced the failure in the first place.
>
>
> Sure, I can quickly send the updated patch series to address your this
> concern, but before spamming everyone's inbox I was wondering if I can
> get some indication whether this series will make into 2.12 merge.
>
> Paolo, Eduardo and Richard,
>
> Most of the changes are in x86 directory hence any thought if you are
> considering this series for 2.12 ? I have been testing the series with
> and without SEV support and so far have not ran into any issue. if you
> are not planning to pull this series in 2.12 then I will wait a bit
> longer to get more feedback before sending the updates to address
> Daniel's comment. thanks
Trying to merge it before 2.12 soft freeze (next Tuesday) still
looks like a reasonable goal to me. What do others think?
--
Eduardo
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v12 08/28] target/i386: add Secure Encrypted Virtulization (SEV) object
2018-03-08 16:49 ` [Qemu-devel] " Daniel P. Berrangé
@ 2018-03-08 22:22 ` Brijesh Singh
-1 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 22:22 UTC (permalink / raw)
To: Daniel P. Berrangé
Cc: Peter Maydell, brijesh.singh, kvm, Michael S. Tsirkin,
Stefan Hajnoczi, qemu-devel, Alexander Graf, Edgar E. Iglesias,
Markus Armbruster, Bruce Rogers, Christian Borntraeger,
Marcel Apfelbaum, Borislav Petkov, Thomas Lendacky,
Eduardo Habkost, Richard Henderson, Dr. David Alan Gilbert,
Alistair Francis, Cornelia Huck, Richard Henderson,
Peter Crosthwaite, Paolo Bonzini
On 3/8/18 10:49 AM, Daniel P. Berrangé wrote:
> On Thu, Mar 08, 2018 at 06:48:41AM -0600, Brijesh Singh wrote:
>> Add a new memory encryption object 'sev-guest'. The object will be used
>> to create enrypted VMs on AMD EPYC CPU. The object provides the properties
>> to pass guest owner's public Diffie-hellman key, guest policy and session
>> information required to create the memory encryption context within the
>> SEV firmware.
>>
>> e.g to launch SEV guest
>> # $QEMU \
>> -object sev-guest,id=sev0 \
>> -machine ....,memory-encryption=sev0
>>
>> Cc: Paolo Bonzini <pbonzini@redhat.com>
>> Cc: Richard Henderson <rth@twiddle.net>
>> Cc: Eduardo Habkost <ehabkost@redhat.com>
>> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
>
>> diff --git a/qemu-options.hx b/qemu-options.hx
>> index 4c280142c52c..6113bce08a8c 100644
>> --- a/qemu-options.hx
>> +++ b/qemu-options.hx
>> @@ -4353,6 +4353,50 @@ contents of @code{iv.b64} to the second secret
>> data=$SECRET,iv=$(<iv.b64)
>> @end example
>>
>> +@item -object sev-guest,id=@var{id},cbitpos=@var{cbitpos},reduced-phys-bits=@var{val},[sev-device=@var{string},policy=@var{policy},handle=@var{handle},dh-cert-file=@var{file},session-file=@var{file}]
>> +
>> +Create a Secure Encrypted Virtualization (SEV) guest object, which can be used
>> +to provide the guest memory encryption support on AMD processors.
>> +
>> +When memory encryption is enabled, one of the physical address bit (aka the
>> +C-bit) is utilized to mark if a memory page is protected. The @option{cbitpos}
>> +is used to provide the C-bit position. The C-bit position is Host family dependent
>> +hence user must provide this value. On EPYC, the value should be 47.
>> +
>> +When memory encryption is enabled, we loose certain bits in physical address space.
>> +The @option{reduced-phys-bits} is used to provide the number of bits we loose in
>> +physical address space. Similar to C-bit, the value is Host family dependent.
>> +On EPYC, the value should be 5.
> Is it valid to specify a different value for either of these properties ?
> eg what happens if I pass cbitpos=45 instead of 47 on an EPYC host ?
On EPYC, passing anything other than 47 will trigger error during SEV
guest initialization. The value of Cbit position is host dependent, the
value is readonly and can be obtained through the host CPUID. The
cbitpos must be same between guest and host. Please note that the pte's
in guest page table will need to use the cbitpos information to mark
the pages as encrypted. If cbit position given to the guest is different
from the host then guest will fail to execute.
>
> In particular I thinking about possible migration scenario, where EPYC
> uses 47 by default but some $NEXT AMD CPU uses 48 by default. In that
> case we might want to use '47' on both CPUs if we need ability to live
> migrate between different host CPU generations. Would that be valid ?
We will not be able to migrate SEV guests if cbit position does not
match between the source and destination hosts. Since during migration,
the destination guest is launched with same QEMU cli as source hence
cbitpos check in QEMU will catch it and fail the new launch. Optionally,
user can call query-sev-capabilities on both source and destination to
see if cbitpos is compatible before attempting to migrate the guest.
> On the flip side, if the value really it strictly tied to the host
> CPU family and no deviation is permitted, could the kernel not just
> pick the right value automatically avoiding the config option ?
>
I think doing so will be an issue for the migration. Consider your above
use case, a SEV guest is running on EPYC with cbitpos=47 and if we
migrate to some $NEXT AMD CPU which uses need to use cbitpos=48 and we
will fail to resume the guest on destination after migrating.
>
> Regards,
> Daniel
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [Qemu-devel] [PATCH v12 08/28] target/i386: add Secure Encrypted Virtulization (SEV) object
@ 2018-03-08 22:22 ` Brijesh Singh
0 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 22:22 UTC (permalink / raw)
To: Daniel P. Berrangé
Cc: brijesh.singh, qemu-devel, Alistair Francis,
Christian Borntraeger, Cornelia Huck, Dr. David Alan Gilbert,
Michael S. Tsirkin, Edgar E. Iglesias, Eduardo Habkost,
Eric Blake, kvm, Marcel Apfelbaum, Markus Armbruster,
Paolo Bonzini, Peter Crosthwaite, Peter Maydell,
Richard Henderson, Stefan Hajnoczi, Thomas Lendacky,
Borislav Petkov, Alexander Graf, Bruce Rogers, Richard Henderson
On 3/8/18 10:49 AM, Daniel P. Berrangé wrote:
> On Thu, Mar 08, 2018 at 06:48:41AM -0600, Brijesh Singh wrote:
>> Add a new memory encryption object 'sev-guest'. The object will be used
>> to create enrypted VMs on AMD EPYC CPU. The object provides the properties
>> to pass guest owner's public Diffie-hellman key, guest policy and session
>> information required to create the memory encryption context within the
>> SEV firmware.
>>
>> e.g to launch SEV guest
>> # $QEMU \
>> -object sev-guest,id=sev0 \
>> -machine ....,memory-encryption=sev0
>>
>> Cc: Paolo Bonzini <pbonzini@redhat.com>
>> Cc: Richard Henderson <rth@twiddle.net>
>> Cc: Eduardo Habkost <ehabkost@redhat.com>
>> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
>
>> diff --git a/qemu-options.hx b/qemu-options.hx
>> index 4c280142c52c..6113bce08a8c 100644
>> --- a/qemu-options.hx
>> +++ b/qemu-options.hx
>> @@ -4353,6 +4353,50 @@ contents of @code{iv.b64} to the second secret
>> data=$SECRET,iv=$(<iv.b64)
>> @end example
>>
>> +@item -object sev-guest,id=@var{id},cbitpos=@var{cbitpos},reduced-phys-bits=@var{val},[sev-device=@var{string},policy=@var{policy},handle=@var{handle},dh-cert-file=@var{file},session-file=@var{file}]
>> +
>> +Create a Secure Encrypted Virtualization (SEV) guest object, which can be used
>> +to provide the guest memory encryption support on AMD processors.
>> +
>> +When memory encryption is enabled, one of the physical address bit (aka the
>> +C-bit) is utilized to mark if a memory page is protected. The @option{cbitpos}
>> +is used to provide the C-bit position. The C-bit position is Host family dependent
>> +hence user must provide this value. On EPYC, the value should be 47.
>> +
>> +When memory encryption is enabled, we loose certain bits in physical address space.
>> +The @option{reduced-phys-bits} is used to provide the number of bits we loose in
>> +physical address space. Similar to C-bit, the value is Host family dependent.
>> +On EPYC, the value should be 5.
> Is it valid to specify a different value for either of these properties ?
> eg what happens if I pass cbitpos=45 instead of 47 on an EPYC host ?
On EPYC, passing anything other than 47 will trigger error during SEV
guest initialization. The value of Cbit position is host dependent, the
value is readonly and can be obtained through the host CPUID. The
cbitpos must be same between guest and host. Please note that the pte's
in guest page table will need to use the cbitpos information to mark
the pages as encrypted. If cbit position given to the guest is different
from the host then guest will fail to execute.
>
> In particular I thinking about possible migration scenario, where EPYC
> uses 47 by default but some $NEXT AMD CPU uses 48 by default. In that
> case we might want to use '47' on both CPUs if we need ability to live
> migrate between different host CPU generations. Would that be valid ?
We will not be able to migrate SEV guests if cbit position does not
match between the source and destination hosts. Since during migration,
the destination guest is launched with same QEMU cli as source hence
cbitpos check in QEMU will catch it and fail the new launch. Optionally,
user can call query-sev-capabilities on both source and destination to
see if cbitpos is compatible before attempting to migrate the guest.
> On the flip side, if the value really it strictly tied to the host
> CPU family and no deviation is permitted, could the kernel not just
> pick the right value automatically avoiding the config option ?
>
I think doing so will be an issue for the migration. Consider your above
use case, a SEV guest is running on EPYC with cbitpos=47 and if we
migrate to some $NEXT AMD CPU which uses need to use cbitpos=48 and we
will fail to resume the guest on destination after migrating.
>
> Regards,
> Daniel
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v12 08/28] target/i386: add Secure Encrypted Virtulization (SEV) object
2018-03-08 22:22 ` [Qemu-devel] " Brijesh Singh
@ 2018-03-08 22:44 ` Eduardo Habkost
-1 siblings, 0 replies; 114+ messages in thread
From: Eduardo Habkost @ 2018-03-08 22:44 UTC (permalink / raw)
To: Brijesh Singh
Cc: Peter Maydell, kvm, Michael S. Tsirkin, Stefan Hajnoczi,
qemu-devel, Alexander Graf, Edgar E. Iglesias, Markus Armbruster,
Bruce Rogers, Christian Borntraeger, Marcel Apfelbaum,
Borislav Petkov, Thomas Lendacky, Richard Henderson,
Dr. David Alan Gilbert, Alistair Francis, Cornelia Huck,
Richard Henderson, Peter Crosthwaite, Paolo Bonzini
On Thu, Mar 08, 2018 at 04:22:52PM -0600, Brijesh Singh wrote:
>
>
> On 3/8/18 10:49 AM, Daniel P. Berrangé wrote:
> > On Thu, Mar 08, 2018 at 06:48:41AM -0600, Brijesh Singh wrote:
> >> Add a new memory encryption object 'sev-guest'. The object will be used
> >> to create enrypted VMs on AMD EPYC CPU. The object provides the properties
> >> to pass guest owner's public Diffie-hellman key, guest policy and session
> >> information required to create the memory encryption context within the
> >> SEV firmware.
> >>
> >> e.g to launch SEV guest
> >> # $QEMU \
> >> -object sev-guest,id=sev0 \
> >> -machine ....,memory-encryption=sev0
> >>
> >> Cc: Paolo Bonzini <pbonzini@redhat.com>
> >> Cc: Richard Henderson <rth@twiddle.net>
> >> Cc: Eduardo Habkost <ehabkost@redhat.com>
> >> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
> >
> >> diff --git a/qemu-options.hx b/qemu-options.hx
> >> index 4c280142c52c..6113bce08a8c 100644
> >> --- a/qemu-options.hx
> >> +++ b/qemu-options.hx
> >> @@ -4353,6 +4353,50 @@ contents of @code{iv.b64} to the second secret
> >> data=$SECRET,iv=$(<iv.b64)
> >> @end example
> >>
> >> +@item -object sev-guest,id=@var{id},cbitpos=@var{cbitpos},reduced-phys-bits=@var{val},[sev-device=@var{string},policy=@var{policy},handle=@var{handle},dh-cert-file=@var{file},session-file=@var{file}]
> >> +
> >> +Create a Secure Encrypted Virtualization (SEV) guest object, which can be used
> >> +to provide the guest memory encryption support on AMD processors.
> >> +
> >> +When memory encryption is enabled, one of the physical address bit (aka the
> >> +C-bit) is utilized to mark if a memory page is protected. The @option{cbitpos}
> >> +is used to provide the C-bit position. The C-bit position is Host family dependent
> >> +hence user must provide this value. On EPYC, the value should be 47.
> >> +
> >> +When memory encryption is enabled, we loose certain bits in physical address space.
> >> +The @option{reduced-phys-bits} is used to provide the number of bits we loose in
> >> +physical address space. Similar to C-bit, the value is Host family dependent.
> >> +On EPYC, the value should be 5.
> > Is it valid to specify a different value for either of these properties ?
> > eg what happens if I pass cbitpos=45 instead of 47 on an EPYC host ?
>
> On EPYC, passing anything other than 47 will trigger error during SEV
> guest initialization. The value of Cbit position is host dependent, the
> value is readonly and can be obtained through the host CPUID. The
> cbitpos must be same between guest and host. Please note that the pte's
> in guest page table will need to use the cbitpos information to mark
> the pages as encrypted. If cbit position given to the guest is different
> from the host then guest will fail to execute.
>
> >
> > In particular I thinking about possible migration scenario, where EPYC
> > uses 47 by default but some $NEXT AMD CPU uses 48 by default. In that
> > case we might want to use '47' on both CPUs if we need ability to live
> > migrate between different host CPU generations. Would that be valid ?
>
> We will not be able to migrate SEV guests if cbit position does not
> match between the source and destination hosts. Since during migration,
> the destination guest is launched with same QEMU cli as source hence
> cbitpos check in QEMU will catch it and fail the new launch. Optionally,
> user can call query-sev-capabilities on both source and destination to
> see if cbitpos is compatible before attempting to migrate the guest.
>
> > On the flip side, if the value really it strictly tied to the host
> > CPU family and no deviation is permitted, could the kernel not just
> > pick the right value automatically avoiding the config option ?
> >
>
> I think doing so will be an issue for the migration. Consider your above
> use case, a SEV guest is running on EPYC with cbitpos=47 and if we
> migrate to some $NEXT AMD CPU which uses need to use cbitpos=48 and we
> will fail to resume the guest on destination after migrating.
Exactly, in other words these two options are part of the guest
ABI, and QEMU promises to never make the guest ABI depend on the
host hardware unless you're using "-cpu host".
In theory we could make QEMU choose the right values
automatically if we document very clearly that the default
behavior is unsafe. But I would rather not take that risk and
force management software to be aware of the gotchas involved in
using SEV + live-migration.
--
Eduardo
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [Qemu-devel] [PATCH v12 08/28] target/i386: add Secure Encrypted Virtulization (SEV) object
@ 2018-03-08 22:44 ` Eduardo Habkost
0 siblings, 0 replies; 114+ messages in thread
From: Eduardo Habkost @ 2018-03-08 22:44 UTC (permalink / raw)
To: Brijesh Singh
Cc: Daniel P. Berrangé,
qemu-devel, Alistair Francis, Christian Borntraeger,
Cornelia Huck, Dr. David Alan Gilbert, Michael S. Tsirkin,
Edgar E. Iglesias, Eric Blake, kvm, Marcel Apfelbaum,
Markus Armbruster, Paolo Bonzini, Peter Crosthwaite,
Peter Maydell, Richard Henderson, Stefan Hajnoczi,
Thomas Lendacky, Borislav Petkov, Alexander Graf, Bruce Rogers,
Richard Henderson
On Thu, Mar 08, 2018 at 04:22:52PM -0600, Brijesh Singh wrote:
>
>
> On 3/8/18 10:49 AM, Daniel P. Berrangé wrote:
> > On Thu, Mar 08, 2018 at 06:48:41AM -0600, Brijesh Singh wrote:
> >> Add a new memory encryption object 'sev-guest'. The object will be used
> >> to create enrypted VMs on AMD EPYC CPU. The object provides the properties
> >> to pass guest owner's public Diffie-hellman key, guest policy and session
> >> information required to create the memory encryption context within the
> >> SEV firmware.
> >>
> >> e.g to launch SEV guest
> >> # $QEMU \
> >> -object sev-guest,id=sev0 \
> >> -machine ....,memory-encryption=sev0
> >>
> >> Cc: Paolo Bonzini <pbonzini@redhat.com>
> >> Cc: Richard Henderson <rth@twiddle.net>
> >> Cc: Eduardo Habkost <ehabkost@redhat.com>
> >> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
> >
> >> diff --git a/qemu-options.hx b/qemu-options.hx
> >> index 4c280142c52c..6113bce08a8c 100644
> >> --- a/qemu-options.hx
> >> +++ b/qemu-options.hx
> >> @@ -4353,6 +4353,50 @@ contents of @code{iv.b64} to the second secret
> >> data=$SECRET,iv=$(<iv.b64)
> >> @end example
> >>
> >> +@item -object sev-guest,id=@var{id},cbitpos=@var{cbitpos},reduced-phys-bits=@var{val},[sev-device=@var{string},policy=@var{policy},handle=@var{handle},dh-cert-file=@var{file},session-file=@var{file}]
> >> +
> >> +Create a Secure Encrypted Virtualization (SEV) guest object, which can be used
> >> +to provide the guest memory encryption support on AMD processors.
> >> +
> >> +When memory encryption is enabled, one of the physical address bit (aka the
> >> +C-bit) is utilized to mark if a memory page is protected. The @option{cbitpos}
> >> +is used to provide the C-bit position. The C-bit position is Host family dependent
> >> +hence user must provide this value. On EPYC, the value should be 47.
> >> +
> >> +When memory encryption is enabled, we loose certain bits in physical address space.
> >> +The @option{reduced-phys-bits} is used to provide the number of bits we loose in
> >> +physical address space. Similar to C-bit, the value is Host family dependent.
> >> +On EPYC, the value should be 5.
> > Is it valid to specify a different value for either of these properties ?
> > eg what happens if I pass cbitpos=45 instead of 47 on an EPYC host ?
>
> On EPYC, passing anything other than 47 will trigger error during SEV
> guest initialization. The value of Cbit position is host dependent, the
> value is readonly and can be obtained through the host CPUID. The
> cbitpos must be same between guest and host. Please note that the pte's
> in guest page table will need to use the cbitpos information to mark
> the pages as encrypted. If cbit position given to the guest is different
> from the host then guest will fail to execute.
>
> >
> > In particular I thinking about possible migration scenario, where EPYC
> > uses 47 by default but some $NEXT AMD CPU uses 48 by default. In that
> > case we might want to use '47' on both CPUs if we need ability to live
> > migrate between different host CPU generations. Would that be valid ?
>
> We will not be able to migrate SEV guests if cbit position does not
> match between the source and destination hosts. Since during migration,
> the destination guest is launched with same QEMU cli as source hence
> cbitpos check in QEMU will catch it and fail the new launch. Optionally,
> user can call query-sev-capabilities on both source and destination to
> see if cbitpos is compatible before attempting to migrate the guest.
>
> > On the flip side, if the value really it strictly tied to the host
> > CPU family and no deviation is permitted, could the kernel not just
> > pick the right value automatically avoiding the config option ?
> >
>
> I think doing so will be an issue for the migration. Consider your above
> use case, a SEV guest is running on EPYC with cbitpos=47 and if we
> migrate to some $NEXT AMD CPU which uses need to use cbitpos=48 and we
> will fail to resume the guest on destination after migrating.
Exactly, in other words these two options are part of the guest
ABI, and QEMU promises to never make the guest ABI depend on the
host hardware unless you're using "-cpu host".
In theory we could make QEMU choose the right values
automatically if we document very clearly that the default
behavior is unsafe. But I would rather not take that risk and
force management software to be aware of the gotchas involved in
using SEV + live-migration.
--
Eduardo
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v12 26/28] qmp: add query-sev-capabilities command
2018-03-08 17:05 ` [Qemu-devel] " Daniel P. Berrangé
@ 2018-03-08 22:52 ` Brijesh Singh
-1 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 22:52 UTC (permalink / raw)
To: Daniel P. Berrangé
Cc: Peter Maydell, brijesh.singh, kvm, Michael S. Tsirkin,
Stefan Hajnoczi, qemu-devel, Alexander Graf, Edgar E. Iglesias,
Markus Armbruster, Bruce Rogers, Christian Borntraeger,
Marcel Apfelbaum, Borislav Petkov, Thomas Lendacky,
Eduardo Habkost, Richard Henderson, Dr. David Alan Gilbert,
Alistair Francis, Cornelia Huck, Peter Crosthwaite,
Paolo Bonzini
On 3/8/18 11:05 AM, Daniel P. Berrangé wrote:
> On Thu, Mar 08, 2018 at 06:48:59AM -0600, Brijesh Singh wrote:
>> The command can be used by libvirt to query the SEV capabilities.
>>
>> Cc: "Daniel P. Berrangé" <berrange@redhat.com>
>> Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
>> Cc: Markus Armbruster <armbru@redhat.com>
>> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
>> ---
>> monitor.c | 7 +++++++
>> qapi/misc.json | 42 ++++++++++++++++++++++++++++++++++++++++++
>> target/i386/monitor.c | 6 ++++++
>> 3 files changed, 55 insertions(+)
>>
>> diff --git a/monitor.c b/monitor.c
>> index d53ecc5ddab3..29ce695a80d5 100644
>> --- a/monitor.c
>> +++ b/monitor.c
>> @@ -985,6 +985,7 @@ static void qmp_unregister_commands_hack(void)
>> qmp_unregister_command(&qmp_commands, "rtc-reset-reinjection");
>> qmp_unregister_command(&qmp_commands, "query-sev");
>> qmp_unregister_command(&qmp_commands, "query-sev-launch-measure");
>> + qmp_unregister_command(&qmp_commands, "query-sev-capabilities");
>> #endif
>> #ifndef TARGET_S390X
>> qmp_unregister_command(&qmp_commands, "dump-skeys");
>> @@ -4117,6 +4118,12 @@ SevLaunchMeasureInfo *qmp_query_sev_launch_measure(Error **errp)
>> error_setg(errp, QERR_FEATURE_DISABLED, "query-sev-launch-measure");
>> return NULL;
>> }
>> +
>> +SevCapability *qmp_query_sev_capabilities(Error **errp)
>> +{
>> + error_setg(errp, QERR_FEATURE_DISABLED, "query-sev-capabilities");
>> + return NULL;
>> +}
>> #endif
>>
>> #ifndef TARGET_S390X
>> diff --git a/qapi/misc.json b/qapi/misc.json
>> index a39c43aa64b1..37c89663d8f4 100644
>> --- a/qapi/misc.json
>> +++ b/qapi/misc.json
>> @@ -3306,3 +3306,45 @@
>> #
>> ##
>> { 'command': 'query-sev-launch-measure', 'returns': 'SevLaunchMeasureInfo' }
>> +
>> +##
>> +# @SevCapability:
>> +#
>> +# The struct describes capability for a Secure Encrypted Virtualization
>> +# feature.
>> +#
>> +# @pdh: Platform Diffie-Hellman key
>> +#
>> +# @cert-chain: PDH certificate chain
> Are either of these base64 encoded ? If so nice to document that.
Yep, they are base64 encoded, I will update the doc.
>
>> +#
>> +# @cbitpos: C-bit location in page table entry
>> +#
>> +# @reduced-phys-bits: Number of physical Address bit reduction when SEV is
>> +# enabled
>> +#
>> +# Since: 2.12
>> +##
>> +{ 'struct': 'SevCapability',
>> + 'data': { 'pdh': 'str',
>> + 'cert-chain': 'str',
>> + 'cbitpos': 'int',
>> + 'reduced-phys-bits': 'int'} }
> Regardless of answer to above Q,
>
> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
>
>
> Regards,
> Daniel
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [Qemu-devel] [PATCH v12 26/28] qmp: add query-sev-capabilities command
@ 2018-03-08 22:52 ` Brijesh Singh
0 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-08 22:52 UTC (permalink / raw)
To: Daniel P. Berrangé
Cc: brijesh.singh, qemu-devel, Alistair Francis,
Christian Borntraeger, Cornelia Huck, Dr. David Alan Gilbert,
Michael S. Tsirkin, Edgar E. Iglesias, Eduardo Habkost,
Eric Blake, kvm, Marcel Apfelbaum, Markus Armbruster,
Paolo Bonzini, Peter Crosthwaite, Peter Maydell,
Richard Henderson, Stefan Hajnoczi, Thomas Lendacky,
Borislav Petkov, Alexander Graf, Bruce Rogers
On 3/8/18 11:05 AM, Daniel P. Berrangé wrote:
> On Thu, Mar 08, 2018 at 06:48:59AM -0600, Brijesh Singh wrote:
>> The command can be used by libvirt to query the SEV capabilities.
>>
>> Cc: "Daniel P. Berrangé" <berrange@redhat.com>
>> Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
>> Cc: Markus Armbruster <armbru@redhat.com>
>> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
>> ---
>> monitor.c | 7 +++++++
>> qapi/misc.json | 42 ++++++++++++++++++++++++++++++++++++++++++
>> target/i386/monitor.c | 6 ++++++
>> 3 files changed, 55 insertions(+)
>>
>> diff --git a/monitor.c b/monitor.c
>> index d53ecc5ddab3..29ce695a80d5 100644
>> --- a/monitor.c
>> +++ b/monitor.c
>> @@ -985,6 +985,7 @@ static void qmp_unregister_commands_hack(void)
>> qmp_unregister_command(&qmp_commands, "rtc-reset-reinjection");
>> qmp_unregister_command(&qmp_commands, "query-sev");
>> qmp_unregister_command(&qmp_commands, "query-sev-launch-measure");
>> + qmp_unregister_command(&qmp_commands, "query-sev-capabilities");
>> #endif
>> #ifndef TARGET_S390X
>> qmp_unregister_command(&qmp_commands, "dump-skeys");
>> @@ -4117,6 +4118,12 @@ SevLaunchMeasureInfo *qmp_query_sev_launch_measure(Error **errp)
>> error_setg(errp, QERR_FEATURE_DISABLED, "query-sev-launch-measure");
>> return NULL;
>> }
>> +
>> +SevCapability *qmp_query_sev_capabilities(Error **errp)
>> +{
>> + error_setg(errp, QERR_FEATURE_DISABLED, "query-sev-capabilities");
>> + return NULL;
>> +}
>> #endif
>>
>> #ifndef TARGET_S390X
>> diff --git a/qapi/misc.json b/qapi/misc.json
>> index a39c43aa64b1..37c89663d8f4 100644
>> --- a/qapi/misc.json
>> +++ b/qapi/misc.json
>> @@ -3306,3 +3306,45 @@
>> #
>> ##
>> { 'command': 'query-sev-launch-measure', 'returns': 'SevLaunchMeasureInfo' }
>> +
>> +##
>> +# @SevCapability:
>> +#
>> +# The struct describes capability for a Secure Encrypted Virtualization
>> +# feature.
>> +#
>> +# @pdh: Platform Diffie-Hellman key
>> +#
>> +# @cert-chain: PDH certificate chain
> Are either of these base64 encoded ? If so nice to document that.
Yep, they are base64 encoded, I will update the doc.
>
>> +#
>> +# @cbitpos: C-bit location in page table entry
>> +#
>> +# @reduced-phys-bits: Number of physical Address bit reduction when SEV is
>> +# enabled
>> +#
>> +# Since: 2.12
>> +##
>> +{ 'struct': 'SevCapability',
>> + 'data': { 'pdh': 'str',
>> + 'cert-chain': 'str',
>> + 'cbitpos': 'int',
>> + 'reduced-phys-bits': 'int'} }
> Regardless of answer to above Q,
>
> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
>
>
> Regards,
> Daniel
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v12 28/28] tests/qmp-test: blacklist sev specific qmp commands
2018-03-08 21:45 ` [Qemu-devel] " Eduardo Habkost
@ 2018-03-08 23:22 ` Daniel P. Berrange
-1 siblings, 0 replies; 114+ messages in thread
From: Daniel P. Berrange @ 2018-03-08 23:22 UTC (permalink / raw)
To: Eduardo Habkost
Cc: Edgar E. Iglesias, Peter Maydell, Borislav Petkov, Brijesh Singh,
kvm, Michael S. Tsirkin, Marcel Apfelbaum, Markus Armbruster,
Peter Crosthwaite, Richard Henderson, qemu-devel,
Dr. David Alan Gilbert, Christian Borntraeger, Alexander Graf,
Stefan Hajnoczi, Cornelia Huck, Paolo Bonzini, Thomas Lendacky,
Alistair Francis, Bruce Rogers
On Thu, Mar 08, 2018 at 06:45:04PM -0300, Eduardo Habkost wrote:
> On Thu, Mar 08, 2018 at 02:18:55PM -0600, Brijesh Singh wrote:
> >
> >
> > On 3/8/18 11:08 AM, Daniel P. Berrangé wrote:
> > > On Thu, Mar 08, 2018 at 06:49:01AM -0600, Brijesh Singh wrote:
> > >> Blacklist the following commands to fix the 'make check' failure.
> > >>
> > >> query-sev-launch-measure: it returns meaninful data only when we launch
> > >> SEV guest otherwise the command returns an error.
> > >>
> > >> query-sev: it return an error when SEV is not available on host (e.g non
> > >> X86 platform or KVM is disabled at the build time)
> > >>
> > >> query-sev-capabilities: it returns an error when SEV feature is not
> > >> available on host machine.
> > > We generally expect 'make check' to succeed on every single patch
> > > in a series, so that 'git bisect' doesn't break.
> > >
> > > So you should add each command to the blacklist in the same commit
> > > that introduced the failure in the first place.
> >
> >
> > Sure, I can quickly send the updated patch series to address your this
> > concern, but before spamming everyone's inbox I was wondering if I can
> > get some indication whether this series will make into 2.12 merge.
> >
> > Paolo, Eduardo and Richard,
> >
> > Most of the changes are in x86 directory hence any thought if you are
> > considering this series for 2.12 ? I have been testing the series with
> > and without SEV support and so far have not ran into any issue. if you
> > are not planning to pull this series in 2.12 then I will wait a bit
> > longer to get more feedback before sending the updates to address
> > Daniel's comment. thanks
>
> Trying to merge it before 2.12 soft freeze (next Tuesday) still
> looks like a reasonable goal to me. What do others think?
I've only really looked at the QAPI / QMP bits and they seem fine from
pov of libvirt's needs - just very minor comments. So not objection from
me on that area of the code.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [Qemu-devel] [PATCH v12 28/28] tests/qmp-test: blacklist sev specific qmp commands
@ 2018-03-08 23:22 ` Daniel P. Berrange
0 siblings, 0 replies; 114+ messages in thread
From: Daniel P. Berrange @ 2018-03-08 23:22 UTC (permalink / raw)
To: Eduardo Habkost
Cc: Brijesh Singh, qemu-devel, Alistair Francis,
Christian Borntraeger, Cornelia Huck, Dr. David Alan Gilbert,
Michael S. Tsirkin, Edgar E. Iglesias, Eric Blake, kvm,
Marcel Apfelbaum, Markus Armbruster, Paolo Bonzini,
Peter Crosthwaite, Peter Maydell, Richard Henderson,
Stefan Hajnoczi, Thomas Lendacky, Borislav Petkov,
Alexander Graf, Bruce Rogers
On Thu, Mar 08, 2018 at 06:45:04PM -0300, Eduardo Habkost wrote:
> On Thu, Mar 08, 2018 at 02:18:55PM -0600, Brijesh Singh wrote:
> >
> >
> > On 3/8/18 11:08 AM, Daniel P. Berrangé wrote:
> > > On Thu, Mar 08, 2018 at 06:49:01AM -0600, Brijesh Singh wrote:
> > >> Blacklist the following commands to fix the 'make check' failure.
> > >>
> > >> query-sev-launch-measure: it returns meaninful data only when we launch
> > >> SEV guest otherwise the command returns an error.
> > >>
> > >> query-sev: it return an error when SEV is not available on host (e.g non
> > >> X86 platform or KVM is disabled at the build time)
> > >>
> > >> query-sev-capabilities: it returns an error when SEV feature is not
> > >> available on host machine.
> > > We generally expect 'make check' to succeed on every single patch
> > > in a series, so that 'git bisect' doesn't break.
> > >
> > > So you should add each command to the blacklist in the same commit
> > > that introduced the failure in the first place.
> >
> >
> > Sure, I can quickly send the updated patch series to address your this
> > concern, but before spamming everyone's inbox I was wondering if I can
> > get some indication whether this series will make into 2.12 merge.
> >
> > Paolo, Eduardo and Richard,
> >
> > Most of the changes are in x86 directory hence any thought if you are
> > considering this series for 2.12 ? I have been testing the series with
> > and without SEV support and so far have not ran into any issue. if you
> > are not planning to pull this series in 2.12 then I will wait a bit
> > longer to get more feedback before sending the updates to address
> > Daniel's comment. thanks
>
> Trying to merge it before 2.12 soft freeze (next Tuesday) still
> looks like a reasonable goal to me. What do others think?
I've only really looked at the QAPI / QMP bits and they seem fine from
pov of libvirt's needs - just very minor comments. So not objection from
me on that area of the code.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v12 28/28] tests/qmp-test: blacklist sev specific qmp commands
2018-03-08 21:45 ` [Qemu-devel] " Eduardo Habkost
@ 2018-03-09 10:12 ` Dr. David Alan Gilbert
-1 siblings, 0 replies; 114+ messages in thread
From: Dr. David Alan Gilbert @ 2018-03-09 10:12 UTC (permalink / raw)
To: Eduardo Habkost
Cc: Edgar E. Iglesias, Peter Maydell, kvm, Michael S. Tsirkin,
Marcel Apfelbaum, Markus Armbruster, Stefan Hajnoczi,
Peter Crosthwaite, Richard Henderson, qemu-devel,
Alistair Francis, Christian Borntraeger, Alexander Graf,
Paolo Bonzini, Cornelia Huck, Brijesh Singh, Thomas Lendacky,
Borislav Petkov, Bruce Rogers
* Eduardo Habkost (ehabkost@redhat.com) wrote:
> On Thu, Mar 08, 2018 at 02:18:55PM -0600, Brijesh Singh wrote:
> >
> >
> > On 3/8/18 11:08 AM, Daniel P. Berrangé wrote:
> > > On Thu, Mar 08, 2018 at 06:49:01AM -0600, Brijesh Singh wrote:
> > >> Blacklist the following commands to fix the 'make check' failure.
> > >>
> > >> query-sev-launch-measure: it returns meaninful data only when we launch
> > >> SEV guest otherwise the command returns an error.
> > >>
> > >> query-sev: it return an error when SEV is not available on host (e.g non
> > >> X86 platform or KVM is disabled at the build time)
> > >>
> > >> query-sev-capabilities: it returns an error when SEV feature is not
> > >> available on host machine.
> > > We generally expect 'make check' to succeed on every single patch
> > > in a series, so that 'git bisect' doesn't break.
> > >
> > > So you should add each command to the blacklist in the same commit
> > > that introduced the failure in the first place.
> >
> >
> > Sure, I can quickly send the updated patch series to address your this
> > concern, but before spamming everyone's inbox I was wondering if I can
> > get some indication whether this series will make into 2.12 merge.
> >
> > Paolo, Eduardo and Richard,
> >
> > Most of the changes are in x86 directory hence any thought if you are
> > considering this series for 2.12 ? I have been testing the series with
> > and without SEV support and so far have not ran into any issue. if you
> > are not planning to pull this series in 2.12 then I will wait a bit
> > longer to get more feedback before sending the updates to address
> > Daniel's comment. thanks
>
> Trying to merge it before 2.12 soft freeze (next Tuesday) still
> looks like a reasonable goal to me. What do others think?
I've only looked at a few general comments and things but it looks like
it's getting there; I don't think it's had many comments from the KVM
side yet.
Dave
> --
> Eduardo
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [Qemu-devel] [PATCH v12 28/28] tests/qmp-test: blacklist sev specific qmp commands
@ 2018-03-09 10:12 ` Dr. David Alan Gilbert
0 siblings, 0 replies; 114+ messages in thread
From: Dr. David Alan Gilbert @ 2018-03-09 10:12 UTC (permalink / raw)
To: Eduardo Habkost
Cc: Brijesh Singh, Daniel P. Berrangé,
qemu-devel, Alistair Francis, Christian Borntraeger,
Cornelia Huck, Michael S. Tsirkin, Edgar E. Iglesias, Eric Blake,
kvm, Marcel Apfelbaum, Markus Armbruster, Paolo Bonzini,
Peter Crosthwaite, Peter Maydell, Richard Henderson,
Stefan Hajnoczi, Thomas Lendacky, Borislav Petkov,
Alexander Graf, Bruce Rogers
* Eduardo Habkost (ehabkost@redhat.com) wrote:
> On Thu, Mar 08, 2018 at 02:18:55PM -0600, Brijesh Singh wrote:
> >
> >
> > On 3/8/18 11:08 AM, Daniel P. Berrangé wrote:
> > > On Thu, Mar 08, 2018 at 06:49:01AM -0600, Brijesh Singh wrote:
> > >> Blacklist the following commands to fix the 'make check' failure.
> > >>
> > >> query-sev-launch-measure: it returns meaninful data only when we launch
> > >> SEV guest otherwise the command returns an error.
> > >>
> > >> query-sev: it return an error when SEV is not available on host (e.g non
> > >> X86 platform or KVM is disabled at the build time)
> > >>
> > >> query-sev-capabilities: it returns an error when SEV feature is not
> > >> available on host machine.
> > > We generally expect 'make check' to succeed on every single patch
> > > in a series, so that 'git bisect' doesn't break.
> > >
> > > So you should add each command to the blacklist in the same commit
> > > that introduced the failure in the first place.
> >
> >
> > Sure, I can quickly send the updated patch series to address your this
> > concern, but before spamming everyone's inbox I was wondering if I can
> > get some indication whether this series will make into 2.12 merge.
> >
> > Paolo, Eduardo and Richard,
> >
> > Most of the changes are in x86 directory hence any thought if you are
> > considering this series for 2.12 ? I have been testing the series with
> > and without SEV support and so far have not ran into any issue. if you
> > are not planning to pull this series in 2.12 then I will wait a bit
> > longer to get more feedback before sending the updates to address
> > Daniel's comment. thanks
>
> Trying to merge it before 2.12 soft freeze (next Tuesday) still
> looks like a reasonable goal to me. What do others think?
I've only looked at a few general comments and things but it looks like
it's getting there; I don't think it's had many comments from the KVM
side yet.
Dave
> --
> Eduardo
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v12 10/28] include: add psp-sev.h header file
2018-03-08 16:54 ` [Qemu-devel] " Daniel P. Berrangé
@ 2018-03-09 12:24 ` Dr. David Alan Gilbert
-1 siblings, 0 replies; 114+ messages in thread
From: Dr. David Alan Gilbert @ 2018-03-09 12:24 UTC (permalink / raw)
To: Daniel P. Berrangé
Cc: Peter Maydell, Brijesh Singh, kvm, Michael S. Tsirkin,
Stefan Hajnoczi, qemu-devel, Alexander Graf, Edgar E. Iglesias,
Markus Armbruster, Bruce Rogers, Christian Borntraeger,
Marcel Apfelbaum, Borislav Petkov, Thomas Lendacky,
Eduardo Habkost, Richard Henderson, Alistair Francis,
Cornelia Huck, Richard Henderson, Peter Crosthwaite,
Paolo Bonzini
* Daniel P. Berrangé (berrange@redhat.com) wrote:
> On Thu, Mar 08, 2018 at 06:48:43AM -0600, Brijesh Singh wrote:
> > The header file provide the ioctl command and structure to communicate
> > with /dev/sev device.
> >
> > Cc: Paolo Bonzini <pbonzini@redhat.com>
> > Cc: Richard Henderson <rth@twiddle.net>
> > Cc: Eduardo Habkost <ehabkost@redhat.com>
> > Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
> > ---
> > linux-headers/linux/psp-sev.h | 142 ++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 142 insertions(+)
> > create mode 100644 linux-headers/linux/psp-sev.h
> >
> > diff --git a/linux-headers/linux/psp-sev.h b/linux-headers/linux/psp-sev.h
> > new file mode 100644
> > index 000000000000..33e247471ae0
> > --- /dev/null
> > +++ b/linux-headers/linux/psp-sev.h
> > @@ -0,0 +1,142 @@
> > +/*
> > + * Userspace interface for AMD Secure Encrypted Virtualization (SEV)
> > + * platform management commands.
> > + *
> > + * Copyright (C) 2016-2017 Advanced Micro Devices, Inc.
> > + *
> > + * Author: Brijesh Singh <brijesh.singh@amd.com>
> > + *
> > + * SEV spec 0.14 is available at:
> > + * http://support.amd.com/TechDocs/55766_SEV-KM%20API_Specification.pdf
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + */
>
> Most of the files you've added are GPLv2-or-later. Is this one intentionally
> GPLv2-only instead ?
This is just a sync'd kernel header (which should just get sync'd with
the sync script).
Dave
> Regards,
> Daniel
> --
> |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org -o- https://fstop138.berrange.com :|
> |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [Qemu-devel] [PATCH v12 10/28] include: add psp-sev.h header file
@ 2018-03-09 12:24 ` Dr. David Alan Gilbert
0 siblings, 0 replies; 114+ messages in thread
From: Dr. David Alan Gilbert @ 2018-03-09 12:24 UTC (permalink / raw)
To: Daniel P. Berrangé
Cc: Brijesh Singh, qemu-devel, Alistair Francis,
Christian Borntraeger, Cornelia Huck, Michael S. Tsirkin,
Edgar E. Iglesias, Eduardo Habkost, Eric Blake, kvm,
Marcel Apfelbaum, Markus Armbruster, Paolo Bonzini,
Peter Crosthwaite, Peter Maydell, Richard Henderson,
Stefan Hajnoczi, Thomas Lendacky, Borislav Petkov,
Alexander Graf, Bruce Rogers, Richard Henderson
* Daniel P. Berrangé (berrange@redhat.com) wrote:
> On Thu, Mar 08, 2018 at 06:48:43AM -0600, Brijesh Singh wrote:
> > The header file provide the ioctl command and structure to communicate
> > with /dev/sev device.
> >
> > Cc: Paolo Bonzini <pbonzini@redhat.com>
> > Cc: Richard Henderson <rth@twiddle.net>
> > Cc: Eduardo Habkost <ehabkost@redhat.com>
> > Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
> > ---
> > linux-headers/linux/psp-sev.h | 142 ++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 142 insertions(+)
> > create mode 100644 linux-headers/linux/psp-sev.h
> >
> > diff --git a/linux-headers/linux/psp-sev.h b/linux-headers/linux/psp-sev.h
> > new file mode 100644
> > index 000000000000..33e247471ae0
> > --- /dev/null
> > +++ b/linux-headers/linux/psp-sev.h
> > @@ -0,0 +1,142 @@
> > +/*
> > + * Userspace interface for AMD Secure Encrypted Virtualization (SEV)
> > + * platform management commands.
> > + *
> > + * Copyright (C) 2016-2017 Advanced Micro Devices, Inc.
> > + *
> > + * Author: Brijesh Singh <brijesh.singh@amd.com>
> > + *
> > + * SEV spec 0.14 is available at:
> > + * http://support.amd.com/TechDocs/55766_SEV-KM%20API_Specification.pdf
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + */
>
> Most of the files you've added are GPLv2-or-later. Is this one intentionally
> GPLv2-only instead ?
This is just a sync'd kernel header (which should just get sync'd with
the sync script).
Dave
> Regards,
> Daniel
> --
> |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org -o- https://fstop138.berrange.com :|
> |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v12 10/28] include: add psp-sev.h header file
2018-03-09 12:24 ` [Qemu-devel] " Dr. David Alan Gilbert
@ 2018-03-12 10:32 ` Daniel P. Berrangé
-1 siblings, 0 replies; 114+ messages in thread
From: Daniel P. Berrangé @ 2018-03-12 10:32 UTC (permalink / raw)
To: Dr. David Alan Gilbert
Cc: Peter Maydell, Brijesh Singh, kvm, Michael S. Tsirkin,
Stefan Hajnoczi, qemu-devel, Alexander Graf, Edgar E. Iglesias,
Markus Armbruster, Bruce Rogers, Christian Borntraeger,
Marcel Apfelbaum, Borislav Petkov, Thomas Lendacky,
Eduardo Habkost, Richard Henderson, Alistair Francis,
Cornelia Huck, Richard Henderson, Peter Crosthwaite,
Paolo Bonzini
On Fri, Mar 09, 2018 at 12:24:06PM +0000, Dr. David Alan Gilbert wrote:
> * Daniel P. Berrangé (berrange@redhat.com) wrote:
> > On Thu, Mar 08, 2018 at 06:48:43AM -0600, Brijesh Singh wrote:
> > > The header file provide the ioctl command and structure to communicate
> > > with /dev/sev device.
> > >
> > > Cc: Paolo Bonzini <pbonzini@redhat.com>
> > > Cc: Richard Henderson <rth@twiddle.net>
> > > Cc: Eduardo Habkost <ehabkost@redhat.com>
> > > Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
> > > ---
> > > linux-headers/linux/psp-sev.h | 142 ++++++++++++++++++++++++++++++++++++++++++
> > > 1 file changed, 142 insertions(+)
> > > create mode 100644 linux-headers/linux/psp-sev.h
> > >
> > > diff --git a/linux-headers/linux/psp-sev.h b/linux-headers/linux/psp-sev.h
> > > new file mode 100644
> > > index 000000000000..33e247471ae0
> > > --- /dev/null
> > > +++ b/linux-headers/linux/psp-sev.h
> > > @@ -0,0 +1,142 @@
> > > +/*
> > > + * Userspace interface for AMD Secure Encrypted Virtualization (SEV)
> > > + * platform management commands.
> > > + *
> > > + * Copyright (C) 2016-2017 Advanced Micro Devices, Inc.
> > > + *
> > > + * Author: Brijesh Singh <brijesh.singh@amd.com>
> > > + *
> > > + * SEV spec 0.14 is available at:
> > > + * http://support.amd.com/TechDocs/55766_SEV-KM%20API_Specification.pdf
> > > + *
> > > + * This program is free software; you can redistribute it and/or modify
> > > + * it under the terms of the GNU General Public License version 2 as
> > > + * published by the Free Software Foundation.
> > > + */
> >
> > Most of the files you've added are GPLv2-or-later. Is this one intentionally
> > GPLv2-only instead ?
>
> This is just a sync'd kernel header (which should just get sync'd with
> the sync script).
Ok, no problem then.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [Qemu-devel] [PATCH v12 10/28] include: add psp-sev.h header file
@ 2018-03-12 10:32 ` Daniel P. Berrangé
0 siblings, 0 replies; 114+ messages in thread
From: Daniel P. Berrangé @ 2018-03-12 10:32 UTC (permalink / raw)
To: Dr. David Alan Gilbert
Cc: Brijesh Singh, qemu-devel, Alistair Francis,
Christian Borntraeger, Cornelia Huck, Michael S. Tsirkin,
Edgar E. Iglesias, Eduardo Habkost, Eric Blake, kvm,
Marcel Apfelbaum, Markus Armbruster, Paolo Bonzini,
Peter Crosthwaite, Peter Maydell, Richard Henderson,
Stefan Hajnoczi, Thomas Lendacky, Borislav Petkov,
Alexander Graf, Bruce Rogers, Richard Henderson
On Fri, Mar 09, 2018 at 12:24:06PM +0000, Dr. David Alan Gilbert wrote:
> * Daniel P. Berrangé (berrange@redhat.com) wrote:
> > On Thu, Mar 08, 2018 at 06:48:43AM -0600, Brijesh Singh wrote:
> > > The header file provide the ioctl command and structure to communicate
> > > with /dev/sev device.
> > >
> > > Cc: Paolo Bonzini <pbonzini@redhat.com>
> > > Cc: Richard Henderson <rth@twiddle.net>
> > > Cc: Eduardo Habkost <ehabkost@redhat.com>
> > > Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
> > > ---
> > > linux-headers/linux/psp-sev.h | 142 ++++++++++++++++++++++++++++++++++++++++++
> > > 1 file changed, 142 insertions(+)
> > > create mode 100644 linux-headers/linux/psp-sev.h
> > >
> > > diff --git a/linux-headers/linux/psp-sev.h b/linux-headers/linux/psp-sev.h
> > > new file mode 100644
> > > index 000000000000..33e247471ae0
> > > --- /dev/null
> > > +++ b/linux-headers/linux/psp-sev.h
> > > @@ -0,0 +1,142 @@
> > > +/*
> > > + * Userspace interface for AMD Secure Encrypted Virtualization (SEV)
> > > + * platform management commands.
> > > + *
> > > + * Copyright (C) 2016-2017 Advanced Micro Devices, Inc.
> > > + *
> > > + * Author: Brijesh Singh <brijesh.singh@amd.com>
> > > + *
> > > + * SEV spec 0.14 is available at:
> > > + * http://support.amd.com/TechDocs/55766_SEV-KM%20API_Specification.pdf
> > > + *
> > > + * This program is free software; you can redistribute it and/or modify
> > > + * it under the terms of the GNU General Public License version 2 as
> > > + * published by the Free Software Foundation.
> > > + */
> >
> > Most of the files you've added are GPLv2-or-later. Is this one intentionally
> > GPLv2-only instead ?
>
> This is just a sync'd kernel header (which should just get sync'd with
> the sync script).
Ok, no problem then.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v12 08/28] target/i386: add Secure Encrypted Virtulization (SEV) object
2018-03-08 22:44 ` [Qemu-devel] " Eduardo Habkost
@ 2018-03-13 8:42 ` Paolo Bonzini
-1 siblings, 0 replies; 114+ messages in thread
From: Paolo Bonzini @ 2018-03-13 8:42 UTC (permalink / raw)
To: Eduardo Habkost, Brijesh Singh
Cc: Edgar E. Iglesias, Peter Maydell, Borislav Petkov, kvm,
Michael S. Tsirkin, Stefan Hajnoczi, Alistair Francis,
Peter Crosthwaite, Richard Henderson, Alexander Graf, qemu-devel,
Christian Borntraeger, Dr. David Alan Gilbert, Marcel Apfelbaum,
Thomas Lendacky, Bruce Rogers, Cornelia Huck, Markus Armbruster,
Richard Henderson
On 08/03/2018 23:44, Eduardo Habkost wrote:
>> I think doing so will be an issue for the migration. Consider your above
>> use case, a SEV guest is running on EPYC with cbitpos=47 and if we
>> migrate to some $NEXT AMD CPU which uses need to use cbitpos=48 and we
>> will fail to resume the guest on destination after migrating.
>
> Exactly, in other words these two options are part of the guest
> ABI, and QEMU promises to never make the guest ABI depend on the
> host hardware unless you're using "-cpu host".
This is not entirely true; while MAXPHYADDR is constant downstream
unless using "-cpu host", in practice that behavior is wrong and a guest
could misbehave if passed a MAXPHYADDR that is different from the host's.
I think this is the same, and management software will have to live with it.
Paolo
> In theory we could make QEMU choose the right values
> automatically if we document very clearly that the default
> behavior is unsafe. But I would rather not take that risk and
> force management software to be aware of the gotchas involved in
> using SEV + live-migration.
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [Qemu-devel] [PATCH v12 08/28] target/i386: add Secure Encrypted Virtulization (SEV) object
@ 2018-03-13 8:42 ` Paolo Bonzini
0 siblings, 0 replies; 114+ messages in thread
From: Paolo Bonzini @ 2018-03-13 8:42 UTC (permalink / raw)
To: Eduardo Habkost, Brijesh Singh
Cc: Peter Maydell, kvm, Michael S. Tsirkin, Stefan Hajnoczi,
qemu-devel, Alexander Graf, Edgar E. Iglesias, Markus Armbruster,
Bruce Rogers, Christian Borntraeger, Marcel Apfelbaum,
Borislav Petkov, Thomas Lendacky, Richard Henderson,
Dr. David Alan Gilbert, Alistair Francis, Cornelia Huck,
Richard Henderson, Peter Crosthwaite
On 08/03/2018 23:44, Eduardo Habkost wrote:
>> I think doing so will be an issue for the migration. Consider your above
>> use case, a SEV guest is running on EPYC with cbitpos=47 and if we
>> migrate to some $NEXT AMD CPU which uses need to use cbitpos=48 and we
>> will fail to resume the guest on destination after migrating.
>
> Exactly, in other words these two options are part of the guest
> ABI, and QEMU promises to never make the guest ABI depend on the
> host hardware unless you're using "-cpu host".
This is not entirely true; while MAXPHYADDR is constant downstream
unless using "-cpu host", in practice that behavior is wrong and a guest
could misbehave if passed a MAXPHYADDR that is different from the host's.
I think this is the same, and management software will have to live with it.
Paolo
> In theory we could make QEMU choose the right values
> automatically if we document very clearly that the default
> behavior is unsafe. But I would rather not take that risk and
> force management software to be aware of the gotchas involved in
> using SEV + live-migration.
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v12 28/28] tests/qmp-test: blacklist sev specific qmp commands
2018-03-09 10:12 ` [Qemu-devel] " Dr. David Alan Gilbert
@ 2018-03-13 9:07 ` Paolo Bonzini
-1 siblings, 0 replies; 114+ messages in thread
From: Paolo Bonzini @ 2018-03-13 9:07 UTC (permalink / raw)
To: Dr. David Alan Gilbert, Eduardo Habkost
Cc: Edgar E. Iglesias, Peter Maydell, Cornelia Huck, Brijesh Singh,
kvm, Michael S. Tsirkin, Stefan Hajnoczi, Peter Crosthwaite,
Richard Henderson, Markus Armbruster, qemu-devel,
Christian Borntraeger, Alexander Graf, Borislav Petkov,
Marcel Apfelbaum, Thomas Lendacky, Alistair Francis,
Bruce Rogers
On 09/03/2018 11:12, Dr. David Alan Gilbert wrote:
> * Eduardo Habkost (ehabkost@redhat.com) wrote:
>> On Thu, Mar 08, 2018 at 02:18:55PM -0600, Brijesh Singh wrote:
>>>
>>>
>>> On 3/8/18 11:08 AM, Daniel P. Berrangé wrote:
>>>> On Thu, Mar 08, 2018 at 06:49:01AM -0600, Brijesh Singh wrote:
>>>>> Blacklist the following commands to fix the 'make check' failure.
>>>>>
>>>>> query-sev-launch-measure: it returns meaninful data only when we launch
>>>>> SEV guest otherwise the command returns an error.
>>>>>
>>>>> query-sev: it return an error when SEV is not available on host (e.g non
>>>>> X86 platform or KVM is disabled at the build time)
>>>>>
>>>>> query-sev-capabilities: it returns an error when SEV feature is not
>>>>> available on host machine.
>>>> We generally expect 'make check' to succeed on every single patch
>>>> in a series, so that 'git bisect' doesn't break.
>>>>
>>>> So you should add each command to the blacklist in the same commit
>>>> that introduced the failure in the first place.
>>>
>>>
>>> Sure, I can quickly send the updated patch series to address your this
>>> concern, but before spamming everyone's inbox I was wondering if I can
>>> get some indication whether this series will make into 2.12 merge.
>>>
>>> Paolo, Eduardo and Richard,
>>>
>>> Most of the changes are in x86 directory hence any thought if you are
>>> considering this series for 2.12 ? I have been testing the series with
>>> and without SEV support and so far have not ran into any issue. if you
>>> are not planning to pull this series in 2.12 then I will wait a bit
>>> longer to get more feedback before sending the updates to address
>>> Daniel's comment. thanks
>>
>> Trying to merge it before 2.12 soft freeze (next Tuesday) still
>> looks like a reasonable goal to me. What do others think?
>
> I've only looked at a few general comments and things but it looks like
> it's getting there; I don't think it's had many comments from the KVM
> side yet.
The KVM side is a pretty linear use of the kernel API. I'm not very
happy with the debug API for MemoryRegions (but it's not really
Brijesh's fault), so my plan would be to merge it without debug support.
Paolo
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [Qemu-devel] [PATCH v12 28/28] tests/qmp-test: blacklist sev specific qmp commands
@ 2018-03-13 9:07 ` Paolo Bonzini
0 siblings, 0 replies; 114+ messages in thread
From: Paolo Bonzini @ 2018-03-13 9:07 UTC (permalink / raw)
To: Dr. David Alan Gilbert, Eduardo Habkost
Cc: Edgar E. Iglesias, Peter Maydell, kvm, Michael S. Tsirkin,
Marcel Apfelbaum, Markus Armbruster, Stefan Hajnoczi,
Peter Crosthwaite, Richard Henderson, qemu-devel,
Alistair Francis, Christian Borntraeger, Alexander Graf,
Cornelia Huck, Brijesh Singh, Thomas Lendacky, Borislav Petkov,
Bruce Rogers
On 09/03/2018 11:12, Dr. David Alan Gilbert wrote:
> * Eduardo Habkost (ehabkost@redhat.com) wrote:
>> On Thu, Mar 08, 2018 at 02:18:55PM -0600, Brijesh Singh wrote:
>>>
>>>
>>> On 3/8/18 11:08 AM, Daniel P. Berrangé wrote:
>>>> On Thu, Mar 08, 2018 at 06:49:01AM -0600, Brijesh Singh wrote:
>>>>> Blacklist the following commands to fix the 'make check' failure.
>>>>>
>>>>> query-sev-launch-measure: it returns meaninful data only when we launch
>>>>> SEV guest otherwise the command returns an error.
>>>>>
>>>>> query-sev: it return an error when SEV is not available on host (e.g non
>>>>> X86 platform or KVM is disabled at the build time)
>>>>>
>>>>> query-sev-capabilities: it returns an error when SEV feature is not
>>>>> available on host machine.
>>>> We generally expect 'make check' to succeed on every single patch
>>>> in a series, so that 'git bisect' doesn't break.
>>>>
>>>> So you should add each command to the blacklist in the same commit
>>>> that introduced the failure in the first place.
>>>
>>>
>>> Sure, I can quickly send the updated patch series to address your this
>>> concern, but before spamming everyone's inbox I was wondering if I can
>>> get some indication whether this series will make into 2.12 merge.
>>>
>>> Paolo, Eduardo and Richard,
>>>
>>> Most of the changes are in x86 directory hence any thought if you are
>>> considering this series for 2.12 ? I have been testing the series with
>>> and without SEV support and so far have not ran into any issue. if you
>>> are not planning to pull this series in 2.12 then I will wait a bit
>>> longer to get more feedback before sending the updates to address
>>> Daniel's comment. thanks
>>
>> Trying to merge it before 2.12 soft freeze (next Tuesday) still
>> looks like a reasonable goal to me. What do others think?
>
> I've only looked at a few general comments and things but it looks like
> it's getting there; I don't think it's had many comments from the KVM
> side yet.
The KVM side is a pretty linear use of the kernel API. I'm not very
happy with the debug API for MemoryRegions (but it's not really
Brijesh's fault), so my plan would be to merge it without debug support.
Paolo
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v12 24/28] sev/i386: add migration blocker
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
@ 2018-03-13 9:33 ` Paolo Bonzini
-1 siblings, 0 replies; 114+ messages in thread
From: Paolo Bonzini @ 2018-03-13 9:33 UTC (permalink / raw)
To: Brijesh Singh, qemu-devel
Cc: Edgar E. Iglesias, Peter Maydell, Borislav Petkov,
Eduardo Habkost, kvm, Michael S. Tsirkin, Stefan Hajnoczi,
Alistair Francis, Peter Crosthwaite, Richard Henderson,
Alexander Graf, Markus Armbruster, Christian Borntraeger,
Marcel Apfelbaum, Thomas Lendacky, Bruce Rogers, Cornelia Huck,
Dr. David Alan Gilbert
On 08/03/2018 13:48, Brijesh Singh wrote:
> sev_set_guest_state(SEV_STATE_RUNNING);
> +
> + /* add migration blocker */
> + error_setg(&sev_mig_blocker,
> + "SEV: Migration is not implemented");
> + ret = migrate_add_blocker(sev_mig_blocker, &local_err);
> + if (local_err) {
> + error_report_err(local_err);
> + error_free(sev_mig_blocker);
> + exit(1);
> + }
> }
I think this should be in sev_guest_init instead? Does migration
transfer the measurement, or is it lost forever? Not a blocker though.
Paolo
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [Qemu-devel] [PATCH v12 24/28] sev/i386: add migration blocker
@ 2018-03-13 9:33 ` Paolo Bonzini
0 siblings, 0 replies; 114+ messages in thread
From: Paolo Bonzini @ 2018-03-13 9:33 UTC (permalink / raw)
To: Brijesh Singh, qemu-devel
Cc: Peter Maydell, kvm, Michael S. Tsirkin, Stefan Hajnoczi,
Alexander Graf, Edgar E. Iglesias, Markus Armbruster,
Bruce Rogers, Christian Borntraeger, Marcel Apfelbaum,
Borislav Petkov, Thomas Lendacky, Eduardo Habkost,
Richard Henderson, Dr. David Alan Gilbert, Alistair Francis,
Cornelia Huck, Peter Crosthwaite
On 08/03/2018 13:48, Brijesh Singh wrote:
> sev_set_guest_state(SEV_STATE_RUNNING);
> +
> + /* add migration blocker */
> + error_setg(&sev_mig_blocker,
> + "SEV: Migration is not implemented");
> + ret = migrate_add_blocker(sev_mig_blocker, &local_err);
> + if (local_err) {
> + error_report_err(local_err);
> + error_free(sev_mig_blocker);
> + exit(1);
> + }
> }
I think this should be in sev_guest_init instead? Does migration
transfer the measurement, or is it lost forever? Not a blocker though.
Paolo
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v12 28/28] tests/qmp-test: blacklist sev specific qmp commands
2018-03-13 9:07 ` [Qemu-devel] " Paolo Bonzini
@ 2018-03-13 11:21 ` Brijesh Singh
-1 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-13 11:21 UTC (permalink / raw)
To: Paolo Bonzini, Dr. David Alan Gilbert, Eduardo Habkost
Cc: Edgar E. Iglesias, Peter Maydell, Cornelia Huck, brijesh.singh,
kvm, Michael S. Tsirkin, Stefan Hajnoczi, Peter Crosthwaite,
Richard Henderson, Markus Armbruster, qemu-devel,
Christian Borntraeger, Alexander Graf, Borislav Petkov,
Marcel Apfelbaum, Thomas Lendacky, Alistair Francis,
Bruce Rogers
On 3/13/18 4:07 AM, Paolo Bonzini wrote:
> On 09/03/2018 11:12, Dr. David Alan Gilbert wrote:
>> * Eduardo Habkost (ehabkost@redhat.com) wrote:
>>> On Thu, Mar 08, 2018 at 02:18:55PM -0600, Brijesh Singh wrote:
>>>>
>>>> On 3/8/18 11:08 AM, Daniel P. Berrangé wrote:
>>>>> On Thu, Mar 08, 2018 at 06:49:01AM -0600, Brijesh Singh wrote:
>>>>>> Blacklist the following commands to fix the 'make check' failure.
>>>>>>
>>>>>> query-sev-launch-measure: it returns meaninful data only when we launch
>>>>>> SEV guest otherwise the command returns an error.
>>>>>>
>>>>>> query-sev: it return an error when SEV is not available on host (e.g non
>>>>>> X86 platform or KVM is disabled at the build time)
>>>>>>
>>>>>> query-sev-capabilities: it returns an error when SEV feature is not
>>>>>> available on host machine.
>>>>> We generally expect 'make check' to succeed on every single patch
>>>>> in a series, so that 'git bisect' doesn't break.
>>>>>
>>>>> So you should add each command to the blacklist in the same commit
>>>>> that introduced the failure in the first place.
>>>>
>>>> Sure, I can quickly send the updated patch series to address your this
>>>> concern, but before spamming everyone's inbox I was wondering if I can
>>>> get some indication whether this series will make into 2.12 merge.
>>>>
>>>> Paolo, Eduardo and Richard,
>>>>
>>>> Most of the changes are in x86 directory hence any thought if you are
>>>> considering this series for 2.12 ? I have been testing the series with
>>>> and without SEV support and so far have not ran into any issue. if you
>>>> are not planning to pull this series in 2.12 then I will wait a bit
>>>> longer to get more feedback before sending the updates to address
>>>> Daniel's comment. thanks
>>> Trying to merge it before 2.12 soft freeze (next Tuesday) still
>>> looks like a reasonable goal to me. What do others think?
>> I've only looked at a few general comments and things but it looks like
>> it's getting there; I don't think it's had many comments from the KVM
>> side yet.
> The KVM side is a pretty linear use of the kernel API. I'm not very
> happy with the debug API for MemoryRegions (but it's not really
> Brijesh's fault), so my plan would be to merge it without debug support.
Thanks Paolo, I am working to drop the complete debug support and will
send series very soon. I need to run some quick smoke test to make sure
I don't break SEV guest support.
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [Qemu-devel] [PATCH v12 28/28] tests/qmp-test: blacklist sev specific qmp commands
@ 2018-03-13 11:21 ` Brijesh Singh
0 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-13 11:21 UTC (permalink / raw)
To: Paolo Bonzini, Dr. David Alan Gilbert, Eduardo Habkost
Cc: brijesh.singh, Edgar E. Iglesias, Peter Maydell, kvm,
Michael S. Tsirkin, Marcel Apfelbaum, Markus Armbruster,
Stefan Hajnoczi, Peter Crosthwaite, Richard Henderson,
qemu-devel, Alistair Francis, Christian Borntraeger,
Alexander Graf, Cornelia Huck, Thomas Lendacky, Borislav Petkov,
Bruce Rogers
On 3/13/18 4:07 AM, Paolo Bonzini wrote:
> On 09/03/2018 11:12, Dr. David Alan Gilbert wrote:
>> * Eduardo Habkost (ehabkost@redhat.com) wrote:
>>> On Thu, Mar 08, 2018 at 02:18:55PM -0600, Brijesh Singh wrote:
>>>>
>>>> On 3/8/18 11:08 AM, Daniel P. Berrangé wrote:
>>>>> On Thu, Mar 08, 2018 at 06:49:01AM -0600, Brijesh Singh wrote:
>>>>>> Blacklist the following commands to fix the 'make check' failure.
>>>>>>
>>>>>> query-sev-launch-measure: it returns meaninful data only when we launch
>>>>>> SEV guest otherwise the command returns an error.
>>>>>>
>>>>>> query-sev: it return an error when SEV is not available on host (e.g non
>>>>>> X86 platform or KVM is disabled at the build time)
>>>>>>
>>>>>> query-sev-capabilities: it returns an error when SEV feature is not
>>>>>> available on host machine.
>>>>> We generally expect 'make check' to succeed on every single patch
>>>>> in a series, so that 'git bisect' doesn't break.
>>>>>
>>>>> So you should add each command to the blacklist in the same commit
>>>>> that introduced the failure in the first place.
>>>>
>>>> Sure, I can quickly send the updated patch series to address your this
>>>> concern, but before spamming everyone's inbox I was wondering if I can
>>>> get some indication whether this series will make into 2.12 merge.
>>>>
>>>> Paolo, Eduardo and Richard,
>>>>
>>>> Most of the changes are in x86 directory hence any thought if you are
>>>> considering this series for 2.12 ? I have been testing the series with
>>>> and without SEV support and so far have not ran into any issue. if you
>>>> are not planning to pull this series in 2.12 then I will wait a bit
>>>> longer to get more feedback before sending the updates to address
>>>> Daniel's comment. thanks
>>> Trying to merge it before 2.12 soft freeze (next Tuesday) still
>>> looks like a reasonable goal to me. What do others think?
>> I've only looked at a few general comments and things but it looks like
>> it's getting there; I don't think it's had many comments from the KVM
>> side yet.
> The KVM side is a pretty linear use of the kernel API. I'm not very
> happy with the debug API for MemoryRegions (but it's not really
> Brijesh's fault), so my plan would be to merge it without debug support.
Thanks Paolo, I am working to drop the complete debug support and will
send series very soon. I need to run some quick smoke test to make sure
I don't break SEV guest support.
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v12 24/28] sev/i386: add migration blocker
2018-03-13 9:33 ` [Qemu-devel] " Paolo Bonzini
@ 2018-03-13 11:28 ` Brijesh Singh
-1 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-13 11:28 UTC (permalink / raw)
To: Paolo Bonzini, qemu-devel
Cc: Edgar E. Iglesias, Peter Maydell, Borislav Petkov, brijesh.singh,
Eduardo Habkost, kvm, Michael S. Tsirkin, Stefan Hajnoczi,
Alistair Francis, Peter Crosthwaite, Richard Henderson,
Alexander Graf, Markus Armbruster, Christian Borntraeger,
Marcel Apfelbaum, Thomas Lendacky, Bruce Rogers, Cornelia Huck,
Dr. David Alan Gilbert
On 3/13/18 4:33 AM, Paolo Bonzini wrote:
> On 08/03/2018 13:48, Brijesh Singh wrote:
>> sev_set_guest_state(SEV_STATE_RUNNING);
>> +
>> + /* add migration blocker */
>> + error_setg(&sev_mig_blocker,
>> + "SEV: Migration is not implemented");
>> + ret = migrate_add_blocker(sev_mig_blocker, &local_err);
>> + if (local_err) {
>> + error_report_err(local_err);
>> + error_free(sev_mig_blocker);
>> + exit(1);
>> + }
>> }
> I think this should be in sev_guest_init instead? Does migration
> transfer the measurement, or is it lost forever? Not a blocker though.
The launch measurement does not get transferred during the migration.
During migration we get totally different measurement which is wrapped
with transport key etc and that need to send to destination. IIRC, in my
first attempt I was adding this blocker in sev_guest_init() but
migration_add_blocker() was failing because sev_guest_init() is called
before the migration_object_init().
>
> Paolo
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [Qemu-devel] [PATCH v12 24/28] sev/i386: add migration blocker
@ 2018-03-13 11:28 ` Brijesh Singh
0 siblings, 0 replies; 114+ messages in thread
From: Brijesh Singh @ 2018-03-13 11:28 UTC (permalink / raw)
To: Paolo Bonzini, qemu-devel
Cc: brijesh.singh, Peter Maydell, kvm, Michael S. Tsirkin,
Stefan Hajnoczi, Alexander Graf, Edgar E. Iglesias,
Markus Armbruster, Bruce Rogers, Christian Borntraeger,
Marcel Apfelbaum, Borislav Petkov, Thomas Lendacky,
Eduardo Habkost, Richard Henderson, Dr. David Alan Gilbert,
Alistair Francis, Cornelia Huck, Peter Crosthwaite
On 3/13/18 4:33 AM, Paolo Bonzini wrote:
> On 08/03/2018 13:48, Brijesh Singh wrote:
>> sev_set_guest_state(SEV_STATE_RUNNING);
>> +
>> + /* add migration blocker */
>> + error_setg(&sev_mig_blocker,
>> + "SEV: Migration is not implemented");
>> + ret = migrate_add_blocker(sev_mig_blocker, &local_err);
>> + if (local_err) {
>> + error_report_err(local_err);
>> + error_free(sev_mig_blocker);
>> + exit(1);
>> + }
>> }
> I think this should be in sev_guest_init instead? Does migration
> transfer the measurement, or is it lost forever? Not a blocker though.
The launch measurement does not get transferred during the migration.
During migration we get totally different measurement which is wrapped
with transport key etc and that need to send to destination. IIRC, in my
first attempt I was adding this blocker in sev_guest_init() but
migration_add_blocker() was failing because sev_guest_init() is called
before the migration_object_init().
>
> Paolo
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v12 28/28] tests/qmp-test: blacklist sev specific qmp commands
2018-03-13 11:21 ` [Qemu-devel] " Brijesh Singh
@ 2018-03-13 11:36 ` Paolo Bonzini
-1 siblings, 0 replies; 114+ messages in thread
From: Paolo Bonzini @ 2018-03-13 11:36 UTC (permalink / raw)
To: Brijesh Singh, Dr. David Alan Gilbert, Eduardo Habkost
Cc: Edgar E. Iglesias, Peter Maydell, kvm, Michael S. Tsirkin,
Marcel Apfelbaum, Stefan Hajnoczi, Alistair Francis,
Peter Crosthwaite, Richard Henderson, Markus Armbruster,
qemu-devel, Christian Borntraeger, Alexander Graf, Cornelia Huck,
Thomas Lendacky, Borislav Petkov, Bruce Rogers
On 13/03/2018 12:21, Brijesh Singh wrote:
>> The KVM side is a pretty linear use of the kernel API. I'm not very
>> happy with the debug API for MemoryRegions (but it's not really
>> Brijesh's fault), so my plan would be to merge it without debug support.
>
> Thanks Paolo, I am working to drop the complete debug support and will
> send series very soon. I need to run some quick smoke test to make sure
> I don't break SEV guest support.
Just test the pull request I'll send in less than an hour. :)
Paolo
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [Qemu-devel] [PATCH v12 28/28] tests/qmp-test: blacklist sev specific qmp commands
@ 2018-03-13 11:36 ` Paolo Bonzini
0 siblings, 0 replies; 114+ messages in thread
From: Paolo Bonzini @ 2018-03-13 11:36 UTC (permalink / raw)
To: Brijesh Singh, Dr. David Alan Gilbert, Eduardo Habkost
Cc: Edgar E. Iglesias, Peter Maydell, Cornelia Huck, kvm,
Michael S. Tsirkin, Stefan Hajnoczi, Peter Crosthwaite,
Richard Henderson, Markus Armbruster, qemu-devel,
Christian Borntraeger, Alexander Graf, Borislav Petkov,
Marcel Apfelbaum, Thomas Lendacky, Alistair Francis,
Bruce Rogers
On 13/03/2018 12:21, Brijesh Singh wrote:
>> The KVM side is a pretty linear use of the kernel API. I'm not very
>> happy with the debug API for MemoryRegions (but it's not really
>> Brijesh's fault), so my plan would be to merge it without debug support.
>
> Thanks Paolo, I am working to drop the complete debug support and will
> send series very soon. I need to run some quick smoke test to make sure
> I don't break SEV guest support.
Just test the pull request I'll send in less than an hour. :)
Paolo
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v12 24/28] sev/i386: add migration blocker
2018-03-13 11:28 ` [Qemu-devel] " Brijesh Singh
@ 2018-03-13 11:36 ` Paolo Bonzini
-1 siblings, 0 replies; 114+ messages in thread
From: Paolo Bonzini @ 2018-03-13 11:36 UTC (permalink / raw)
To: Brijesh Singh, qemu-devel
Cc: Edgar E. Iglesias, Peter Maydell, Cornelia Huck, Eduardo Habkost,
kvm, Michael S. Tsirkin, Stefan Hajnoczi, Peter Crosthwaite,
Richard Henderson, Alexander Graf, Alistair Francis,
Christian Borntraeger, Dr. David Alan Gilbert, Marcel Apfelbaum,
Thomas Lendacky, Borislav Petkov, Bruce Rogers,
Markus Armbruster
On 13/03/2018 12:28, Brijesh Singh wrote:
>
>
> On 3/13/18 4:33 AM, Paolo Bonzini wrote:
>> On 08/03/2018 13:48, Brijesh Singh wrote:
>>> sev_set_guest_state(SEV_STATE_RUNNING);
>>> +
>>> + /* add migration blocker */
>>> + error_setg(&sev_mig_blocker,
>>> + "SEV: Migration is not implemented");
>>> + ret = migrate_add_blocker(sev_mig_blocker, &local_err);
>>> + if (local_err) {
>>> + error_report_err(local_err);
>>> + error_free(sev_mig_blocker);
>>> + exit(1);
>>> + }
>>> }
>> I think this should be in sev_guest_init instead? Does migration
>> transfer the measurement, or is it lost forever? Not a blocker though.
>
> The launch measurement does not get transferred during the migration.
> During migration we get totally different measurement which is wrapped
> with transport key etc and that need to send to destination. IIRC, in my
> first attempt I was adding this blocker in sev_guest_init() but
> migration_add_blocker() was failing because sev_guest_init() is called
> before the migration_object_init().
I see, thanks. I'm not going to touch this part anyway. :)
We can fix it during the freeze period.
Paolo
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [Qemu-devel] [PATCH v12 24/28] sev/i386: add migration blocker
@ 2018-03-13 11:36 ` Paolo Bonzini
0 siblings, 0 replies; 114+ messages in thread
From: Paolo Bonzini @ 2018-03-13 11:36 UTC (permalink / raw)
To: Brijesh Singh, qemu-devel
Cc: Edgar E. Iglesias, Peter Maydell, Borislav Petkov,
Eduardo Habkost, kvm, Michael S. Tsirkin, Stefan Hajnoczi,
Alistair Francis, Peter Crosthwaite, Richard Henderson,
Alexander Graf, Markus Armbruster, Christian Borntraeger,
Marcel Apfelbaum, Thomas Lendacky, Bruce Rogers, Cornelia Huck,
Dr. David Alan Gilbert
On 13/03/2018 12:28, Brijesh Singh wrote:
>
>
> On 3/13/18 4:33 AM, Paolo Bonzini wrote:
>> On 08/03/2018 13:48, Brijesh Singh wrote:
>>> sev_set_guest_state(SEV_STATE_RUNNING);
>>> +
>>> + /* add migration blocker */
>>> + error_setg(&sev_mig_blocker,
>>> + "SEV: Migration is not implemented");
>>> + ret = migrate_add_blocker(sev_mig_blocker, &local_err);
>>> + if (local_err) {
>>> + error_report_err(local_err);
>>> + error_free(sev_mig_blocker);
>>> + exit(1);
>>> + }
>>> }
>> I think this should be in sev_guest_init instead? Does migration
>> transfer the measurement, or is it lost forever? Not a blocker though.
>
> The launch measurement does not get transferred during the migration.
> During migration we get totally different measurement which is wrapped
> with transport key etc and that need to send to destination. IIRC, in my
> first attempt I was adding this blocker in sev_guest_init() but
> migration_add_blocker() was failing because sev_guest_init() is called
> before the migration_object_init().
I see, thanks. I'm not going to touch this part anyway. :)
We can fix it during the freeze period.
Paolo
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v12 08/28] target/i386: add Secure Encrypted Virtulization (SEV) object
2018-03-13 8:42 ` [Qemu-devel] " Paolo Bonzini
@ 2018-03-13 18:49 ` Eduardo Habkost
-1 siblings, 0 replies; 114+ messages in thread
From: Eduardo Habkost @ 2018-03-13 18:49 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Edgar E. Iglesias, Peter Maydell, Borislav Petkov, Brijesh Singh,
kvm, Michael S. Tsirkin, Stefan Hajnoczi, Alistair Francis,
Peter Crosthwaite, Richard Henderson, qemu-devel, Alexander Graf,
Christian Borntraeger, Dr. David Alan Gilbert, Marcel Apfelbaum,
Thomas Lendacky, Bruce Rogers, Cornelia Huck, Markus Armbruster,
Richard Henderson
On Tue, Mar 13, 2018 at 09:42:51AM +0100, Paolo Bonzini wrote:
> On 08/03/2018 23:44, Eduardo Habkost wrote:
> >> I think doing so will be an issue for the migration. Consider your above
> >> use case, a SEV guest is running on EPYC with cbitpos=47 and if we
> >> migrate to some $NEXT AMD CPU which uses need to use cbitpos=48 and we
> >> will fail to resume the guest on destination after migrating.
> >
> > Exactly, in other words these two options are part of the guest
> > ABI, and QEMU promises to never make the guest ABI depend on the
> > host hardware unless you're using "-cpu host".
>
> This is not entirely true; while MAXPHYADDR is constant downstream
> unless using "-cpu host", in practice that behavior is wrong and a guest
> could misbehave if passed a MAXPHYADDR that is different from the host's.
>
> I think this is the same, and management software will have to live with it.
>
I think they are very far from being equivalent.
In practice guests don't seem to mind if we don't perfectly
emulate behavior that depend on MAXPHYADDR, and live-migration
between hosts with different MAXPHYADDR works.
But if you tell the guest the wrong C-bit location, guests are
likely to rely on it and break. Migration between hosts with
different C-bit locations won't work, will it?
--
Eduardo
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [Qemu-devel] [PATCH v12 08/28] target/i386: add Secure Encrypted Virtulization (SEV) object
@ 2018-03-13 18:49 ` Eduardo Habkost
0 siblings, 0 replies; 114+ messages in thread
From: Eduardo Habkost @ 2018-03-13 18:49 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Brijesh Singh, Peter Maydell, kvm, Michael S. Tsirkin,
Stefan Hajnoczi, qemu-devel, Alexander Graf, Edgar E. Iglesias,
Markus Armbruster, Bruce Rogers, Christian Borntraeger,
Marcel Apfelbaum, Borislav Petkov, Thomas Lendacky,
Richard Henderson, Dr. David Alan Gilbert, Alistair Francis,
Cornelia Huck, Richard Henderson, Peter Crosthwaite
On Tue, Mar 13, 2018 at 09:42:51AM +0100, Paolo Bonzini wrote:
> On 08/03/2018 23:44, Eduardo Habkost wrote:
> >> I think doing so will be an issue for the migration. Consider your above
> >> use case, a SEV guest is running on EPYC with cbitpos=47 and if we
> >> migrate to some $NEXT AMD CPU which uses need to use cbitpos=48 and we
> >> will fail to resume the guest on destination after migrating.
> >
> > Exactly, in other words these two options are part of the guest
> > ABI, and QEMU promises to never make the guest ABI depend on the
> > host hardware unless you're using "-cpu host".
>
> This is not entirely true; while MAXPHYADDR is constant downstream
> unless using "-cpu host", in practice that behavior is wrong and a guest
> could misbehave if passed a MAXPHYADDR that is different from the host's.
>
> I think this is the same, and management software will have to live with it.
>
I think they are very far from being equivalent.
In practice guests don't seem to mind if we don't perfectly
emulate behavior that depend on MAXPHYADDR, and live-migration
between hosts with different MAXPHYADDR works.
But if you tell the guest the wrong C-bit location, guests are
likely to rely on it and break. Migration between hosts with
different C-bit locations won't work, will it?
--
Eduardo
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v12 08/28] target/i386: add Secure Encrypted Virtulization (SEV) object
2018-03-13 18:49 ` [Qemu-devel] " Eduardo Habkost
@ 2018-03-13 19:04 ` Paolo Bonzini
-1 siblings, 0 replies; 114+ messages in thread
From: Paolo Bonzini @ 2018-03-13 19:04 UTC (permalink / raw)
To: Eduardo Habkost
Cc: Edgar E. Iglesias, Peter Maydell, Borislav Petkov, Brijesh Singh,
kvm, Michael S. Tsirkin, Stefan Hajnoczi, Alistair Francis,
Peter Crosthwaite, Richard Henderson, qemu-devel, Alexander Graf,
Christian Borntraeger, Dr. David Alan Gilbert, Marcel Apfelbaum,
Thomas Lendacky, Bruce Rogers, Cornelia Huck, Markus Armbruster,
Richard Henderson
On 13/03/2018 19:49, Eduardo Habkost wrote:
>>>
>>> Exactly, in other words these two options are part of the guest
>>> ABI, and QEMU promises to never make the guest ABI depend on the
>>> host hardware unless you're using "-cpu host".
>>
>> This is not entirely true; while MAXPHYADDR is constant downstream
>> unless using "-cpu host", in practice that behavior is wrong and a guest
>> could misbehave if passed a MAXPHYADDR that is different from the host's.
>>
>> I think this is the same, and management software will have to live with it.
>
> I think they are very far from being equivalent.
Right, I only meant to say that guest ABI actually does depend on the
host hardware, even outside of "-cpu host".
> But if you tell the guest the wrong C-bit location, guests are
> likely to rely on it and break. Migration between hosts with
> different C-bit locations won't work, will it?
It won't---but as long as the destination hosts fails fast when the
C-bit location is wrong, it's okay. What matters is that we don't run
guest code with the wrong C bit, as you noted.
Paolo
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [Qemu-devel] [PATCH v12 08/28] target/i386: add Secure Encrypted Virtulization (SEV) object
@ 2018-03-13 19:04 ` Paolo Bonzini
0 siblings, 0 replies; 114+ messages in thread
From: Paolo Bonzini @ 2018-03-13 19:04 UTC (permalink / raw)
To: Eduardo Habkost
Cc: Brijesh Singh, Peter Maydell, kvm, Michael S. Tsirkin,
Stefan Hajnoczi, qemu-devel, Alexander Graf, Edgar E. Iglesias,
Markus Armbruster, Bruce Rogers, Christian Borntraeger,
Marcel Apfelbaum, Borislav Petkov, Thomas Lendacky,
Richard Henderson, Dr. David Alan Gilbert, Alistair Francis,
Cornelia Huck, Richard Henderson, Peter Crosthwaite
On 13/03/2018 19:49, Eduardo Habkost wrote:
>>>
>>> Exactly, in other words these two options are part of the guest
>>> ABI, and QEMU promises to never make the guest ABI depend on the
>>> host hardware unless you're using "-cpu host".
>>
>> This is not entirely true; while MAXPHYADDR is constant downstream
>> unless using "-cpu host", in practice that behavior is wrong and a guest
>> could misbehave if passed a MAXPHYADDR that is different from the host's.
>>
>> I think this is the same, and management software will have to live with it.
>
> I think they are very far from being equivalent.
Right, I only meant to say that guest ABI actually does depend on the
host hardware, even outside of "-cpu host".
> But if you tell the guest the wrong C-bit location, guests are
> likely to rely on it and break. Migration between hosts with
> different C-bit locations won't work, will it?
It won't---but as long as the destination hosts fails fast when the
C-bit location is wrong, it's okay. What matters is that we don't run
guest code with the wrong C bit, as you noted.
Paolo
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v12 08/28] target/i386: add Secure Encrypted Virtulization (SEV) object
2018-03-13 19:04 ` [Qemu-devel] " Paolo Bonzini
@ 2018-03-13 19:20 ` Eduardo Habkost
-1 siblings, 0 replies; 114+ messages in thread
From: Eduardo Habkost @ 2018-03-13 19:20 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Edgar E. Iglesias, Peter Maydell, Borislav Petkov, Brijesh Singh,
kvm, Michael S. Tsirkin, Stefan Hajnoczi, Alistair Francis,
Peter Crosthwaite, Richard Henderson, qemu-devel, Alexander Graf,
Christian Borntraeger, Dr. David Alan Gilbert, Marcel Apfelbaum,
Thomas Lendacky, Bruce Rogers, Cornelia Huck, Markus Armbruster,
Richard Henderson
On Tue, Mar 13, 2018 at 08:04:51PM +0100, Paolo Bonzini wrote:
> On 13/03/2018 19:49, Eduardo Habkost wrote:
> >>>
> >>> Exactly, in other words these two options are part of the guest
> >>> ABI, and QEMU promises to never make the guest ABI depend on the
> >>> host hardware unless you're using "-cpu host".
> >>
> >> This is not entirely true; while MAXPHYADDR is constant downstream
> >> unless using "-cpu host", in practice that behavior is wrong and a guest
> >> could misbehave if passed a MAXPHYADDR that is different from the host's.
> >>
> >> I think this is the same, and management software will have to live with it.
> >
> > I think they are very far from being equivalent.
>
> Right, I only meant to say that guest ABI actually does depend on the
> host hardware, even outside of "-cpu host".
>
> > But if you tell the guest the wrong C-bit location, guests are
> > likely to rely on it and break. Migration between hosts with
> > different C-bit locations won't work, will it?
>
> It won't---but as long as the destination hosts fails fast when the
> C-bit location is wrong, it's okay. What matters is that we don't run
> guest code with the wrong C bit, as you noted.
Are you proposing we change the default to simply use cbitpos
from the host?
I would agree with this only if we make QEMU able to prevent live
migration to a host with mismatching cbitpos.
--
Eduardo
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [Qemu-devel] [PATCH v12 08/28] target/i386: add Secure Encrypted Virtulization (SEV) object
@ 2018-03-13 19:20 ` Eduardo Habkost
0 siblings, 0 replies; 114+ messages in thread
From: Eduardo Habkost @ 2018-03-13 19:20 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Brijesh Singh, Peter Maydell, kvm, Michael S. Tsirkin,
Stefan Hajnoczi, qemu-devel, Alexander Graf, Edgar E. Iglesias,
Markus Armbruster, Bruce Rogers, Christian Borntraeger,
Marcel Apfelbaum, Borislav Petkov, Thomas Lendacky,
Richard Henderson, Dr. David Alan Gilbert, Alistair Francis,
Cornelia Huck, Richard Henderson, Peter Crosthwaite
On Tue, Mar 13, 2018 at 08:04:51PM +0100, Paolo Bonzini wrote:
> On 13/03/2018 19:49, Eduardo Habkost wrote:
> >>>
> >>> Exactly, in other words these two options are part of the guest
> >>> ABI, and QEMU promises to never make the guest ABI depend on the
> >>> host hardware unless you're using "-cpu host".
> >>
> >> This is not entirely true; while MAXPHYADDR is constant downstream
> >> unless using "-cpu host", in practice that behavior is wrong and a guest
> >> could misbehave if passed a MAXPHYADDR that is different from the host's.
> >>
> >> I think this is the same, and management software will have to live with it.
> >
> > I think they are very far from being equivalent.
>
> Right, I only meant to say that guest ABI actually does depend on the
> host hardware, even outside of "-cpu host".
>
> > But if you tell the guest the wrong C-bit location, guests are
> > likely to rely on it and break. Migration between hosts with
> > different C-bit locations won't work, will it?
>
> It won't---but as long as the destination hosts fails fast when the
> C-bit location is wrong, it's okay. What matters is that we don't run
> guest code with the wrong C bit, as you noted.
Are you proposing we change the default to simply use cbitpos
from the host?
I would agree with this only if we make QEMU able to prevent live
migration to a host with mismatching cbitpos.
--
Eduardo
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v12 08/28] target/i386: add Secure Encrypted Virtulization (SEV) object
2018-03-13 19:20 ` [Qemu-devel] " Eduardo Habkost
@ 2018-03-13 19:49 ` Dr. David Alan Gilbert
-1 siblings, 0 replies; 114+ messages in thread
From: Dr. David Alan Gilbert @ 2018-03-13 19:49 UTC (permalink / raw)
To: Eduardo Habkost
Cc: Edgar E. Iglesias, Peter Maydell, Borislav Petkov, Brijesh Singh,
kvm, Michael S. Tsirkin, Stefan Hajnoczi, Alistair Francis,
Peter Crosthwaite, Richard Henderson, qemu-devel, Alexander Graf,
Christian Borntraeger, Marcel Apfelbaum, Paolo Bonzini,
Thomas Lendacky, Bruce Rogers, Cornelia Huck, Markus Armbruster,
Richard Henderson
* Eduardo Habkost (ehabkost@redhat.com) wrote:
> On Tue, Mar 13, 2018 at 08:04:51PM +0100, Paolo Bonzini wrote:
> > On 13/03/2018 19:49, Eduardo Habkost wrote:
> > >>>
> > >>> Exactly, in other words these two options are part of the guest
> > >>> ABI, and QEMU promises to never make the guest ABI depend on the
> > >>> host hardware unless you're using "-cpu host".
> > >>
> > >> This is not entirely true; while MAXPHYADDR is constant downstream
> > >> unless using "-cpu host", in practice that behavior is wrong and a guest
> > >> could misbehave if passed a MAXPHYADDR that is different from the host's.
> > >>
> > >> I think this is the same, and management software will have to live with it.
> > >
> > > I think they are very far from being equivalent.
> >
> > Right, I only meant to say that guest ABI actually does depend on the
> > host hardware, even outside of "-cpu host".
> >
> > > But if you tell the guest the wrong C-bit location, guests are
> > > likely to rely on it and break. Migration between hosts with
> > > different C-bit locations won't work, will it?
> >
> > It won't---but as long as the destination hosts fails fast when the
> > C-bit location is wrong, it's okay. What matters is that we don't run
> > guest code with the wrong C bit, as you noted.
>
> Are you proposing we change the default to simply use cbitpos
> from the host?
Hmm I don't like that idea; as an option that's fine, as the only
way it's not.
> I would agree with this only if we make QEMU able to prevent live
> migration to a host with mismatching cbitpos.
Yeh; especially since I suspect debugging stuff with a failed SEV
migration like that is going to be really hard.
Dave
> --
> Eduardo
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [Qemu-devel] [PATCH v12 08/28] target/i386: add Secure Encrypted Virtulization (SEV) object
@ 2018-03-13 19:49 ` Dr. David Alan Gilbert
0 siblings, 0 replies; 114+ messages in thread
From: Dr. David Alan Gilbert @ 2018-03-13 19:49 UTC (permalink / raw)
To: Eduardo Habkost
Cc: Paolo Bonzini, Brijesh Singh, Peter Maydell, kvm,
Michael S. Tsirkin, Stefan Hajnoczi, qemu-devel, Alexander Graf,
Edgar E. Iglesias, Markus Armbruster, Bruce Rogers,
Christian Borntraeger, Marcel Apfelbaum, Borislav Petkov,
Thomas Lendacky, Richard Henderson, Alistair Francis,
Cornelia Huck, Richard Henderson, Peter Crosthwaite
* Eduardo Habkost (ehabkost@redhat.com) wrote:
> On Tue, Mar 13, 2018 at 08:04:51PM +0100, Paolo Bonzini wrote:
> > On 13/03/2018 19:49, Eduardo Habkost wrote:
> > >>>
> > >>> Exactly, in other words these two options are part of the guest
> > >>> ABI, and QEMU promises to never make the guest ABI depend on the
> > >>> host hardware unless you're using "-cpu host".
> > >>
> > >> This is not entirely true; while MAXPHYADDR is constant downstream
> > >> unless using "-cpu host", in practice that behavior is wrong and a guest
> > >> could misbehave if passed a MAXPHYADDR that is different from the host's.
> > >>
> > >> I think this is the same, and management software will have to live with it.
> > >
> > > I think they are very far from being equivalent.
> >
> > Right, I only meant to say that guest ABI actually does depend on the
> > host hardware, even outside of "-cpu host".
> >
> > > But if you tell the guest the wrong C-bit location, guests are
> > > likely to rely on it and break. Migration between hosts with
> > > different C-bit locations won't work, will it?
> >
> > It won't---but as long as the destination hosts fails fast when the
> > C-bit location is wrong, it's okay. What matters is that we don't run
> > guest code with the wrong C bit, as you noted.
>
> Are you proposing we change the default to simply use cbitpos
> from the host?
Hmm I don't like that idea; as an option that's fine, as the only
way it's not.
> I would agree with this only if we make QEMU able to prevent live
> migration to a host with mismatching cbitpos.
Yeh; especially since I suspect debugging stuff with a failed SEV
migration like that is going to be really hard.
Dave
> --
> Eduardo
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
^ permalink raw reply [flat|nested] 114+ messages in thread
end of thread, other threads:[~2018-03-13 19:50 UTC | newest]
Thread overview: 114+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-03-08 12:48 [PATCH v12 00/28] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
2018-03-08 12:48 ` [PATCH v12 01/28] memattrs: add debug attribute Brijesh Singh
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
2018-03-08 12:48 ` [PATCH v12 02/28] exec: add ram_debug_ops support Brijesh Singh
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
2018-03-08 12:48 ` [PATCH v12 03/28] exec: add debug version of physical memory read and write API Brijesh Singh
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
2018-03-08 12:48 ` [PATCH v12 04/28] monitor/i386: use debug APIs when accessing guest memory Brijesh Singh
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
2018-03-08 12:48 ` [PATCH v12 05/28] machine: add -memory-encryption property Brijesh Singh
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
2018-03-08 16:43 ` Daniel P. Berrangé
2018-03-08 16:43 ` [Qemu-devel] " Daniel P. Berrangé
2018-03-08 12:48 ` [PATCH v12 06/28] kvm: update kvm.h to include memory encryption ioctls Brijesh Singh
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
2018-03-08 12:48 ` [PATCH v12 07/28] docs: add AMD Secure Encrypted Virtualization (SEV) Brijesh Singh
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
2018-03-08 12:48 ` [PATCH v12 08/28] target/i386: add Secure Encrypted Virtulization (SEV) object Brijesh Singh
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
2018-03-08 16:49 ` Daniel P. Berrangé
2018-03-08 16:49 ` [Qemu-devel] " Daniel P. Berrangé
2018-03-08 22:22 ` Brijesh Singh
2018-03-08 22:22 ` [Qemu-devel] " Brijesh Singh
2018-03-08 22:44 ` Eduardo Habkost
2018-03-08 22:44 ` [Qemu-devel] " Eduardo Habkost
2018-03-13 8:42 ` Paolo Bonzini
2018-03-13 8:42 ` [Qemu-devel] " Paolo Bonzini
2018-03-13 18:49 ` Eduardo Habkost
2018-03-13 18:49 ` [Qemu-devel] " Eduardo Habkost
2018-03-13 19:04 ` Paolo Bonzini
2018-03-13 19:04 ` [Qemu-devel] " Paolo Bonzini
2018-03-13 19:20 ` Eduardo Habkost
2018-03-13 19:20 ` [Qemu-devel] " Eduardo Habkost
2018-03-13 19:49 ` Dr. David Alan Gilbert
2018-03-13 19:49 ` [Qemu-devel] " Dr. David Alan Gilbert
2018-03-08 12:48 ` [PATCH v12 09/28] qmp: add query-sev command Brijesh Singh
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
2018-03-08 16:52 ` Daniel P. Berrangé
2018-03-08 16:52 ` [Qemu-devel] " Daniel P. Berrangé
2018-03-08 12:48 ` [PATCH v12 10/28] include: add psp-sev.h header file Brijesh Singh
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
2018-03-08 16:54 ` Daniel P. Berrangé
2018-03-08 16:54 ` [Qemu-devel] " Daniel P. Berrangé
2018-03-09 12:24 ` Dr. David Alan Gilbert
2018-03-09 12:24 ` [Qemu-devel] " Dr. David Alan Gilbert
2018-03-12 10:32 ` Daniel P. Berrangé
2018-03-12 10:32 ` [Qemu-devel] " Daniel P. Berrangé
2018-03-08 12:48 ` [PATCH v12 11/28] sev/i386: add command to initialize the memory encryption context Brijesh Singh
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
2018-03-08 16:57 ` Daniel P. Berrangé
2018-03-08 16:57 ` [Qemu-devel] " Daniel P. Berrangé
2018-03-08 12:48 ` [PATCH v12 12/28] sev/i386: register the guest memory range which may contain encrypted data Brijesh Singh
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
2018-03-08 12:48 ` [PATCH v12 13/28] kvm: introduce memory encryption APIs Brijesh Singh
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
2018-03-08 12:48 ` [PATCH v12 14/28] hmp: add 'info sev' command Brijesh Singh
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
2018-03-08 12:48 ` [PATCH v12 15/28] sev/i386: add command to create launch memory encryption context Brijesh Singh
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
2018-03-08 12:48 ` [PATCH v12 16/28] sev/i386: add command to encrypt guest memory region Brijesh Singh
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
2018-03-08 12:48 ` [PATCH v12 17/28] target/i386: encrypt bios rom Brijesh Singh
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
2018-03-08 12:48 ` [PATCH v12 18/28] sev/i386: add support to LAUNCH_MEASURE command Brijesh Singh
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
2018-03-08 12:48 ` [PATCH v12 19/28] sev/i386: finalize the SEV guest launch flow Brijesh Singh
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
2018-03-08 12:48 ` [PATCH v12 20/28] hw/i386: set ram_debug_ops when memory encryption is enabled Brijesh Singh
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
2018-03-08 12:48 ` [PATCH v12 21/28] sev/i386: add debug encrypt and decrypt commands Brijesh Singh
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
2018-03-08 12:48 ` [PATCH v12 22/28] target/i386: clear C-bit when walking SEV guest page table Brijesh Singh
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
2018-03-08 12:48 ` [PATCH v12 23/28] qmp: add query-sev-launch-measure command Brijesh Singh
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
2018-03-08 17:03 ` Daniel P. Berrangé
2018-03-08 17:03 ` [Qemu-devel] " Daniel P. Berrangé
2018-03-08 12:48 ` [PATCH v12 24/28] sev/i386: add migration blocker Brijesh Singh
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
2018-03-13 9:33 ` Paolo Bonzini
2018-03-13 9:33 ` [Qemu-devel] " Paolo Bonzini
2018-03-13 11:28 ` Brijesh Singh
2018-03-13 11:28 ` [Qemu-devel] " Brijesh Singh
2018-03-13 11:36 ` Paolo Bonzini
2018-03-13 11:36 ` [Qemu-devel] " Paolo Bonzini
2018-03-08 12:48 ` [PATCH v12 25/28] cpu/i386: populate CPUID 0x8000_001F when SEV is active Brijesh Singh
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
2018-03-08 12:48 ` [PATCH v12 26/28] qmp: add query-sev-capabilities command Brijesh Singh
2018-03-08 12:48 ` [Qemu-devel] " Brijesh Singh
2018-03-08 17:05 ` Daniel P. Berrangé
2018-03-08 17:05 ` [Qemu-devel] " Daniel P. Berrangé
2018-03-08 22:52 ` Brijesh Singh
2018-03-08 22:52 ` [Qemu-devel] " Brijesh Singh
2018-03-08 12:49 ` [PATCH v12 27/28] sev/i386: add sev_get_capabilities() Brijesh Singh
2018-03-08 12:49 ` [Qemu-devel] " Brijesh Singh
2018-03-08 12:49 ` [PATCH v12 28/28] tests/qmp-test: blacklist sev specific qmp commands Brijesh Singh
2018-03-08 12:49 ` [Qemu-devel] " Brijesh Singh
2018-03-08 17:08 ` Daniel P. Berrangé
2018-03-08 17:08 ` [Qemu-devel] " Daniel P. Berrangé
2018-03-08 20:18 ` Brijesh Singh
2018-03-08 20:18 ` [Qemu-devel] " Brijesh Singh
2018-03-08 21:45 ` Eduardo Habkost
2018-03-08 21:45 ` [Qemu-devel] " Eduardo Habkost
2018-03-08 23:22 ` Daniel P. Berrange
2018-03-08 23:22 ` [Qemu-devel] " Daniel P. Berrange
2018-03-09 10:12 ` Dr. David Alan Gilbert
2018-03-09 10:12 ` [Qemu-devel] " Dr. David Alan Gilbert
2018-03-13 9:07 ` Paolo Bonzini
2018-03-13 9:07 ` [Qemu-devel] " Paolo Bonzini
2018-03-13 11:21 ` Brijesh Singh
2018-03-13 11:21 ` [Qemu-devel] " Brijesh Singh
2018-03-13 11:36 ` Paolo Bonzini
2018-03-13 11:36 ` [Qemu-devel] " Paolo Bonzini
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.