Date:   Thu, 16 Mar 2023 17:19:48 +0800
From:   Yan Zhao <yan.y.zhao@intel.com>
To:     Sean Christopherson <seanjc@google.com>
CC:     Paolo Bonzini <pbonzini@redhat.com>,
        Zhenyu Wang <zhenyuw@linux.intel.com>,
        Zhi Wang <zhi.a.wang@intel.com>, <kvm@vger.kernel.org>,
        <intel-gvt-dev@lists.freedesktop.org>,
        <intel-gfx@lists.freedesktop.org>, <linux-kernel@vger.kernel.org>,
        Ben Gardon <bgardon@google.com>
Subject: Re: [PATCH v2 19/27] KVM: x86/mmu: Move KVM-only page-track
 declarations to internal header
Message-ID: <ZBLfNLb5z2EYdeXy@yzhao56-desk.sh.intel.com>
Reply-To: Yan Zhao <yan.y.zhao@intel.com>
References: <20230311002258.852397-1-seanjc@google.com>
 <20230311002258.852397-20-seanjc@google.com>
 <ZBGFXrpSXpF5NUlV@yzhao56-desk.sh.intel.com>
 <ZBHgoS/4R35KByOp@google.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <ZBHgoS/4R35KByOp@google.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?Bv+dBhLc+CV0C7+8sxgcp8gGDDPlezkXu1HYNpGyNRoWh//6DrKDrFvmYl1t?=
 =?us-ascii?Q?LS22Lx49ntY/TS70T+LH3uMJI5YbPu5E4iuHraKfZ2AtCRSsT1x7xbK7bRqr?=
 =?us-ascii?Q?jrrGuiQ8yIHDjjgNgA5aP4QPCZkAgAfNl1/iP/SQkhbYKa/GzoDUHUH7ub7S?=
 =?us-ascii?Q?Qdd0jLh1pn0d4eJW8jM9niX+PFPDYiiicDTijVtz/OS4GkXwiH/mJBzeQTZP?=
 =?us-ascii?Q?VwiQ9s+0h3fTWfhnXqJrBNb1Zlede+KrOPBqulPqubjcjxtcl05xSCa2Z2Id?=
 =?us-ascii?Q?113I+P1asRXYGsIjcBqHUjNMWW0CMpIhgWxaXeUjW/dj9D2oZh+JkLkiKyNA?=
 =?us-ascii?Q?fDiSSxcEDnP0NfHAl35es8ExjCOrhfeOGytlOnwOr63ojjzzz/t5XV6E3zmg?=
 =?us-ascii?Q?1A/i7zdYAY8x/4QEHIdyFRA9X4X2cjTCCQNNW26cMm7tjAN5kV44qOGHFCOZ?=
 =?us-ascii?Q?XQB62cCF/n0B3hJ5hw2GvaMdsyhNktO0pxFmV1S+OPPCcI2k2f8rkfAH3iAB?=
 =?us-ascii?Q?RWQktCRnAjEkNAwWYVDyo/jDWIoc4wYySiNl3q7Q1zzuBNX5/iYvfJpSuW8t?=
 =?us-ascii?Q?TdRHIPIvRjdBpUTa+gGHkX8oVH6ZAU6y6SLkJ15ZEM0A1xh1ooO8dIrSJdA0?=
 =?us-ascii?Q?HP9I7oE35b+b2q22//NJdMBDwYT+GKgN+zGuNeWUVXY1LNtD9Q68VKm+7JCi?=
 =?us-ascii?Q?Hhk1FO/DXyFHBUJafp10kJ8NBbaEdLXDI1oKa8E/Ho/wOSATR2fyucJ9baAF?=
 =?us-ascii?Q?3Gqy55g7HWQDt9Gm2pUXt5zBGt2FOn41n4i3FTQLg8NQ+/jKj5Pw4wZjLoDD?=
 =?us-ascii?Q?gPHmcjRF7lsmb3A6lJYd3hHBPRu5NENhp/WaqKL9XG3OTCbswO0phdB6KlIc?=
 =?us-ascii?Q?YYZ1IfDClM2KkNFffd3GE6x8RF07Yzm0/wXlC+wD2wkiKQVNRtuL8D8XqPBs?=
 =?us-ascii?Q?hWjI2AgnN/q5eII7jYCOyUvmz+WwKR96cE8eIItUQ9BtxANm71zs8y0Eoc++?=
 =?us-ascii?Q?qd+PH5Vy2ltpqxFG7VBEhRbC93A9AaE1aIlXJYG42IWwY4++0CR1iYq3BzUg?=
 =?us-ascii?Q?31YUFQiLKOD/eJmPuAtMh0vOu6+bmoj6EvNgiYGxlN8OCvzq9bzSoWfj7WHc?=
 =?us-ascii?Q?esax6v28Do5gWLnVZfqQiyzUCnN4szNUm9ZXazPomBuCjnQqChepALeb/2uP?=
 =?us-ascii?Q?h2UPCkyrHU6dcE+093mfQVSvGmPe5uvo1yj5k8L3eVHsAqCE6zA0Hr8yQJ6u?=
 =?us-ascii?Q?mm+YTO18yz3oo4owgnTF0grXQ5ho0EtsMshZNNS6Ab0wJZ/va67aCJgY5pvZ?=
 =?us-ascii?Q?dtll5cvZjZm1MtVeTyE8mc5GlAHt7S3jDJ5G79Y6cP5BJaea/sHcw1dvCdvZ?=
 =?us-ascii?Q?oj8CrKk2d06QBmcu9bX4E7It7TxiIsWdaCj8tzMGCMR64hCuQIIbazMRB2k/?=
 =?us-ascii?Q?IaCUd5meyorFE1IGipFqXvl+pyZ72Zp3jnP4BeyR1/gPGLJPOjv1KRsfw5WB?=
 =?us-ascii?Q?98ZllvVEpgIp951XhJyz1zWFvrrTkTl6GYGpp/oe3PsnYDngtSQ4c0vwsIGw?=
 =?us-ascii?Q?aHOO4otWzyZLmYM1LGoYb/7P1wi9lGH8GHcu5kSnUObxcJQajiRvKDLC9koP?=
 =?us-ascii?Q?Hw=3D=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: f34b43b0-07af-4822-76b3-08db260306b1
