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 7E35BC3DA66 for ; Fri, 25 Aug 2023 06:42:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242252AbjHYGmV (ORCPT ); Fri, 25 Aug 2023 02:42:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59412 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242623AbjHYGmS (ORCPT ); Fri, 25 Aug 2023 02:42:18 -0400 Received: from mail.skyhub.de (mail.skyhub.de [IPv6:2a01:4f8:190:11c2::b:1457]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 97F022129 for ; Thu, 24 Aug 2023 23:41:58 -0700 (PDT) Received: from nazgul.tnic (unknown [78.130.214.203]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id E52801EC0338; Fri, 25 Aug 2023 08:41:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1692945717; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=n6ZUfPPmuShCDZMNulO4E5XiMbW+NH4bF6taV+K6lUM=; b=q0MM2F+JHF3YNlG4TG88j7crhewEQXXUvVvb7oibXCW8qe3bzX5qa2FW9h5WKyoOGfjouq iEAq6TsXjB4Y3iz2XtmUTGMT9f9KvIkYzpD2M9J9D4BbBdolj+LPQKybS+h1g93K4PEJGA IqNmYYEhS596GBt3cn2Voql6vipPXaE= Date: Fri, 25 Aug 2023 08:42:09 +0200 From: Borislav Petkov To: Josh Poimboeuf Cc: Andrew Cooper , x86@kernel.org, linux-kernel@vger.kernel.org, Peter Zijlstra , Babu Moger , Paolo Bonzini , Sean Christopherson , David.Kaplan@amd.com, Nikolay Borisov , gregkh@linuxfoundation.org, Thomas Gleixner Subject: Re: [PATCH 02/22] x86/srso: Set CPUID feature bits independently of bug or mitigation status Message-ID: <20230825064209.GCZOhNQf4wP1qWObOG@fat_crate.local> References: <26a3421e-3a88-b326-4c4f-abdaa2262852@citrix.com> <20230821140619.GBZONvWz+iwQZwx/sC@fat_crate.local> <20230823052007.GBZOWXBymcCUOoMax3@fat_crate.local> <22eb07b3-6de4-9fc2-fb05-2c7ebe6dc951@citrix.com> <20230824042420.GAZObbdNb38eKaCPAm@fat_crate.local> <20230824220440.ltmozuypice2kmwg@treble> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20230824220440.ltmozuypice2kmwg@treble> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 24, 2023 at 03:04:40PM -0700, Josh Poimboeuf wrote: > Something like this? Yeah, that's solving the immediate issue but what I mean is, I'd prefer to have a statement saying: "This is the use cases Foo and Bar related to live migration which we want to support because of reasons X and Y." So that we can know what we're actually supporting. I keep hearing of cloud vendors doing live migration but nothing about what the kernel running as a guest needs to support. And whether migration across generations should be supported. At all. And whether the kernel needs to even support anything. And if we don't know the use cases we can't even commit to supporting them. Or not break them in the future. And above you can replace "live migration" with any other feature that is requested. It helps immensely if we know how the kernel is used as most of us tip maintainers, IMNSVHO, are blissfully unaware of live migration. I hope that makes more sense. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette