From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F3820C4338F for ; Mon, 16 Aug 2021 14:24:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D63996108E for ; Mon, 16 Aug 2021 14:24:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230518AbhHPOYk (ORCPT ); Mon, 16 Aug 2021 10:24:40 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:26817 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229880AbhHPOYk (ORCPT ); Mon, 16 Aug 2021 10:24:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1629123845; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=TU9WQqclCj5JWpeWLZIR7qY0KU/ywm/jjSLxeA7lujc=; b=LWhVsap6Ikb0Pfvke8ffZ9dGkSf9T5eqbHAnDZgcJVpArv1LYrDKUbUutX31erncWAhRQ5 lLKuCA6GMi7n+/98LjbdVwMnu3IdiWUZqXNZ56kD3+3NkcWQPo2aPVjH83AoHNqv7EaAz3 hJhb9mTgfeT2GkS/qFf1AH/aafYG5aw= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-535-GDv6rcngPZi8eOuy76aKWQ-1; Mon, 16 Aug 2021 10:24:02 -0400 X-MC-Unique: GDv6rcngPZi8eOuy76aKWQ-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 3D94F800493; Mon, 16 Aug 2021 14:24:00 +0000 (UTC) Received: from redhat.com (unknown [10.39.192.216]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0EFE75D9D3; Mon, 16 Aug 2021 14:23:52 +0000 (UTC) Date: Mon, 16 Aug 2021 15:23:50 +0100 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: Paolo Bonzini Cc: Ashish Kalra , qemu-devel@nongnu.org, thomas.lendacky@amd.com, brijesh.singh@amd.com, ehabkost@redhat.com, kvm@vger.kernel.org, mst@redhat.com, tobin@ibm.com, jejb@linux.ibm.com, richard.henderson@linaro.org, frankeh@us.ibm.com, dgilbert@redhat.com, dovmurik@linux.vnet.ibm.com Subject: Re: [RFC PATCH 00/13] Add support for Mirror VM. Message-ID: Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.0.7 (2021-05-04) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org 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 creates a new > > VM and shares the primary VM's encryption context > > with it using the KVM_CAP_VM_COPY_ENC_CONTEXT_FROM capability. > > The mirror VM uses a separate pair of VM + vCPU file > > descriptors and also uses a simplified KVM run loop, > > for example, it does not support any interrupt vmexit's. etc. > > Currently the mirror VM shares the address space of the > > primary VM. > > > > The mirror VM can be used for running an in-guest migration > > helper (MH). It also might have future uses for other in-guest > > operations. > 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 the migration helper. I don't think management apps will accept that approach when pinning guests. They will want control over how many extra vCPU threads are created, what host pCPUs they are pinned to, and what schedular policies might be applied to them. 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 :| From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2DBABC4338F for ; Mon, 16 Aug 2021 14:24:58 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id BDA716108E for ; Mon, 16 Aug 2021 14:24:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org BDA716108E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=nongnu.org Received: from localhost ([::1]:57836 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mFdXs-00075R-N3 for qemu-devel@archiver.kernel.org; Mon, 16 Aug 2021 10:24:56 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:33500) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mFdX7-0006Ns-MN for qemu-devel@nongnu.org; Mon, 16 Aug 2021 10:24:09 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:36347) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mFdX3-0006Q7-B3 for qemu-devel@nongnu.org; Mon, 16 Aug 2021 10:24:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1629123843; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=TU9WQqclCj5JWpeWLZIR7qY0KU/ywm/jjSLxeA7lujc=; b=hVUHIJuxcYFJeVLdRFcOYZh6f/DDTA1rtnyxEdtkV/d6k62HmF9lGenPxymkzcYsuRMwNw 8mazb/kHNR4Js7czh8TQCkGhHFcCjEI1EXUZBZ6UnaLqYYG0M5p/jM714bhk7vGcnkUkko AjZtgITi8KQ4RaHaoUCdmmrIHbD4fA4= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-535-GDv6rcngPZi8eOuy76aKWQ-1; Mon, 16 Aug 2021 10:24:02 -0400 X-MC-Unique: GDv6rcngPZi8eOuy76aKWQ-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 3D94F800493; Mon, 16 Aug 2021 14:24:00 +0000 (UTC) Received: from redhat.com (unknown [10.39.192.216]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0EFE75D9D3; Mon, 16 Aug 2021 14:23:52 +0000 (UTC) Date: Mon, 16 Aug 2021 15:23:50 +0100 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: Paolo Bonzini Subject: Re: [RFC PATCH 00/13] Add support for Mirror VM. Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.0.7 (2021-05-04) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 Received-SPF: pass client-ip=216.205.24.124; envelope-from=berrange@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -34 X-Spam_score: -3.5 X-Spam_bar: --- X-Spam_report: (-3.5 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= Cc: thomas.lendacky@amd.com, Ashish Kalra , brijesh.singh@amd.com, ehabkost@redhat.com, kvm@vger.kernel.org, mst@redhat.com, richard.henderson@linaro.org, jejb@linux.ibm.com, tobin@ibm.com, qemu-devel@nongnu.org, dgilbert@redhat.com, frankeh@us.ibm.com, dovmurik@linux.vnet.ibm.com Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" 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 creates a new > > VM and shares the primary VM's encryption context > > with it using the KVM_CAP_VM_COPY_ENC_CONTEXT_FROM capability. > > The mirror VM uses a separate pair of VM + vCPU file > > descriptors and also uses a simplified KVM run loop, > > for example, it does not support any interrupt vmexit's. etc. > > Currently the mirror VM shares the address space of the > > primary VM. > > > > The mirror VM can be used for running an in-guest migration > > helper (MH). It also might have future uses for other in-guest > > operations. > 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 the migration helper. I don't think management apps will accept that approach when pinning guests. They will want control over how many extra vCPU threads are created, what host pCPUs they are pinned to, and what schedular policies might be applied to them. 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 :|