On Tue, Aug 24, 2021 at 06:00:51PM -0400, Tobin Feldman-Fitzthum wrote:
> 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 s
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
> alwa
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
case
* James Bottomley (j...@linux.ibm.com) wrote:
> On Thu, 2021-08-19 at 15:28 +0100, Dr. David Alan Gilbert wrote:
> > * James Bottomley (j...@linux.ibm.com) wrote:
> > > On Thu, 2021-08-19 at 09:22 +0100, Dr. David Alan Gilbert wrote:
> [...]
> > > > I think it really does have to cope with migratio
On Thu, 2021-08-19 at 15:28 +0100, Dr. David Alan Gilbert wrote:
> * James Bottomley (j...@linux.ibm.com) wrote:
> > On Thu, 2021-08-19 at 09:22 +0100, Dr. David Alan Gilbert wrote:
[...]
> > > I think it really does have to cope with migration to a new
> > > version of host.
> >
> > Well, you're
* James Bottomley (j...@linux.ibm.com) wrote:
> On Thu, 2021-08-19 at 09:22 +0100, 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:
> > > > * Tobin Feldman-Fitzthum (to...@linux.ibm.com) wrote:
> > > > >
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 to be the result
On Thu, 2021-08-19 at 09:22 +0100, 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:
> > > * Tobin Feldman-Fitzthum (to...@linux.ibm.com) wrote:
> > > > On 8/17/21 6:04 PM, Steve Rutherford wrote:
> > > > > Ah
* Tobin Feldman-Fitzthum (to...@linux.ibm.com) wrote:
> 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
> > > > AM
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 s
Il mer 18 ago 2021, 12:31 Ashish Kalra ha scritto:
> Hello Paolo,
>
> On Mon, Aug 16, 2021 at 05:38:55PM +0200, Paolo Bonzini wrote:
> > On 16/08/21 17:13, Ashish Kalra wrote:
> > > > > I think that once the mirror VM starts booting and running the UEFI
> > > > > code, it might be only during the
* Tobin Feldman-Fitzthum (to...@linux.ibm.com) wrote:
> 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 th
On Wed, 2021-08-18 at 18:30 +0100, Dr. David Alan Gilbert wrote:
> * James Bottomley (j...@linux.ibm.com) wrote:
> > On Wed, 2021-08-18 at 16:43 +0100, Dr. David Alan Gilbert wrote:
> > > * James Bottomley (j...@linux.ibm.com) wrote:
> > [...]
> > > > Given the lack of SMI, we can't guarantee that
* James Bottomley (j...@linux.ibm.com) wrote:
> On Wed, 2021-08-18 at 16:43 +0100, Dr. David Alan Gilbert wrote:
> > * James Bottomley (j...@linux.ibm.com) wrote:
> [...]
> > > Given the lack of SMI, we can't guarantee that with plain SEV and
> > > -ES. Once we move to -SNP, we can use VMPLs to ach
On Wed, Aug 18, 2021 at 02:06:25PM +, Ashish Kalra wrote:
> On Wed, Aug 18, 2021 at 12:37:32AM +0200, Paolo Bonzini wrote:
> > On Tue, Aug 17, 2021 at 11:54 PM Steve Rutherford
> > wrote:
> > > > 1) the easy one: the bottom 4G of guest memory are mapped in the mirror
> > > > VM 1:1. The ram_a
On Wed, 2021-08-18 at 16:43 +0100, Dr. David Alan Gilbert wrote:
> * James Bottomley (j...@linux.ibm.com) wrote:
[...]
> > Given the lack of SMI, we can't guarantee that with plain SEV and
> > -ES. Once we move to -SNP, we can use VMPLs to achieve this.
>
> Doesn't the MH have access to different
* James Bottomley (j...@linux.ibm.com) wrote:
> On Wed, 2021-08-18 at 16:31 +0100, Dr. David Alan Gilbert wrote:
> > * James Bottomley (j...@linux.ibm.com) wrote:
> > > On Wed, 2021-08-18 at 10:31 +, Ashish Kalra wrote:
> > > > Hello Paolo,
> > > >
> > > > On Mon, Aug 16, 2021 at 05:38:55PM +0
On Wed, 2021-08-18 at 16:31 +0100, Dr. David Alan Gilbert wrote:
> * James Bottomley (j...@linux.ibm.com) wrote:
> > On Wed, 2021-08-18 at 10:31 +, Ashish Kalra wrote:
> > > Hello Paolo,
> > >
> > > On Mon, Aug 16, 2021 at 05:38:55PM +0200, Paolo Bonzini wrote:
> > > > On 16/08/21 17:13, Ashis
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 ask
* James Bottomley (j...@linux.ibm.com) wrote:
> On Wed, 2021-08-18 at 10:31 +, Ashish Kalra wrote:
> > Hello Paolo,
> >
> > On Mon, Aug 16, 2021 at 05:38:55PM +0200, Paolo Bonzini wrote:
> > > On 16/08/21 17:13, Ashish Kalra wrote:
> > > > > > I think that once the mirror VM starts booting and
On Wed, Aug 18, 2021 at 12:37:32AM +0200, Paolo Bonzini wrote:
> On Tue, Aug 17, 2021 at 11:54 PM Steve Rutherford
> wrote:
> > > 1) the easy one: the bottom 4G of guest memory are mapped in the mirror
> > > VM 1:1. The ram_addr_t-based addresses are shifted by either 4G or a
> > > huge value suc
On Wed, 2021-08-18 at 10:31 +, Ashish Kalra wrote:
> Hello Paolo,
>
> On Mon, Aug 16, 2021 at 05:38:55PM +0200, Paolo Bonzini wrote:
> > On 16/08/21 17:13, Ashish Kalra wrote:
> > > > > I think that once the mirror VM starts booting and running
> > > > > the UEFI code, it might be only during
Hello Paolo,
On Mon, Aug 16, 2021 at 05:38:55PM +0200, Paolo Bonzini wrote:
> On 16/08/21 17:13, Ashish Kalra wrote:
> > > > 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 t
On Tue, 2021-08-17 at 16:10 -0700, Steve Rutherford wrote:
> On Tue, Aug 17, 2021 at 3:57 PM James Bottomley
> wrote:
> > Realistically, migration is becoming a royal pain, not just for
> > confidential computing, but for virtual functions in general. I
> > really think we should look at S3 suspe
On Tue, Aug 17, 2021 at 10:51 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 asks the migration
> handler to import/expo
On Tue, Aug 17, 2021 at 3:57 PM James Bottomley wrote:
> Realistically, migration is becoming a royal pain, not just for
> confidential computing, but for virtual functions in general. I really
> think we should look at S3 suspend, where we shut down the drivers and
> then reattach on S3 resume a
On Wed, 2021-08-18 at 00:37 +0200, Paolo Bonzini wrote:
> On Tue, Aug 17, 2021 at 11:54 PM Steve Rutherford
> wrote:
> > > 1) the easy one: the bottom 4G of guest memory are mapped in the
> > > mirror
> > > VM 1:1. The ram_addr_t-based addresses are shifted by either 4G
> > > or a
> > > huge valu
On Tue, Aug 17, 2021 at 11:54 PM Steve Rutherford
wrote:
> > 1) the easy one: the bottom 4G of guest memory are mapped in the mirror
> > VM 1:1. The ram_addr_t-based addresses are shifted by either 4G or a
> > huge value such as 2^42 (MAXPHYADDR - physical address reduction - 1).
> > This even le
On Tue, Aug 17, 2021 at 1:50 PM Tobin Feldman-Fitzthum
wrote:
>
>
> On 8/17/21 12:32 PM, Paolo Bonzini wrote:
> > There's three possibilities for this:
> >
> > 1) the easy one: the bottom 4G of guest memory are mapped in the
> > mirror VM 1:1. The ram_addr_t-based addresses are shifted by either
On Tue, Aug 17, 2021 at 9:32 AM 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
>
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 memor
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 memory in both physical and virtual address.
Fir
Hello Dave, Steve,
On Tue, Aug 17, 2021 at 09:38:24AM +0100, Dr. David Alan Gilbert wrote:
> * Steve Rutherford (srutherf...@google.com) wrote:
> > On Mon, Aug 16, 2021 at 6:37 AM Ashish Kalra wrote:
> > >
> > > From: Ashish Kalra
> > >
> > > This is an RFC series for Mirror VM support that are
* Steve Rutherford (srutherf...@google.com) wrote:
> On Mon, Aug 16, 2021 at 6:37 AM Ashish Kalra wrote:
> >
> > From: Ashish Kalra
> >
> > This is an RFC series for Mirror VM support that are
> > essentially secondary VMs sharing the encryption context
> > (ASID) with a primary VM. The patch-set
On Mon, Aug 16, 2021 at 04:53:17PM -0700, Steve Rutherford wrote:
> Separately, I'm a little weary of leaving the migration helper mapped
> into the shared address space as writable. Since the migration threads
> will be executing guest-owned code, the guest could use these threads
> to do whatever
On Mon, Aug 16, 2021 at 6:37 AM Ashish Kalra wrote:
>
> From: Ashish Kalra
>
> This is an RFC series for Mirror VM support that are
> essentially secondary VMs sharing the encryption context
> (ASID) with a primary VM. The patch-set creates a new
> VM and shares the primary VM's encryption contex
Il lun 16 ago 2021, 19:23 Dr. David Alan Gilbert ha
scritto:
> > 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 always
> work
> > with host CPUID (copied directly from KVM_GET_SUPPORTED_CPUID),
>
>
* Paolo Bonzini (pbonz...@redhat.com) wrote:
> On 16/08/21 15:25, Ashish Kalra wrote:
> > From: Ashish Kalra
> >
> > This is an RFC series for Mirror VM support that are
> > essentially secondary VMs sharing the encryption context
> > (ASID) with a primary VM. The patch-set creates a new
> > VM an
* Paolo Bonzini (pbonz...@redhat.com) wrote:
> On 16/08/21 17:13, Ashish Kalra wrote:
> > > > 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 VM probabl
On 16/08/21 17:13, Ashish Kalra wrote:
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 VM probably still need
to handles KVM_EXIT_IO when SEC phase does I/O, I can se
On 16/08/21 17:16, Daniel P. Berrangé wrote:
I woudn't be needed to create migration threads at startup - we should
just think about how we would identify and control them when created
at runtime. The complexity here is a trust issue - once guest code has
been run, we can't trust what QMP tells u
On Mon, Aug 16, 2021 at 05:00:21PM +0200, Paolo Bonzini wrote:
> On 16/08/21 16:23, Daniel P. Berrangé wrote:
> > snip
> >
> > > With this implementation, the number of mirror vCPUs does not even have to
> > > be indicated on the command line. The VM and its vCPUs can simply be
> > > created when
Hello Paolo,
On Mon, Aug 16, 2021 at 04:58:02PM +0200, Paolo Bonzini wrote:
> On 16/08/21 16:44, Ashish Kalra wrote:
> > 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,
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 VM
On 16/08/21 16:23, Daniel P. Berrangé wrote:
snip
With this implementation, the number of mirror vCPUs does not even have to
be indicated on the command line. The VM and its vCPUs can simply be
created when migration starts. In the SEV-ES case, the guest can even
provide the VMSA that starts
On 16/08/21 16:44, Ashish Kalra wrote:
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 VM probably still need
to handles KVM_EXIT_IO when SEC phase does I/O, I can se
Hello Paolo,
On Mon, Aug 16, 2021 at 04:15:46PM +0200, Paolo Bonzini wrote:
> On 16/08/21 15:25, Ashish Kalra wrote:
> > From: Ashish Kalra
> >
> > This is an RFC series for Mirror VM support that are
> > essentially secondary VMs sharing the encryption context
> > (ASID) with a primary VM. The p
On Mon, Aug 16, 2021 at 04:15:46PM +0200, Paolo Bonzini wrote:
> On 16/08/21 15:25, Ashish Kalra wrote:
> > From: Ashish Kalra
> >
> > This is an RFC series for Mirror VM support that are
> > essentially secondary VMs sharing the encryption context
> > (ASID) with a primary VM. The patch-set creat
On 16/08/21 15:25, Ashish Kalra wrote:
From: Ashish Kalra
This is an RFC series for Mirror VM support that are
essentially secondary VMs sharing the encryption context
(ASID) with a primary VM. The patch-set creates a new
VM and shares the primary VM's encryption context
with it using the KVM_CA
On 8/16/21 3:25 PM, Ashish Kalra wrote:
> From: Ashish Kalra
>
> This is an RFC series for Mirror VM support that are
> essentially secondary VMs sharing the encryption context
> (ASID) with a primary VM. The patch-set creates a new
> VM and shares the primary VM's encryption context
> with
From: Ashish Kalra
This is an RFC series for Mirror VM support that are
essentially secondary VMs sharing the encryption context
(ASID) with a primary VM. The patch-set creates a new
VM and shares the primary VM's encryption context
with it using the KVM_CAP_VM_COPY_ENC_CONTEXT_FROM capability
51 matches
Mail list logo
