From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f73.google.com (mail-pj1-f73.google.com [209.85.216.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3D28A28BA92 for ; Wed, 23 Apr 2025 17:16:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.73 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745428570; cv=none; b=PSyiXiDrG7qV7GgtfdAk/l5LfPRvlK12RehRiHxCjPhhgC7WLouGqkmRts6xaLP/ywnEDRh1rkfoP0Zdp39IIrNfxWfJO9uaZXiKYSU0Dj1S34tCe55vLTMMM1xKNMaakQxgz0L0FFtbS/YeUeA4v4KDtO17IEnuskKCmJSNitg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745428570; c=relaxed/simple; bh=s8DhHlPJWvIsgbsoToLAZ45tVx7yVHr17rRzAAX9TR0=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=Ly1RTpihOqRUuCC9iDTg9KrQMhAdsec6H+wmcbKecQj8AyXoUpU1z4310s1HxLVpVZj2RF/f9zAhql/doyiQpF4FmCjXR/HaWUab/5k8gTCPCmunkWri6SBpX9RM/rX2Klz5k6klbw/1pkm0CWqNPEA6Ousbm8tt2iAn3S4aags= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=JyBLkBSc; arc=none smtp.client-ip=209.85.216.73 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="JyBLkBSc" Received: by mail-pj1-f73.google.com with SMTP id 98e67ed59e1d1-2ff53a4754aso128061a91.2 for ; Wed, 23 Apr 2025 10:16:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1745428568; x=1746033368; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=hrqmrLz7e0CPs0ksITZKUWYoX57wzVXLqGxivpIF80E=; b=JyBLkBSchR4xLHbeRgBEugPxLKnCtmkw5CjaOsRdl96jefVgOcVoOTuAyyeNvPhztp EXtR9UiRbago5Ze9La5oW5y+e/QWC8msbtUXA/dRxlAPN6pOqrt3hcHpCq9ucYdxyN0W dIQLBlsemqJ+wPUdAC4ECvJt43HVn8FXpuEh78BJ6aNeIdh/8nc/9FIKIN83h3ucu+wA 3NDDuHRBrf6dr+JOQ8XmRYihW5l5N59aCoPCKKN6IcSvHDUIVMYDdmu2Pgd8CBITkj9A xINB6457sT6YVfifLUvkKcst2EE0V0x+bKQTd5hWnAhMIZ3OSQf49WEZyOeGJnDkcxxV Z01g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745428568; x=1746033368; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=hrqmrLz7e0CPs0ksITZKUWYoX57wzVXLqGxivpIF80E=; b=GnrdGJbxwVJF18LkauZSS66Q+hwsw3i2/pnf943lCzaLnZvECHXFXS/I75/MbXQdtD 2Mdmoi+Qn6L11lq9Lhzue4OK/KmzppkWyeFBWAuhZUeA3ATFwS29VLTukQJ85YfNDbnz f9azIu0wtNqRxHuItUGeTvK2SEh7F0Sk6uNb9Jr2RVKdrs9KP81mLcIQh+I0b/7Oq4Dr NcSbtFyfLxxwCoNvx1EWlEMNrvlrLhdO6zW9paQbsPHceLeW0Nhm7HmadG+OifHu8GGN 2STVFNFnBlpUYVTYzikhQZX2xMZXIKovHFwkhyiOkdeoVoEQWaLfUhtrzZBFXo1wKBbE Q/Rg== X-Forwarded-Encrypted: i=1; AJvYcCWUYHzrhU3Y/IpkTjru/qvAMAD+n5Q9Bc/eX3LlxvUilTS9+7Js/TeD8QO0HoBY+Kw9bet+tYUrdKuNAcI=@vger.kernel.org X-Gm-Message-State: AOJu0YyuaeZa5lcJNXPMSGV5b/xw1cc4z+WuT7xSK9o4hpevmmFWgcOe cScW+ntI5tv0vfrs3A7xJ1rS+UuayOYpVsiD3ps2rnsCKs/VCLu/nCJsycsaSWqgmn54A3dCZjS UPw== X-Google-Smtp-Source: AGHT+IHLl6jkGiLQ4wjyLG3esw4ZiRer7DcAc6NZDcDEWXrrD9hY5sUS0R/HiYWJa9E59RXMPwv8rRlRphU= X-Received: from pji5.prod.google.com ([2002:a17:90b:3fc5:b0:2ff:4ba2:f3a5]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:5690:b0:2ff:52b8:2767 with SMTP id 98e67ed59e1d1-3087bb69163mr27347605a91.19.1745428568576; Wed, 23 Apr 2025 10:16:08 -0700 (PDT) Date: Wed, 23 Apr 2025 10:16:07 -0700 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20250422161304.579394-1-zack.rusin@broadcom.com> <20250422161304.579394-5-zack.rusin@broadcom.com> Message-ID: Subject: Re: [PATCH v2 4/5] KVM: x86: Add support for legacy VMware backdoors in nested setups From: Sean Christopherson To: Zack Rusin Cc: Xin Li , linux-kernel@vger.kernel.org, Doug Covelli , Paolo Bonzini , Jonathan Corbet , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , kvm@vger.kernel.org, linux-doc@vger.kernel.org Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Wed, Apr 23, 2025, Zack Rusin wrote: > On Wed, Apr 23, 2025 at 11:54=E2=80=AFAM Sean Christopherson wrote: > > > I'd say that if we desperately want to use a single cap for all of > > > these then I'd probably prefer a different approach because this woul= d > > > make vmware_backdoor_enabled behavior really wacky. > > > > How so? If kvm.enable_vmware_backdoor is true, then the backdoor is en= abled > > for all VMs, else it's disabled by default but can be enabled on a per-= VM basis > > by the new capability. >=20 > Like you said if kvm.enable_vmware_backdoor is true, then it's > enabled for all VMs, so it'd make sense to allow disabling it on a > per-vm basis on those systems. > Just like when the kvm.enable_vmware_backdoor is false, the cap can be > used to enable it on a per-vm basis. Why? What use case does that serve? > > > It's the one that currently can only be set via kernel boot flags, so= having > > > systems where the boot flag is on and disabling it on a per-vm basis = makes > > > sense and breaks with this. > > > > We could go this route, e.g. KVM does something similar for PMU virtual= ization. > > But the key difference is that enable_pmu is enabled by default, wherea= s > > enable_vmware_backdoor is disabled by default. I.e. it makes far more = sense for > > the capability to let userspace opt-in, as opposed to opt-out. > > > > > I'd probably still write the code to be able to disable/enable all of= them > > > because it makes sense for vmware_backdoor_enabled. > > > > Again, that's not KVM's default, and it will never be KVM's default. >=20 > All I'm saying is that you can enable it on a whole system via the > boot flags and on the systems on which it has been turned on it'd make > sense to allow disabling it on a per-vm basis. Again, why would anyone do that? If you *know* you're going to run some VM= s with VMware emulation and some without, the sane approach is to not touch t= he module param and rely entirely on the capability. Otherwise the VMM must b= e able to opt-out, which means that running an older userspace that doesn't k= now about the new capability *can't* opt-out. The only reason to even keep the module param is to not break existing user= s, e.g. to be able to run VMs that want VMware functionality using an existing= VMM. > Anyway, I'm sure I can make it work correctly under any constraints, so l= et > me try to understand the issue because I'm not sure what we're solving he= re. > Is the problem the fact that we have three caps and instead want to squee= ze > all of the functionality under one cap? The "problem" is that I don't want to add complexity and create ABI for a u= se case that doesn't exist.