From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f49.google.com (mail-pj1-f49.google.com [209.85.216.49]) (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 143422C0274 for ; Thu, 14 May 2026 03:54:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778730898; cv=none; b=aaYJdKDkPxhpGxvj4WEiPvYgw1VyjpH2UAdqiU2JvfnMhcOaZD24KHxocCx4nIWt+qhactQAwAJ33mExthMcLJCxSHFIXANzneq+5+K1z2iVMorzMdjBkUv5b2IoCecaKa7QseNKCnsd0lhcoqGkV1OZ6s4wcyEU/3g778MkS2w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778730898; c=relaxed/simple; bh=fsjYLSWcc71c+iOmkcD/Wk13v5fBkksJ8/Ir0dWeEvU=; h=From:To:Cc:Subject:In-Reply-To:Date:Message-ID:References; b=mMM6/nRjQ9j/i0qihyMTXhyiEiR7MYQabQepxcvkYrrnUpRq1w9uxLpJgMfkwM+bDu9qpKFrQDiVHHphoV3crViFoqnTiGJJwqpS05MpDOtOHvheXJLVUw9A1y9hOpT20U+uyWGcdvH6VQGlDGvKhTDu+NEWIBobLMr7JNXLnSo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=JACkQY5x; arc=none smtp.client-ip=209.85.216.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="JACkQY5x" Received: by mail-pj1-f49.google.com with SMTP id 98e67ed59e1d1-3684a6f3b0bso1879657a91.1 for ; Wed, 13 May 2026 20:54:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1778730896; x=1779335696; darn=vger.kernel.org; h=references:message-id:date:in-reply-to:subject:cc:to:from:from:to :cc:subject:date:message-id:reply-to; bh=PKqV86kcIyK48A4gK3vO7m3hgwBILm7DPz49r+DJUUE=; b=JACkQY5xKJCZGQs26Zykmd9Lg1tJcQ4rVuepEZPfSDc4IJarKYmg8sBekobEEsBY4A yt2wdD7rVKFHhm00Ew77pL89nD/neAkT54oCT5Ey+ssxK3wSiN7gsgeXEecG4XLpMuf2 4AK4Lvzt2TKRLWkUNqv1t/A8+JY7YC97NfDsx8PxuUneJowAHOHMC5lWOToOKVpjgkZJ IFCs/FLWexHIgSCIyXaRivY48dYSff1D2B8xv/acA+KoMNCKq5o02B3yF7psOgmP1DBO /94hkgxFEfWAfX8+rGk8wBrqkDgx704r+C7okeAD5de22NkfdrsOSCQHiElfURs12dD4 qEBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778730896; x=1779335696; h=references:message-id:date:in-reply-to:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=PKqV86kcIyK48A4gK3vO7m3hgwBILm7DPz49r+DJUUE=; b=hC/A7DY3a7hyEA1HLuoUCtkR7VXvcJDJx3MpLh8/B1EKnAdNv0C59gM+wsH/Sd+CEn i12t72wybq4YJ3zRxFDGnyNNQ5JlVAh/fUJk31I3pmyDDswdI8jdqoGS53VdG2XKLBwE XRqjUL7EGpIHocOUKgMtkuzuhzVp0xy5azYt4xwaIxWh260Lv/szHeXOo8LcG42YTCYp rN4mRTOrQ6R/7gDdL/xzmoUqdf0BMIj3ZfdfbxsPkzmj2SJV52CnB/H4EhQeqaqARmIx /HKz6KhBd1Kg8R5za3rATRoVlj5qf6EUeHZJ3epbsgp0N6P2/nETuokfCRQgWMrHzUED /PbQ== X-Forwarded-Encrypted: i=1; AFNElJ+XOP0TD5UeaWbdKv2F1K/LGDqtaOROrnkFoLRF60QJZxkFkiq9WuIEoDWSjZidOIKED250AL6YHEtGEWE=@vger.kernel.org X-Gm-Message-State: AOJu0YyXq/wImfGIkqap4CIMOLeXRkx+Er6+ShOfQu+cxHtvna/PfkUk 4tZ/9+Vz/QTG/GXyXgkl5MJn3/tDHHEHhhM8ENs7OXHcy+GO3M/7XGm8 X-Gm-Gg: Acq92OHgTmBO6etKTvDDvK+HiOfTELX5B3qDWWIkqUF1X4g7o2QNTALuz2GclfXjVQm G0DI7IQvW71MlTrp/akl9v/ewboE/kXTxhwmDp5fU8Db+RQFPhl3lA1Ao6agqOjZxCgT5AZq0XH oXLydLYebsvb+G01wssnSUOX4N34m0mV4eyICHFSv04GjSPUn1gl5gRqktpddQoLgsUP6CU8JfQ 18TsRNxt6xscE4iVvWE7e0t4l0N595oG46dsRWrOz5YEoDP1Eh/q2R3qsr9nOrsAGEyQDh3dXOt I8lTXmwRsmBovVBmwmWOHZA7MKZKwE26V6Tg0gkla5QjPGkJf+ZiG554tNfCXPDYu8J9fN7Aww3 KRluErlZ64O5b1GdagngvYKubLF1awTJ2qAbWDJSSlLchs0SStSBLiMLSooCh3Bjv49ZN+2Okxf PMwCCE31Pfs1JqdLPJI1Igmw== X-Received: by 2002:a17:90b:56c4:b0:366:44a4:ab0f with SMTP id 98e67ed59e1d1-3692346f997mr1680017a91.4.1778730896205; Wed, 13 May 2026 20:54:56 -0700 (PDT) Received: from pve-server ([49.205.216.49]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-368ede20a50sm4803643a91.3.2026.05.13.20.54.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 May 2026 20:54:55 -0700 (PDT) From: Ritesh Harjani (IBM) To: Amit Machhiwal , linuxppc-dev@lists.ozlabs.org, Madhavan Srinivasan Cc: Amit Machhiwal , Vaibhav Jain , Paolo Bonzini , Nicholas Piggin , Michael Ellerman , "Christophe Leroy (CS GROUP)" , Jonathan Corbet , Shuah Khan , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org Subject: Re: [PATCH v2 0/5] KVM: PPC: Handle CPU compatibility mode for nested guests In-Reply-To: <20260513100755.83215-1-amachhiw@linux.ibm.com> Date: Thu, 14 May 2026 08:49:59 +0530 Message-ID: References: <20260513100755.83215-1-amachhiw@linux.ibm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Hi Amit, Amit Machhiwal writes: > On POWER systems, newer processor generations can operate in compatibility > modes corresponding to earlier generations (e.g., a Power11 system running > in Power10 compatibility mode). In such cases, the effective CPU level > exposed to guests differs from the physical processor generation. > > This creates a problem for nested virtualization. When booting a nested KVM > guest (L2) inside a host KVM guest (L1) running in a compatibility mode, > userspace (e.g., QEMU) may derive the CPU model from the raw hardware PVR > and attempt to configure the nested guest accordingly. However, the L1 > partition is constrained by the compatibility level negotiated with the > hypervisor (L0), and requests exceeding that level are rejected, leading to > guest boot failures such as: > > KVM-NESTEDv2: couldn't set guest wide elements > > This series addresses the issue in two steps: > > 1. Detect and reject invalid compatibility requests early in KVM to avoid > late failures. > > 2. Provide a mechanism for userspace to query the effective CPU > compatibility modes supported by the host, so it can select an > appropriate CPU model for nested guests. > Do we really need to add a uapi change for this? Tools like Qemu can read the device tree info of the host, isn't it? > To achieve this, the series introduces a new KVM capability and ioctl > (KVM_CAP_PPC_COMPAT_CAPS / KVM_PPC_GET_COMPAT_CAPS) that expose the > compatibility modes supported by the host. > > The implementation supports both: > > - PowerVM (nested API v2), where compatibility information is obtained > via the H_GUEST_GET_CAPABILITIES hypercall. > - PowerNV (nested API v1), where compatibility is derived from the device > tree ("cpu-version") representing the effective processor compatibility > level. See there you go, for PowerNV if this info is provided in the device tree, then Qemu could as well just read that info, no? ... yup, kvmppc_read_int_dt() can do that I guess. So, my request is, can we look into this to see, if there is a possible alternative to this? maybe we already have a mechanism which Qemu could use to get this info already? btw - I haven't given a full read of the patch series, but reading the cover letter, I felt we should atleast add this info to the cover letter on, why a uapi change is really needed here, why can't the existing alternatives work for us. -ritesh > > This allows userspace (e.g., QEMU) to select a CPU model consistent with > the host compatibility mode, avoiding mismatches and enabling successful > nested guest boot. >