On 1/31/22 9:26 AM, Daniel P. Berrangé wrote:
>
> Ok, so the usage scenario is that the platform owner is deciding
> which OVMF build in use, not the guest owner. That guest owner just
> knows that it is an OVMF build from a set of builds published by the
> platform owner. Good enough if you
On Mon, Aug 16, 2021 at 04:15:46PM +0200, Paolo Bonzini wrote:
> Hi,
>
> first of all, thanks for posting this work and starting the discussion.
>
> However, I am not sure if the in-guest migration helper vCPUs should use
> the existing KVM support code. For example, they probably can just
>
On 8/23/21 8:26 AM, Dr. David Alan Gilbert wrote:
* James Bottomley (j...@linux.ibm.com) wrote:
(is there an attest of the destination happening here?)
There will be in the final version. The attestations of the source and
target, being the hash of the OVMF (with the registers in the -ES
On 8/19/21 4:22 AM, Dr. David Alan Gilbert wrote:
* Tobin Feldman-Fitzthum (to...@linux.ibm.com) wrote:
On 8/18/21 3:04 PM, Dr. David Alan Gilbert wrote:
Are you relying on the target firmware to be *identical* or purely for
it to be *compatible* ? It's normal for a migration
On 8/18/21 3:04 PM, Dr. David Alan Gilbert wrote:
* Tobin Feldman-Fitzthum (to...@linux.ibm.com) wrote:
On 8/17/21 6:04 PM, Steve Rutherford wrote:
Ahh, It sounds like you are looking into sidestepping the existing
AMD-SP flows for migration. I assume the idea is to spin up a VM on
the target
On 8/17/21 6:04 PM, Steve Rutherford wrote:
On Tue, Aug 17, 2021 at 1:50 PM Tobin Feldman-Fitzthum
wrote:
This is essentially what we do in our prototype, although we have an
even simpler approach. We have a 1:1 mapping that maps an address to
itself with the cbit set. During Migration QEMU
On 8/17/21 12:32 PM, Paolo Bonzini wrote:
On 17/08/21 01:53, Steve Rutherford wrote:
Separately, I'm a little weary of leaving the migration helper mapped
into the shared address space as writable.
A related question here is what the API should be for how the
migration helper sees the
On Mon, Aug 16 at 10:44 AM Ashish Kalra wrote:
> I am not sure if we really don't need QEMU's MMIO logic, I think that
once the>
> mirror VM starts booting and running the UEFI code, it might be only
during
> the PEI or DXE phase where it will start actually running the MH code,
> so mirror
On 2020-10-30 16:02, Dr. David Alan Gilbert wrote:
* Tobin Feldman-Fitzthum (to...@linux.ibm.com) wrote:
Hello,
Dov Murik, James Bottomley, Hubertus Franke, and I have been working
on a
plan for fast live migration with SEV and SEV-ES. We just posted an
RFC
about it to the edk2 list
Hello,
Dov Murik, James Bottomley, Hubertus Franke, and I have been working on
a plan for fast live migration with SEV and SEV-ES. We just posted an
RFC about it to the edk2 list. It includes a proof-of-concept for what
we feel to be the most difficult part of fast live migration with SEV-ES.
On 2020-10-27 09:35, Eduardo Habkost wrote:
On Thu, Oct 22, 2020 at 01:39:09AM -0400, to...@linux.ibm.com wrote:
From: Tobin Feldman-Fitzthum
AMD SEV allows a guest owner to inject a secret blob
into the memory of a virtual machine. The secret is
encrypted with the SEV Transport Encryption
On 2020-10-22 00:16, to...@linux.ibm.com wrote:
From: Tobin Feldman-Fitzthum
AMD SEV allows a guest owner to inject a secret blob
into the memory of a virtual machine. The secret is
encrypted with the SEV Transport Encryption Key and
integrity is guaranteed with the Transport Integrity
Key
On 2020-10-20 11:56, Paolo Bonzini wrote:
On 20/10/20 15:54, Eduardo Habkost wrote:
On Tue, Oct 20, 2020 at 11:03:51AM +0200, Paolo Bonzini wrote:
On 15/10/20 16:37, to...@linux.ibm.com wrote:
-static void *gpa2hva(MemoryRegion **p_mr, hwaddr addr, Error
**errp)
+void *gpa2hva(MemoryRegion
On 2020-10-19 12:47, Eduardo Habkost wrote:
On Mon, Oct 19, 2020 at 12:46:08PM -0400, Eduardo Habkost wrote:
On Thu, Oct 15, 2020 at 10:37:13AM -0400, to...@linux.ibm.com wrote:
[...]
> diff --git a/target/i386/sev-stub.c b/target/i386/sev-stub.c
> index 88e3f39a1e..2d2ee54cc6 100644
> ---
On 2020-10-14 11:42, Brijesh Singh wrote:
On 10/14/20 10:17 AM, to...@linux.ibm.com wrote:
From: Tobin Feldman-Fitzthum
AMD SEV allows a guest owner to inject a secret blob
into the memory of a virtual machine. The secret is
encrypted with the SEV Transport Encryption Key and
integrity
On 2020-09-21 15:16, Dr. David Alan Gilbert wrote:
* Tobin Feldman-Fitzthum (to...@linux.vnet.ibm.com) wrote:
AMD SEV allows a guest owner to inject a secret blob
into the memory of a virtual machine. The secret is
encrypted with the SEV Transport Encryption Key and
integrity is guaranteed
the secret.
Signed-off-by: Tobin Feldman-Fitzthum
---
include/monitor/monitor.h | 3 ++
include/sysemu/sev.h | 2 ++
monitor/misc.c| 8 ++---
qapi/misc-target.json | 18 +++
target/i386/monitor.c | 9 ++
target/i386/sev-stub.c| 5 +++
target/i386/sev.c
From: Tobin Feldman-Fitzthum
AMD SEV allows a guest owner to inject a secret blob
into the memory of a virtual machine. The secret is
encrypted with the SEV Transport Encryption Key and
integrity is guaranteed with the Transport Integrity
Key. Although QEMU faciliates the injection of the
launch
From: Tobin Feldman-Fitzthum
AMD SEV allows a guest owner to inject a secret blob
into the memory of a virtual machine. The secret is
encrypted with the SEV Transport Encryption Key and
integrity is guaranteed with the Transport Integrity
Key. Although QEMU faciliates the injection of the
launch
requires the user to provide the guest
physical address where the secret will be injected via QMP.
Tobin Feldman-Fitzthum (1):
sev: add sev-inject-launch-secret
include/monitor/monitor.h | 3 ++
include/sysemu/sev.h | 2 ++
monitor/misc.c| 8 ++---
qapi/misc-target.json
This patchset contains two patches. The first enables QEMU
to facilitate the injection of a secret blob into the guest
memory.
The second enables QEMU to parse the guest ROM to determine
the address at which the secret should be injected.
Tobin Feldman-Fitzthum (2):
sev: add sev-inject-launch
From: Tobin Feldman-Fitzthum
AMD SEV allows a guest owner to inject a secret blob
into the memory of a virtual machine. The secret is
encrypted with the SEV Transport Encryption Key and
integrity is guaranteed with the Transport Integrity
Key. Although QEMU faciliates the injection of the
launch
From: Tobin Feldman-Fitzthum
In addition to using QMP to provide the guest memory address
that the launch secret blob will be injected into, the
secret address can also be specified in the guest ROM. This
patch adds sev_find_secret_gpa, which scans the ROM page by
page to find a launch secret
23 matches
Mail list logo
