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=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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 3779EC433EF for ; Fri, 10 Sep 2021 03:41:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0E6336113E for ; Fri, 10 Sep 2021 03:41:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230107AbhIJDmk (ORCPT ); Thu, 9 Sep 2021 23:42:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54682 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229929AbhIJDmi (ORCPT ); Thu, 9 Sep 2021 23:42:38 -0400 Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::22f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7BBDBC061574 for ; Thu, 9 Sep 2021 20:41:28 -0700 (PDT) Received: by mail-oi1-x22f.google.com with SMTP id 6so1108625oiy.8 for ; Thu, 09 Sep 2021 20:41:28 -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=AcDaWUAinO2fEsf4ZPvLFB5Mx25ltgwZ7j4hlM6IIoM=; b=G59xvSv/rp+s9VhZYcfvC7HQvDS0+1Y/31lt72rGg4SuU/3q7Bur6+CZT0oX9BCHHd pf25q9r0pJpU7IZYtD45LxPTuZ7lt/+7kub6CoSg9zklHVO14+S7uSpfFltQBvw4eLda 8lFybnYaePz40XR9CFc+EAGr7DMGGnekQ+7B4JJVAbtpRqVdHwwqHHxKTtPtxEa7nmOJ gn6q36V9etefm6vpc8MR1hhLSUSfIVf4sVgvI8kVOp4VDzhqKL0p9tvVBUxdM9Hm8oWq W/ZyP2CYNdmexJXmP/Mtd7hliSmyQGlSFekxvfGhpoC0l2TuD4H/jNfkIlj/yZgCQLQf 5eOw== 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=AcDaWUAinO2fEsf4ZPvLFB5Mx25ltgwZ7j4hlM6IIoM=; b=O9PYYstDSjrQA091iBxesudJ4oMdmUjfcPeRJqLpegKBLOgMoQC1J2HMiKfVp6Zac4 qRAJLhO05jmm7PNkts2psraDfCKjc7ThbSDsRH0Zq9P70VOmoEz18O9jIHXTAHD/5idF y6m//vMKo4GLjDfbhup6q0A425of0rJCYwQP370tW/J4iOGW6Nhei0iyU9/r6aIFwmr1 lMu11KnjkMlLrMx66vaHLoFjXEULGBdZyBiODSPgLiq68Ip8TdR/wwxSHBJoDkDtDI8K iv381dc7UOjL+4WUU1k0DStvZBiifqngr52uLWqdr6hCdnNkFrPgQK+HnImCzmDD3kgk KdGg== X-Gm-Message-State: AOAM533AMmCFCzUsxV/oTtJdEFaTyj5sFDgHi9dWdLib385QlifKKvVS R62nKVFudA43ktnTpdb2QeVWliDzFCbYof+GGteqZQ== X-Google-Smtp-Source: ABdhPJxvqKgvT0iHOJw9pusSa94n3g4TIFRcc5YNy3WemyPlpTzR+73ed/PuZ8xeXXe2eHPgkUHuLRU2VwFFv/+rplk= X-Received: by 2002:a05:6808:2026:: with SMTP id q38mr2590770oiw.15.1631245287533; Thu, 09 Sep 2021 20:41:27 -0700 (PDT) MIME-Version: 1.0 References: <20210902181751.252227-1-pgonda@google.com> <20210902181751.252227-2-pgonda@google.com> In-Reply-To: From: Marc Orr Date: Thu, 9 Sep 2021 20:41:16 -0700 Message-ID: Subject: Re: [PATCH 1/3 V7] KVM, SEV: Add support for SEV intra host migration To: Sean Christopherson Cc: Peter Gonda , kvm list , Paolo Bonzini , David Rientjes , "Dr . David Alan Gilbert" , Brijesh Singh , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , LKML Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 9, 2021 at 6:40 PM Sean Christopherson wrote: > > On Thu, Sep 09, 2021, Marc Orr wrote: > > > > +int svm_vm_migrate_from(struct kvm *kvm, unsigned int source_fd) > > > > +{ > > > > + struct kvm_sev_info *dst_sev = &to_kvm_svm(kvm)->sev_info; > > > > + struct file *source_kvm_file; > > > > + struct kvm *source_kvm; > > > > + int ret; > > > > + > > > > + ret = svm_sev_lock_for_migration(kvm); > > > > + if (ret) > > > > + return ret; > > > > + > > > > + if (!sev_guest(kvm) || sev_es_guest(kvm)) { > > > > + ret = -EINVAL; > > > > + pr_warn_ratelimited("VM must be SEV enabled to migrate to.\n"); > > > > > > Linux generally doesn't log user errors to dmesg. They can be helpful during > > > development, but aren't actionable and thus are of limited use in production. > > > > Ha. I had suggested adding the logs when I reviewed these patches > > (maybe before Peter posted them publicly). My rationale is that if I'm > > looking at a crash in production, and all I have is a stack trace and > > the error code, then I can narrow the failure down to this function, > > but once the function starts returning the same error code in multiple > > places now it's non-trivial for me to deduce exactly which condition > > caused the crash. Having these logs makes it trivial. However, if this > > is not the preferred Linux style then so be it. > > I don't necessarily disagree, but none of these errors conditions should so much > as sniff production. E.g. if userspace invokes this on a !KVM fd or on a non-SEV > source, or before guest_state_protected=true, then userspace has bigger problems. > Ditto if the dest isn't actual KVM VM or doesn't meet whatever SEV-enabled/disabled > criteria we end up with. > > The mismatch in online_vcpus is the only one where I could reasonablly see a bug > escaping to production, e.g. due to an orchestration layer mixup. > > For all of these conditions, userspace _must_ be aware of the conditions for success, > and except for guest_state_protected=true, userspace has access to what state it > sent into KVM, e.g. it shouldn't be difficult for userspace dump the relevant bits > from the src and dst without any help from the kernel. > > If userspace really needs kernel help to differentiate what's up, I'd rather use > more unique errors for online_cpus and guest_state_protected, e.g. -E2BIG isn't > too big of a strecth for the online_cpus mismatch. SGTM, thanks.