On Tue, Mar 16, 2021, Paolo Bonzini wrote:
> On 16/03/21 18:52, Sean Christopherson wrote:
> > > I don't
> > > know that holding the fd instead of the kvm makes that much better though,
> > > are there advantages to that I'm not seeing?
> > If there's no kvm pointer, it's much more difficult for
On 16/03/21 18:52, Sean Christopherson wrote:
I don't
know that holding the fd instead of the kvm makes that much better though,
are there advantages to that I'm not seeing?
If there's no kvm pointer, it's much more difficult for someone to do the wrong
thing, and any such shenanigans stick out
On Fri, Mar 12, 2021, Nathan Tempelman wrote:
> On Wed, Feb 24, 2021 at 9:37 AM Sean Christopherson wrote:
> > > @@ -1282,6 +1299,65 @@ int svm_unregister_enc_region(struct kvm *kvm,
> > > return ret;
> > > }
> > >
> > > +int svm_vm_copy_asid_to(struct kvm *kvm, unsigned int mirror_kvm_fd)
On 15/03/21 18:05, Tobin Feldman-Fitzthum wrote:
I can answer this part. I think this will actually be simpler than
with auxiliary vCPUs. There will be a separate pair of VM+vCPU file
descriptors within the same QEMU process, and some code to set up the
memory map using
On 3/11/21 11:29 AM, Paolo Bonzini wrote:
On 11/03/21 16:30, Tobin Feldman-Fitzthum wrote:
I am not sure how the mirror VM will be supported in QEMU. Usually
there is one QEMU process per-vm. Now we would need to run a second
VM and communicate with it during migration. Is there a way to do
On Wed, Feb 24, 2021 at 9:37 AM Sean Christopherson wrote:
>
> On Wed, Feb 24, 2021, Nathan Tempelman wrote:
> > static bool __sev_recycle_asids(int min_asid, int max_asid)
> > {
> > @@ -1124,6 +1129,10 @@ int svm_mem_enc_op(struct kvm *kvm, void __user
> > *argp)
> > if
On 11/03/21 16:30, Tobin Feldman-Fitzthum wrote:
I am not sure how the mirror VM will be supported in QEMU. Usually there
is one QEMU process per-vm. Now we would need to run a second VM and
communicate with it during migration. Is there a way to do this without
adding significant complexity?
On 24/02/21 09:59, Nathan Tempelman wrote:
Add a capability for userspace to mirror SEV encryption context from
one vm to another. On our side, this is intended to support a
Migration Helper vCPU, but it can also be used generically to support
other in-guest workloads scheduled by the host. The
On Fri, Mar 05, 2021, Ashish Kalra wrote:
> On Thu, Feb 25, 2021 at 10:49:00AM -0800, Steve Rutherford wrote:
> > On Thu, Feb 25, 2021 at 6:57 AM Tom Lendacky
> > wrote:
> > > >> +int svm_vm_copy_asid_to(struct kvm *kvm, unsigned int mirror_kvm_fd)
> > > >> +{
> > > >> + struct file
On Thu, Feb 25, 2021 at 10:49:00AM -0800, Steve Rutherford wrote:
> On Thu, Feb 25, 2021 at 6:57 AM Tom Lendacky wrote:
> > >> +int svm_vm_copy_asid_to(struct kvm *kvm, unsigned int mirror_kvm_fd)
> > >> +{
> > >> + struct file *mirror_kvm_file;
> > >> + struct kvm *mirror_kvm;
> > >>
On Fri, Mar 5, 2021 at 7:13 AM Paolo Bonzini wrote:
>
> On 05/03/21 15:04, Ashish Kalra wrote:
> >> +/* Mirrors of mirrors should work, but let's not get silly */
> >> +if (is_mirroring_enc_context(kvm)) {
> >> +ret = -ENOTTY;
> >> +goto failed;
> >> +}
> > How
On 05/03/21 15:04, Ashish Kalra wrote:
+ /* Mirrors of mirrors should work, but let's not get silly */
+ if (is_mirroring_enc_context(kvm)) {
+ ret = -ENOTTY;
+ goto failed;
+ }
How will A->B->C->... type of live migration work if mirrors of
mirrors
On Wed, Feb 24, 2021 at 08:59:15AM +, Nathan Tempelman wrote:
> Add a capability for userspace to mirror SEV encryption context from
> one vm to another. On our side, this is intended to support a
> Migration Helper vCPU, but it can also be used generically to support
> other in-guest
On Thu, Feb 25, 2021 at 09:33:09PM +0100, Paolo Bonzini wrote:
> On 25/02/21 19:18, Ashish Kalra wrote:
> > I do believe that some of these alternative SEV live migration support
> > or Migration helper (MH) solutions will still use SEV PSP migration for
> > migrating the MH itself, therefore the
On 25/02/21 18:53, James Bottomley wrote:
https://lore.kernel.org/qemu-devel/8b824c44-6a51-c3a7-6596-921dc47fe...@linux.ibm.com/
It sounds like this mechanism can be used to boot a vCPU through a
mirror VM after the fact, which is very compatible with the above whose
mechanism is simply to
On 25/02/21 19:18, Ashish Kalra wrote:
I do believe that some of these alternative SEV live migration support
or Migration helper (MH) solutions will still use SEV PSP migration for
migrating the MH itself, therefore the SEV live migration patches
(currently v10 posted upstream) still make sense
On Thu, Feb 25, 2021 at 6:57 AM Tom Lendacky wrote:
> >> +int svm_vm_copy_asid_to(struct kvm *kvm, unsigned int mirror_kvm_fd)
> >> +{
> >> + struct file *mirror_kvm_file;
> >> + struct kvm *mirror_kvm;
> >> + struct kvm_sev_info *mirror_kvm_sev;
> >> + unsigned int asid;
>> > For additional context, we need a Migration Helper because SEV PSP
>> > migration is far too slow for our live migration on its own. Using an
>> > in-guest migrator lets us speed this up significantly.
>>
>> We have the same problem here at IBM, hence the RFC referred to above.
>>
I do
> Add a capability for userspace to mirror SEV encryption context from
> one vm to another. On our side, this is intended to support a
> Migration Helper vCPU, but it can also be used generically to support
> other in-guest workloads scheduled by the host. The intention is for
> the primary guest
On 2/24/21 9:44 PM, Steve Rutherford wrote:
On Wed, Feb 24, 2021 at 1:00 AM Nathan Tempelman wrote:
@@ -1186,6 +1195,10 @@ int svm_register_enc_region(struct kvm *kvm,
if (!sev_guest(kvm))
return -ENOTTY;
+ /* If kvm is mirroring encryption context it isn't
On 24/02/21 17:58, Sean Christopherson wrote:
That being said, is there a strong need to get this into 5.12? AIUI, this
hasn't
had any meaningful testing, selftests/kvm-unit-tests or otherwise. Pushing out
to 5.13 might give us a good chance of getting some real testing before merging,
On Wed, Feb 24, 2021 at 9:37 AM Sean Christopherson wrote:
> > + unsigned int asid;
> > + int ret;
> > +
> > + if (!sev_guest(kvm))
> > + return -ENOTTY;
> > +
> > + mutex_lock(>lock);
> > +
> > + /* Mirrors of mirrors should work, but let's not get silly */
>
> Do
On Wed, Feb 24, 2021 at 1:00 AM Nathan Tempelman wrote:
>
> @@ -1186,6 +1195,10 @@ int svm_register_enc_region(struct kvm *kvm,
> if (!sev_guest(kvm))
> return -ENOTTY;
>
> + /* If kvm is mirroring encryption context it isn't responsible for it
> */
> + if
On Wed, Feb 24, 2021, Nathan Tempelman wrote:
> static bool __sev_recycle_asids(int min_asid, int max_asid)
> {
> @@ -1124,6 +1129,10 @@ int svm_mem_enc_op(struct kvm *kvm, void __user *argp)
> if (copy_from_user(_cmd, argp, sizeof(struct kvm_sev_cmd)))
> return -EFAULT;
>
+Marc and Wooky
On Wed, Feb 24, 2021, Paolo Bonzini wrote:
> [CCing Nathaniel McCallum]
Ah, I assume Enarx can use this to share an asid across multiple workloads?
> On 24/02/21 09:59, Nathan Tempelman wrote:
> >
> > +7.23 KVM_CAP_VM_COPY_ENC_CONTEXT_TO
> >
[CCing Nathaniel McCallum]
On 24/02/21 09:59, Nathan Tempelman wrote:
+7.23 KVM_CAP_VM_COPY_ENC_CONTEXT_TO
+---
+
+Architectures: x86 SEV enabled
+Type: system
vm ioctl, not system (/dev/kvm). But, see below.
+Parameters: args[0] is the fd of the kvm to
Add a capability for userspace to mirror SEV encryption context from
one vm to another. On our side, this is intended to support a
Migration Helper vCPU, but it can also be used generically to support
other in-guest workloads scheduled by the host. The intention is for
the primary guest and the
27 matches
Mail list logo
