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=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 0A3FCC2BA83 for ; Fri, 14 Feb 2020 18:57:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C8298206CC for ; Fri, 14 Feb 2020 18:57:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1581706628; bh=YlbFqP4MOujySUgnVR9wtKNwv0GjLZbM5SbUJK0O0gQ=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=yTNMG+XUuavHK+SZZLubR+dwpr7JSOTeCb3GcGSWmVadrvWcryIoHHVSJA9v4higA sf98620yni0geAOsOR7OZik79NL95yj1RfbTHZ0tBfut3AZYDqErob5Cfw+GD+wtXK RstmfbiyFl7nFwa+k2zxGjwEsM2Fz6R88j3XMMy8= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729841AbgBNS5I (ORCPT ); Fri, 14 Feb 2020 13:57:08 -0500 Received: from mail.kernel.org ([198.145.29.99]:45774 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725932AbgBNS5H (ORCPT ); Fri, 14 Feb 2020 13:57:07 -0500 Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 901C622314 for ; Fri, 14 Feb 2020 18:57:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1581706626; bh=YlbFqP4MOujySUgnVR9wtKNwv0GjLZbM5SbUJK0O0gQ=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=LFxgD4D+vmep4eAzrKNlFmVFdKVoEdLCpcb8r6lf3Y7K8zRscdcjqr7NFiohrVA85 HzvaAZxHtIPji4PzbrjMDpMUOw9EiuIwJGLQ2/v7mzoIFjvifDnzJgHub58d+I9LIM 8U/QNff+0x9O+PPZqDCBUvpj8SGZ5n3iEL5Alnrw= Received: by mail-wm1-f48.google.com with SMTP id t23so11032596wmi.1 for ; Fri, 14 Feb 2020 10:57:06 -0800 (PST) X-Gm-Message-State: APjAAAXJio4xIhV1usPPg2dxHZaNo5x/BJoRnPrQQ9bu4vzo33tuxqdJ v6shP3htSy1SoI4hDPVPJvqLckaB3xSRMEGZy+hIWA== X-Google-Smtp-Source: APXvYqxxTQ3SaP1YdoafrYMVaIYSQJJTGOsfi5VrDKZoEp9ouh4TF+uABwFX1kDAEk06lgdpKqTVZcp7FLgcnYYfkKY= X-Received: by 2002:a7b:cbcf:: with SMTP id n15mr6008857wmi.21.1581706625011; Fri, 14 Feb 2020 10:57:05 -0800 (PST) MIME-Version: 1.0 References: <20200213222825.GA8784@ashkalra_ubuntu_server> In-Reply-To: <20200213222825.GA8784@ashkalra_ubuntu_server> From: Andy Lutomirski Date: Fri, 14 Feb 2020 10:56:53 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 10/12] mm: x86: Invoke hypercall when page encryption status is changed To: Ashish Kalra Cc: Paolo Bonzini , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Radim Krcmar , Joerg Roedel , Borislav Petkov , Tom Lendacky , David Rientjes , X86 ML , kvm list , LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 13, 2020 at 2:28 PM Ashish Kalra wrote: > > On Wed, Feb 12, 2020 at 09:42:02PM -0800, Andy Lutomirski wrote: > >> On Wed, Feb 12, 2020 at 5:18 PM Ashish Kalra wrote: > >> > > >> > From: Brijesh Singh > > > > > > Invoke a hypercall when a memory region is changed from encrypted -> > > > decrypted and vice versa. Hypervisor need to know the page encryption > > > status during the guest migration. > >> > >> What happens if the guest memory status doesn't match what the > >> hypervisor thinks it is? What happens if the guest gets migrated > >> between the hypercall and the associated flushes? > > This is basically same as the dirty page tracking and logging being done > during Live Migration. As with dirty page tracking and logging we > maintain a page encryption bitmap in the kernel which keeps tracks of > guest's page encrypted/decrypted state changes and this bitmap is > sync'ed regularly from kernel to qemu and also during the live migration > process, therefore any dirty pages whose encryption status will change > during migration, should also have their page status updated when the > page encryption bitmap is sync'ed. > > Also i think that when the amount of dirty pages reach a low threshold, > QEMU stops the source VM and then transfers all the remaining dirty > pages, so at that point, there will also be a final sync of the page > encryption bitmap, there won't be any hypercalls after this as the > source VM has been stopped and the remaining VM state gets transferred. And have you ensured that, in the inevitable race when a guest gets migrated part way through an encryption state change, that no data corruption occurs?