X-MS-Exchange-CrossTenant-AuthSource: DS7PR11MB5966.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Mar 2023 09:44:24.4451
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: sbPxdlyIpmydFPjueEJPoWxA20UYRcE7hLbDTosvvIrniH247ABcmT5PhFO/bnNgVzTjnoMH/anyWgIQn+OGdQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR11MB7409
X-OriginatorOrg: intel.com
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, Mar 15, 2023 at 08:13:37AM -0700, Sean Christopherson wrote:
> > A curious question:
> > are arch/x86/include/asm/kvm_*.h all expected to be external accessible?
> 
> Depends on what you mean by "expected".  Currently, yes, everything in there is
> globally visible.  But the vast majority of structs, defines, functions, etc. aren't
> intended for external non-KVM consumption, things ended up being globally visible
> largely through carelessness and/or a lack of a forcing function.
> 
> E.g. there is absolutely no reason anything outside of KVM should need
> arch/x86/include/asm/kvm-x86-ops.h, but it landed in asm/ because, at the time it
> was added, nothing would be harmed by making kvm-x86-ops.h "public" and we didn't
> scrutinize the patches well enough.
> 
> My primary motivation for this series is to (eventually) get to a state where only
> select symbols/defines/etc. are exposed by KVM to the outside world, and everything
> else is internal only.  The end goal of tightly restricting KVM's global API is to
> allow concurrently loading multiple instances of kvm.ko so that userspace can
> upgrade/rollback KVM without needed to move VMs off the host, i.e. by performing
> intrahost migration between differenate instances of KVM on the same host.  To do
> that safely, anything that is visible outside of KVM needs to be compatible across
> different instances of KVM, e.g. if kvm_vcpu is "public" then a KVM upgrade/rollback
> wouldn't be able to touch "struct kvm_vcpu" in any way.  We'll definitely want to be
> able to modify things like the vCPU structures, thus the push to restrict the API.
> 
> But even if we never realize that end goal, IMO drastically reducing KVM's "public"
> API surface is worthy goal in and of itself.
Got it. Thanks for explanation!