Received: by 2002:a05:6a10:9afc:0:0:0:0 with SMTP id t28csp4125954pxm; Tue, 1 Mar 2022 11:48:03 -0800 (PST) X-Google-Smtp-Source: ABdhPJwWVdmmVqYoQM3cPdtxNhlM08xaBGt9aSDh2RUNmYPwQ8s20F4cWxklbjtwFxvWNh/hLlae X-Received: by 2002:a05:6402:2c6:b0:415:b06c:de71 with SMTP id b6-20020a05640202c600b00415b06cde71mr828585edx.50.1646164082773; Tue, 01 Mar 2022 11:48:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646164082; cv=none; d=google.com; s=arc-20160816; b=rD3Y4mf0wE0v4/DZlaMhj1UFpmwJssLP7wJFISH9YN+4GjD3W1LSDFAkACW+DJ8vly hDbbVFYrgD3suZJvyEfMllQymBz3Ws9ofj9ajwFJDc8gRfLX+l8whnlWfuod8DN/J9++ E/SCpoLrYAWCXEFCbxRrXGq1WNSXnq4C4ha1whfa9XmAACEgMzDkqdnvE27d9enWAn3u Aja8q6d43h2RPDTKkpvSRsMpBZWSUnfBhj45nocZO1ACc71+3kQMacxkVx4lTfbmogzN 7oSWWHJaA9qyw0WQZrNBL6hkxTE4mBHCRp4OBSDvYsbEQRWnUMcMF3ltjgZE+160Wkeo CJsA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=qGDX0KQ8wXXEiThckeKmyeFBOujXgHDChWLqplnuWIU=; b=rKFGaXgQZcELluUSORaTr8sm0mZX+XDAGy/ufR+LdTQnqGDq40jk8yUJE3zE8S8tfp IPdDBX1EXb82AeHhjzpY/d7mw7iR4gpifvrQclnfEgYaDFgIsufzh3PhGdiK+9RMebMu ReeYoBB7V6AyaBr6C0hfK/OOCRkKtP26JpHNlJZvo6dEqkqqcKuinlbnhEL+9FKhBqZK 0ZTD/vruuHHmcOycopbPg9bPisZ/ZSnd8YkVe8jLORJ0RkYtn1asckvgNdXlDh8Fd/Gv nOpfKXB1p6g6loxZvXdl3JOe6kzMWnCQxq5QqoWZinXugqJ8EJrrx7IkvJyyGX6+WQHt vreQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=sFIIaOr3; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id t3-20020a1709060c4300b006cfce2f51c0si8399323ejf.871.2022.03.01.11.47.37; Tue, 01 Mar 2022 11:48:02 -0800 (PST) Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=sFIIaOr3; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232810AbiCATmX (ORCPT + 99 others); Tue, 1 Mar 2022 14:42:23 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39822 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232112AbiCATmX (ORCPT ); Tue, 1 Mar 2022 14:42:23 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D683465495; Tue, 1 Mar 2022 11:41:41 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 7246761632; Tue, 1 Mar 2022 19:41:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 58888C340EE; Tue, 1 Mar 2022 19:41:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1646163700; bh=C1fiXSQzp/6mGSE4wF5VaDuuI40Za2PZjhJbinmIoDs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=sFIIaOr3qhOtKIiGkw47+sRkCTakK6s4LOKKAyeJYuUR4/NwdOwfdasXUZZE+y2dN qTfAkZtm3bVoFwgnBR5c5AAcIWhrEK1eSu+jJttv2IPEGbRWp65T3CHVpPdKS0aQpb RsAEvhp7ssUECvOQfFWuscCf7xqrvhDIw/AQ44yk= Date: Tue, 1 Mar 2022 20:41:37 +0100 From: Greg KH To: "Jason A. Donenfeld" Cc: LKML , KVM list , QEMU Developers , linux-hyperv@vger.kernel.org, Linux Crypto Mailing List , Alexander Graf , "Michael Kelley (LINUX)" , adrian@parity.io, Laszlo Ersek , Daniel =?iso-8859-1?Q?P=2E_Berrang=E9?= , Dominik Brodowski , Jann Horn , "Michael S. Tsirkin" , "Rafael J. Wysocki" , "Brown, Len" , Pavel Machek , Linux PM , Colm MacCarthaigh , Theodore Ts'o , Arnd Bergmann Subject: Re: propagating vmgenid outward and upward Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-7.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Tue, Mar 01, 2022 at 07:24:11PM +0100, Jason A. Donenfeld wrote: > Hi Greg, > > On Tue, Mar 1, 2022 at 7:01 PM Greg KH wrote: > > A notifier block like this makes sense, but why tie onto the PM_ stuff? > > This isn't power management issues, it's a system-wide change that I am > > sure others will want to know about that doesn't reflect any power > > changes. > > > > As much as I hate adding new notifiers in the kernel, that might be all > > you need here. > > You might indeed be right. I guess I was thinking that "resuming from > suspend" and "resuming from a VM fork" are kind of the same thing. > There _is_ a certain kind of similarity between the two. I was hoping > if the similarity was a strong enough one, maybe it'd make sense to do > them together rather than adding another notifier. But I suppose you > disagree, and it sounds like Rafael might too -- > . Hey, nice, we agree! :) > Code-wise for me with WireGuard it's of course appealing to treat them > the same, since it's like a one line change, but if I need to add a > new notifier call there, it's not the end of the world. I know there are other places in the kernel that would like to be notified when they have been moved to another machine so that they can do things like determine if the CPU functionality has changed (or not), and perhaps do other types of device reconfiguration. Right now the kernel does not have any way of knowing this, so it makes sense that if the platform (i.e. ACPI here) has a way of creating such a event, it should and then we can start tieing in other subsystems to use it as-needed. thanks, greg k-h