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 74C62C47082 for ; Wed, 26 May 2021 21:17:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 547B4613D2 for ; Wed, 26 May 2021 21:17:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233725AbhEZVSu (ORCPT ); Wed, 26 May 2021 17:18:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41432 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233241AbhEZVSh (ORCPT ); Wed, 26 May 2021 17:18:37 -0400 Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 18A24C06175F for ; Wed, 26 May 2021 14:17:03 -0700 (PDT) Received: by mail-pg1-x533.google.com with SMTP id m190so2037831pga.2 for ; Wed, 26 May 2021 14:17:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=k6mJe3ISeJnwgKzjO2ePdb3h4jxlFF2xvibZQHBvtTU=; b=aioJbj4TdMs8oefTrnLR/RoKtdmEYZ+pVc0W6RP1vQ1JmJM5awlKi2dp/cw6Fs0NsB Y5MJHOnxj9dalfPd5aQowX0ufZwk0Y/v8eYgEr6ZiFdBvknnYWtZbqTWEaiftUgK1xFd j6Qza8oh6mEh8D5AHSUZtHlJyAWd80LHSoAX46HIeJxlfXFufQyb60lGrunRAoiFiXJ6 dfBZ6i8xsc1h1BibDsVcN+JCdhAqqqkmO07ncQv1qjjYBzLr6iwaGH0npX3TafSllbCt 2/xaSiTFnIwUOJNpTqYIZGFa2SDC8gdWfi+XS523IOxo65GG1qEWbIrdtJTCZ0w1OtsO X/eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=k6mJe3ISeJnwgKzjO2ePdb3h4jxlFF2xvibZQHBvtTU=; b=glX+UGLPZCEqRlwAGR5vF/WIEU3HPAAARNZ1qascZxYUiVwKATPoUPmT24yzBC3FKZ 38sokVzSMbjvDdNn7cgmf60MTNvddl3CfWvWUceAmrmI92HJ6O5lJzlNe4wAJ+jo/5SL 9nhRhpkfM8Y7BvnTvvyST7H7PPpjvRE2nLP0ADam5ay69/mrkvVh632QrcyeCq4F5zBZ 35w0OjygbYRTXSlMq4sTCr1ZweaUK8EbENpKzd++hES3CRPeDkrr286DxoPDLoDpauvw C2tomjvJC5yJrf/+3NLBRuATc30Qz5J+Y+9HuUXDSDy6XU26oi0OTmrwfuoNVyIGaw+c GRNA== X-Gm-Message-State: AOAM531mDNfXxhjGexHwtgD/h+52+L/xNZDhJjS/sAD1hUqOQy86Ueut PKwIQmzuyi8QZora6/6UrYKNlg== X-Google-Smtp-Source: ABdhPJym48czUmP/lanrXEC0yHDmgc7Ua1qA5PFNYQidngZyPGe+k+zNRRbvZVsNw5o2jDtj3K48gA== X-Received: by 2002:a63:2307:: with SMTP id j7mr458220pgj.20.1622063822494; Wed, 26 May 2021 14:17:02 -0700 (PDT) Received: from google.com (240.111.247.35.bc.googleusercontent.com. [35.247.111.240]) by smtp.gmail.com with ESMTPSA id n21sm134181pfu.99.2021.05.26.14.17.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 26 May 2021 14:17:02 -0700 (PDT) Date: Wed, 26 May 2021 21:16:58 +0000 From: Sean Christopherson To: Ben Gardon Cc: Paolo Bonzini , Maxim Levitsky , Jim Mattson , Junaid Shahid , Peter Xu , LKML , kvm Subject: Re: Writable module parameters in KVM Message-ID: References: <35fe7a86-d808-00e9-a6aa-e77b731bd4bf@redhat.com> <2fd417c59f40bd10a3446f9ed4be434e17e9a64f.camel@redhat.com> <927cbe06-7183-1153-95ea-f97eb4ff12f6@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 26, 2021, Ben Gardon wrote: > I don't know if there's a great way to formally encode this distinction, but > I see two major classes of writable params in terms of complexity: > > 1. parameters that are captured on VM creation and follow the life of > the VM e.g. the TDP MMU > > 2. parameters which have an effect on all VMs on the system when > changed e.g. internally we have sysctls to change NX reclaim > parameters > > I think class 1 is substantially easier to reason about from a code > perspective, but might be more confusing to userspace, as the current > value of the parameter has no bearing on the value captured by the VM. > Class 2 will probably be more complex to implement, require > synchronization, and need a better justification. That assessement isn't universally true, e.g. 'npt' and 'ept' could be snapshotted and put into (1), but as discussed, the fallout would be spectactular. And on the other side, the flush/sync on reuse flag is fully dynamic and falls into (2), yet is trivial to implement. That said, I don't think it matters because I don't think classifying params will change anyone's behavior. Each param would still need to be justified and reviewed on a case-by-case basis.