Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp1780394pxb; Fri, 20 Aug 2021 13:55:43 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyewm4Le4X49Z5aZdWJFlpOu38AHPndKuvjSPyJrMUiat4EYg/BStH6rUUW+tGde4YVqtOu X-Received: by 2002:a17:906:a044:: with SMTP id bg4mr23644564ejb.312.1629492943335; Fri, 20 Aug 2021 13:55:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1629492943; cv=none; d=google.com; s=arc-20160816; b=uDfTSxa54mnuXHLUfvcFzCQSXNE5yFUvPLUuy8Y9qKHHwjQp2Tf9G51W+hKaxz3lHE 6a7ba8psu7EAA2xcHaLyqbZfI/lUWQsb51Ada1RfGMtk1tP6hBIVssBZhZayfy0hS6yI YyFHOfLrGQIKfnX2D+sYfJZimAAyUekib+vFRzF3H1x89UF8nbKzINIDB1JgP4hSJ+1R B85V8WP4BqkG/s3ZT2uihf0cBkYOJo0AlFEUQkZIZx+1mwEiLIadcJu1dFmfj+sWfNC/ N+LvP3TDv4DXxw60RowZ5aL1s4k8vO4PiLdLLFsH5Qw1AVu7Vq7MGM0GLFUmiFlsRhDL MdVA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=rJhLGr0SS5PF10n3fxhzHZmG/BsOEa6vMnDsgK0F/eg=; b=z1SrvePXnywWIzhj2ZW7XrP32N7K0Qjg8cHmcQexp80rp7JxkMA0NqzLDVPejZFS1q F0hg2lGa62NuPONNvCJZpCXj9TXddMc8BVJQTo++sW74GRQ0/pSPcHH7YSmwMqZKf88a bpfdW+jHICxfJ88QxqoSEBVHg1zuqGmYJR09YWeMackOvXhwfsNE6tC+MTLoe6qSyM0S 23dZhuJsez3m07VD3y8SWYTv8TPs0IhAWROkJLvE4jhC5D8rHFRJRm9QXK0kvuT/rAOU p95R+kISJu0076im4o1e226bM8FLLZAkKwdne7ENobYaFibF3w8lH0mXU3JseUOGjmmm SGMw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=qZHhOVfv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l1si622350ejo.68.2021.08.20.13.55.19; Fri, 20 Aug 2021 13:55:43 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=qZHhOVfv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240038AbhHTUy1 (ORCPT + 99 others); Fri, 20 Aug 2021 16:54:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39826 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231171AbhHTUy0 (ORCPT ); Fri, 20 Aug 2021 16:54:26 -0400 Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9CC74C061575 for ; Fri, 20 Aug 2021 13:53:48 -0700 (PDT) Received: by mail-qk1-x736.google.com with SMTP id n11so12243206qkk.1 for ; Fri, 20 Aug 2021 13:53:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rJhLGr0SS5PF10n3fxhzHZmG/BsOEa6vMnDsgK0F/eg=; b=qZHhOVfvqTDAs7Vxag262xjADvDjb6zDTWSLRTNLV6o2zdtMNDZ0PdrNxaCWpc+A0e sc+C8RAHPVLMlgW1NkTt9qSzA4VewGqhNLepjU+SRJgQcjXSBZu/uC9cjhJ+baFUaLrI 8LyoMpMISdMlhgvNhD0FKspuDm82mfQs3hEatzgP1MLHKLT7IcinBW+r74VWOuwI0iBD TN64Y51MT+g/7I+DeyavLOiqtkt/MAPa6qOEfduxISn/LRMlnX0zyOXU7cVhvdNKG4zM ynaObzoRfBaliJDsBG/LJyYdIoCcmJc5YyV71/LGWvBjW7JsmZzQuMnwBWxr/7vjLA5y s1Xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rJhLGr0SS5PF10n3fxhzHZmG/BsOEa6vMnDsgK0F/eg=; b=HV1+KMmBhYCvh831GdlSxtAZ+MvZDiQKYZZpYkGfFBS80XXNjyXNu2+plZoWHGlZwG g+nd4Jz+iZ3kzGa1m1QupY5SqHI9rtpFnkRpP7YZXPowm+SzwXVckr8S9+n0T76939Zt 3D2eAOaIrUHRmpV2dUJKKiSf2d/X1gB0Ud+0+ucP0RR3pdHllQh78pakaCqETVKau5CC TWlHcd8j22m7Kl+7mbjoh0FUP6+S/sm9b3ZvLR1Aet/qNaFfZsv3vHcMoKoezBjjc5lh XmB/H/1wrBDDRriEwjwC/K6tAyA71n0NzrFQHnwHQz6xobItA8aBSEj6W6itqWw2qjn4 T74w== X-Gm-Message-State: AOAM531Ql5qbqSe77SjQDuOyKBU3l9oes4tN9Sx0rEdSUdrmhFsjusuY USO++xZHjuBqC9CHFVE/tBqNFIR6+VjxWsRXpGlkOg== X-Received: by 2002:a37:66d1:: with SMTP id a200mr10294551qkc.440.1629492827571; Fri, 20 Aug 2021 13:53:47 -0700 (PDT) MIME-Version: 1.0 References: <20210819154910.1064090-1-pgonda@google.com> <20210819154910.1064090-2-pgonda@google.com> In-Reply-To: From: Marc Orr Date: Fri, 20 Aug 2021 13:53:36 -0700 Message-ID: Subject: Re: [PATCH 1/2 V4] 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" , linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 19, 2021 at 3:58 PM Sean Christopherson wrote: > > On Thu, Aug 19, 2021, Peter Gonda wrote: > > > > > > > > +static int svm_sev_lock_for_migration(struct kvm *kvm) > > > > +{ > > > > + struct kvm_sev_info *sev = &to_kvm_svm(kvm)->sev_info; > > > > + int ret; > > > > + > > > > + /* > > > > + * Bail if this VM is already involved in a migration to avoid deadlock > > > > + * between two VMs trying to migrate to/from each other. > > > > + */ > > > > + spin_lock(&sev->migration_lock); > > > > + if (sev->migration_in_progress) > > > > + ret = -EBUSY; > > > > + else { > > > > + /* > > > > + * Otherwise indicate VM is migrating and take the KVM lock. > > > > + */ > > > > + sev->migration_in_progress = true; > > > > + mutex_lock(&kvm->lock); > > Deadlock aside, mutex_lock() can sleep, which is not allowed while holding a > spinlock, i.e. this patch does not work. That's my suggestion did the crazy > dance of "acquiring" a flag. > > What I don't know is why on earth I suggested a global spinlock, a simple atomic > should work, e.g. > > if (atomic_cmpxchg_acquire(&sev->migration_in_progress, 0, 1)) > return -EBUSY; > > mutex_lock(&kvm->lock); > > and on the backend... > > mutex_unlock(&kvm->lock); > > atomic_set_release(&sev->migration_in_progress, 0); +1 to replacing the spin lock with an atomic flag. Correctness issues aside, I think it's also cleaner. Also, I'd suggest adding a comment to source code to explain that the `migration_in_progress` flag is to prevent deadlock due to the "double migration" discussed previously.