linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andy Lutomirski <luto@kernel.org>
To: Ashish Kalra <Ashish.Kalra@amd.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Radim Krcmar <rkrcmar@redhat.com>, Joerg Roedel <joro@8bytes.org>,
	Borislav Petkov <bp@suse.de>,
	Tom Lendacky <thomas.lendacky@amd.com>,
	David Rientjes <rientjes@google.com>, X86 ML <x86@kernel.org>,
	kvm list <kvm@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Dave Hansen <dave.hansen@intel.com>
Subject: Re: [PATCH 00/12] SEV Live Migration Patchset.
Date: Wed, 12 Feb 2020 21:43:41 -0800	[thread overview]
Message-ID: <CALCETrXE9cWd3TbBZMsAwmSwWpDYFsicLZ=amHLWsvE0burQSw@mail.gmail.com> (raw)
In-Reply-To: <cover.1581555616.git.ashish.kalra@amd.com>

On Wed, Feb 12, 2020 at 5:14 PM Ashish Kalra <Ashish.Kalra@amd.com> wrote:
>
> From: Ashish Kalra <ashish.kalra@amd.com>
>
> This patchset adds support for SEV Live Migration on KVM/QEMU.

I skimmed this all and I don't see any description of how this all works.

Does any of this address the mess in svm_register_enc_region()?  Right
now, when QEMU (or a QEMU alternative) wants to allocate some memory
to be used for guest encrypted pages, it mmap()s some memory and the
kernel does get_user_pages_fast() on it.  The pages are kept pinned
for the lifetime of the mapping.  This is not at all okay.  Let's see:

 - The memory is pinned and it doesn't play well with the Linux memory
management code.  You just wrote a big patch set to migrate the pages
to a whole different machines, but we apparently can't even migrate
them to a different NUMA node or even just a different address.  And
good luck swapping it out.

 - The memory is still mapped in the QEMU process, and that mapping is
incoherent with actual guest access to the memory.  It's nice that KVM
clflushes it so that, in principle, everything might actually work,
but this is gross.  We should not be exposing incoherent mappings to
userspace.

Perhaps all this fancy infrastructure you're writing for migration and
all this new API surface could also teach the kernel how to migrate
pages from a guest *to the same guest* so we don't need to pin pages
forever.  And perhaps you could put some thought into how to improve
the API so that it doesn't involve nonsensical incoherent mappings.

(To be blunt: if I had noticed how the SEV code worked before it was
merged, I would have NAKed it.  It's too late now to retroactively
remove it from the kernel, but perhaps we could try not to pile more
complexity on top of the unfortunate foundation we have.)

  parent reply	other threads:[~2020-02-13  5:43 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-13  1:14 [PATCH 00/12] SEV Live Migration Patchset Ashish Kalra
2020-02-13  1:14 ` [PATCH 01/12] KVM: SVM: Add KVM_SEV SEND_START command Ashish Kalra
2020-03-09 21:28   ` Steve Rutherford
2020-03-10  0:19     ` Steve Rutherford
2020-02-13  1:15 ` [PATCH 02/12] KVM: SVM: Add KVM_SEND_UPDATE_DATA command Ashish Kalra
2020-03-10  1:04   ` Steve Rutherford
2020-03-12  1:49     ` Ashish Kalra
2020-02-13  1:16 ` [PATCH 03/12] KVM: SVM: Add KVM_SEV_SEND_FINISH command Ashish Kalra
2020-03-10  1:09   ` Steve Rutherford
2020-02-13  1:16 ` [PATCH 04/12] KVM: SVM: Add support for KVM_SEV_RECEIVE_START command Ashish Kalra
2020-03-10  1:41   ` Steve Rutherford
2020-03-12  0:38     ` Ashish Kalra
2020-03-12  2:55       ` Steve Rutherford
2020-02-13  1:16 ` [PATCH 05/12] KVM: SVM: Add KVM_SEV_RECEIVE_UPDATE_DATA command Ashish Kalra
2020-02-13  1:16 ` [PATCH 06/12] KVM: SVM: Add KVM_SEV_RECEIVE_FINISH command Ashish Kalra
2020-02-13  1:17 ` [PATCH 07/12] KVM: x86: Add AMD SEV specific Hypercall3 Ashish Kalra
2020-02-13  1:17 ` [PATCH 08/12] KVM: X86: Introduce KVM_HC_PAGE_ENC_STATUS hypercall Ashish Kalra
2020-02-20  2:39   ` Steve Rutherford
2020-02-20  5:28     ` Ashish Kalra
2020-02-20 21:21       ` Ashish Kalra
2020-02-13  1:17 ` [PATCH 09/12] KVM: x86: Introduce KVM_GET_PAGE_ENC_BITMAP ioctl Ashish Kalra
2020-02-27 17:57   ` Venu Busireddy
2020-02-27 18:18     ` Venu Busireddy
2020-02-27 19:38       ` Ashish Kalra
2020-02-13  1:18 ` [PATCH 10/12] mm: x86: Invoke hypercall when page encryption status is changed Ashish Kalra
2020-02-13  5:42   ` Andy Lutomirski
2020-02-13 22:28     ` Ashish Kalra
2020-02-14 18:56       ` Andy Lutomirski
2020-02-14 20:36         ` Ashish Kalra
2020-02-20  1:58   ` Steve Rutherford
2020-02-20  2:12     ` Andy Lutomirski
2020-02-20  3:29       ` Steve Rutherford
2020-02-20 15:54       ` Brijesh Singh
2020-02-20 20:43         ` Steve Rutherford
2020-02-20 22:43           ` Brijesh Singh
2020-02-20 23:23             ` Steve Rutherford
2020-02-20 23:40               ` Andy Lutomirski
2020-02-13  1:18 ` [PATCH 11/12] KVM: x86: Introduce KVM_SET_PAGE_ENC_BITMAP ioctl Ashish Kalra
2020-02-13  1:18 ` [PATCH 12/12] KVM: x86: Introduce KVM_PAGE_ENC_BITMAP_RESET ioctl Ashish Kalra
2020-02-13  5:43 ` Andy Lutomirski [this message]
2020-02-13 23:09   ` [PATCH 00/12] SEV Live Migration Patchset Ashish Kalra
2020-02-14 18:58     ` Andy Lutomirski
2020-02-17 19:49       ` Ashish Kalra
2020-03-03  1:05         ` Steve Rutherford
2020-03-03  4:42           ` Ashish Kalra
2020-03-19 13:05         ` Paolo Bonzini
2020-03-19 16:18           ` Ashish Kalra
2020-03-19 16:24             ` Paolo Bonzini
2020-02-14  2:10   ` Brijesh Singh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CALCETrXE9cWd3TbBZMsAwmSwWpDYFsicLZ=amHLWsvE0burQSw@mail.gmail.com' \
    --to=luto@kernel.org \
    --cc=Ashish.Kalra@amd.com \
    --cc=bp@suse.de \
    --cc=dave.hansen@intel.com \
    --cc=hpa@zytor.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rientjes@google.com \
    --cc=rkrcmar@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).