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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 55A0AC433F5 for ; Thu, 31 Mar 2022 18:32:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234602AbiCaSeX (ORCPT ); Thu, 31 Mar 2022 14:34:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46310 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232464AbiCaSeW (ORCPT ); Thu, 31 Mar 2022 14:34:22 -0400 Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 975131C1ED5 for ; Thu, 31 Mar 2022 11:32:33 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id c15so902070ljr.9 for ; Thu, 31 Mar 2022 11:32:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Tvw6taPpgUktbBufV96johk8JlHiJhYBWcWPuBo5rDc=; b=gyTvwZKkWvITZ/zBPRstzK2sv3jlV0a0Qv4j6f3+SSTv0Q+DPIDg1CHCfkMvOizNNe fcFu/+LVmwvdfBMnWx9eJpH9bXskgTOomTeSXivuJphqNC1UIdx3Wm8AnWje6VCw/0Ws bVnVtbYRbbzSqSas2eUdPUXv3oGMaX7cZ0gpccp1XPIrzCtNiYGbLF0QfSJ/iVlMe1cs SAV0A2z33vKySiLF0gPFvGh2Brkp9URnuHx7Y0MYyCQW32BDoS1hBgwHysfxKhG+3A8T isNoHSIjD0P2uik7tChfWEI02cHLuFxNmBbHCnNA0kJXVhKpd+ty7goKqaGsInhk0JcZ aXUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Tvw6taPpgUktbBufV96johk8JlHiJhYBWcWPuBo5rDc=; b=TPI6MOSMECefSNwNMSOERPdiK46wHJv6jGsDkIyhVWumJykSeAxA+j7Mi0O2RhVXAN QgLe/YyC39Wuvvmd3AnGiCc0A+EqEbBxURLV+K0TvMAagjsWgu+NiOiyBitBvUuhEMON +/npchV2wZ3+SIo/470ccttOnOYeqyUEQg15m54PbI2bre4xBUm8Xz69e6jOlA6EBzZt l5c3bkigrSc2jw0AUuLMbLancvsqoh5s++cJLi5M4HPEAAdh8vaGyvTMXyS8lVT+E97f Bgei2evo6QL4PjuQVVOOw5cnRjctFS3X5dBW2XWyQo6Rm6G20ItLQ/fkbqiz+gRdtu8H LPkQ== X-Gm-Message-State: AOAM532gf8HNWnzTotDe4DRg8rTmk+UvRt6jApzLBhYYydpmEoQDupYe AvdFwRgocKbpiINwifT9F8RqHMNwAQW5otVbbV7ctQ== X-Google-Smtp-Source: ABdhPJxXnXZtYy6mA03Fv6Rv4cQWDrXySxfwsNF2WvESWs46OgIV2BdHAcwu0EAGIOeigzrCxylDpnc7CUfCL2n+N7Q= X-Received: by 2002:a2e:3c1a:0:b0:249:88f6:f606 with SMTP id j26-20020a2e3c1a000000b0024988f6f606mr11027684lja.132.1648751549725; Thu, 31 Mar 2022 11:32:29 -0700 (PDT) MIME-Version: 1.0 References: <20220308043857.13652-1-nikunj@amd.com> <5567f4ec-bbcf-4caf-16c1-3621b77a1779@amd.com> In-Reply-To: <5567f4ec-bbcf-4caf-16c1-3621b77a1779@amd.com> From: Peter Gonda Date: Thu, 31 Mar 2022 12:32:18 -0600 Message-ID: Subject: Re: [PATCH RFC v1 0/9] KVM: SVM: Defer page pinning for SEV guests To: "Nikunj A. Dadhania" Cc: Sean Christopherson , Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Brijesh Singh , Tom Lendacky , Bharata B Rao , "Maciej S . Szmigiero" , Mingwei Zhang , David Hildenbrand , kvm list , LKML Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 30, 2022 at 10:48 PM Nikunj A. Dadhania wrote: > > > > On 3/31/2022 1:17 AM, Sean Christopherson wrote: > > On Wed, Mar 30, 2022, Nikunj A. Dadhania wrote: > >> On 3/29/2022 2:30 AM, Sean Christopherson wrote: > >>> Let me preface this by saying I generally like the idea and especially the > >>> performance, but... > >>> > >>> I think we should abandon this approach in favor of committing all our resources > >>> to fd-based private memory[*], which (if done right) will provide on-demand pinning > >>> for "free". > >> > >> I will give this a try for SEV, was on my todo list. > >> > >>> I would much rather get that support merged sooner than later, and use > >>> it as a carrot for legacy SEV to get users to move over to its new APIs, with a long > >>> term goal of deprecating and disallowing SEV/SEV-ES guests without fd-based private > >>> memory. > >> > >>> That would require guest kernel support to communicate private vs. shared, > >> > >> Could you explain this in more detail? This is required for punching hole for shared pages? > > > > Unlike SEV-SNP, which enumerates private vs. shared in the error code, SEV and SEV-ES > > don't provide private vs. shared information to the host (KVM) on page fault. And > > it's even more fundamental then that, as SEV/SEV-ES won't even fault if the guest > > accesses the "wrong" GPA variant, they'll silent consume/corrupt data. > > > > That means KVM can't support implicit conversions for SEV/SEV-ES, and so an explicit > > hypercall is mandatory. SEV doesn't even have a vendor-agnostic guest/host paravirt > > ABI, and IIRC SEV-ES doesn't provide a conversion/map hypercall in the GHCB spec, so > > running a SEV/SEV-ES guest under UPM would require the guest firmware+kernel to be > > properly enlightened beyond what is required architecturally. > > > > So with guest supporting KVM_FEATURE_HC_MAP_GPA_RANGE and host (KVM) supporting > KVM_HC_MAP_GPA_RANGE hypercall, SEV/SEV-ES guest should communicate private/shared > pages to the hypervisor, this information can be used to mark page shared/private. One concern here may be that the VMM doesn't know which guests have KVM_FEATURE_HC_MAP_GPA_RANGE support and which don't. Only once the guest boots does the guest tell KVM that it supports KVM_FEATURE_HC_MAP_GPA_RANGE. If the guest doesn't we need to pin all the memory before we run the guest to be safe to be safe.