From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f174.google.com (mail-pg1-f174.google.com [209.85.215.174]) (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 292963D5640 for ; Wed, 5 Aug 2026 19:04:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785956674; cv=none; b=p/4wsb9r/+WMTWsgZDRQtqdWoFwg2xdno9G2qRwRTBSBqtGbfIH5x/aO5DzdqF5j2RT27XnO08cd8U0xFajMn2c74HXqkWkh9P3tLYDq2lefk2RaQf3dNGtyLyQJTcotdRmHDbumpdAc8NNYvrqwWafM4SHnZD25AhkIU4uNd68= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785956674; c=relaxed/simple; bh=cHTJQT/RBVKmLBGY8jEZzpAPKstx7GoblZ2qvVZvaPk=; h=From:To:Cc:Subject:In-Reply-To:Date:Message-ID:References; b=he7I/0jvp3AdeS43xJyBrQTdrj7zQWs75Z5o0eYP5UEVco8J+yH3nqX33oz5tz7C5Ym6EuHNumWwpOFemhrh0sOhFfGc4A3Sc7/47+nkm2FQR+IeKtdnDXLPawsNqQzi6Q+pn/zSknwQQIZdKu0tiVe51zMeEjpKLBw0POltHhw= 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=CoCQUYah; arc=none smtp.client-ip=209.85.215.174 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="CoCQUYah" Received: by mail-pg1-f174.google.com with SMTP id 41be03b00d2f7-ca7bea5e5b3so1115737a12.1 for ; Wed, 05 Aug 2026 12:04:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785956669; x=1786561469; 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:content-type; bh=V5Nj3gKC4yEN6e3D1EtvSjC4Has3vClSVMr6RcOyF2w=; b=CoCQUYahxJaR1S7hhSRrAFui2LryVSJqbPV+GSjVS0HCJl/B60TxQ4kKasB3XckfH1 CzSeHKIWy+1LS9p+JPflidlb7iG/yX3f392aSX2Fa+qQED00IdUzxKXwGaqr8W1t2I9h 0SfrhS1LCptm/4IdK9I6bd5XWlXhPCWMOeUd/GLYL7Lq+8W4XGY+suweD1YfRx613lq6 4jKJ2YKKUJduNnK07kGOovESYfagvbLXQL15l/75akhpBd1CUjsjAXXj0ftMqVqoPvpZ mnK2AcjkfgDyZ12cpada6aM9OH2GRpjCrum2mT+8UFcbRfQbe04xbBaO9EQz1wDJyalr mfNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785956669; x=1786561469; 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 :content-type; bh=V5Nj3gKC4yEN6e3D1EtvSjC4Has3vClSVMr6RcOyF2w=; b=EUTGQPjt4Zq5t0e99Y/HXimjkHRuJxv5bJP98vZGFP008eTBrG4xhCntqxUSzKafeg WEI8g0Zdec2+aYhSPkBUoSMGGwmEeBItiacGgvct8rH+4XubEJ1KVP/jqjQUxH8juBWA NCWYhKlx/RNO6P9BsBd/BAHgPRrnfN55GYI5gNQNSOP/SympQ2TF8914diEDF7enyMHr oWrtXbtjsGKDNTbdL+sbUqPryIoosgJXvLN1stfcblTTa64vuJ6YwPzAcZsqq9UUGilx ARTH+edBb+6ldap7May9WTLr28anfyXprOjBSTUxdvD7fmu5Vk5TDSCw9OGevxB7HyLs 3N7Q== X-Forwarded-Encrypted: i=1; AHgh+Rph4faSTL3uouBrZWgNzBONxI+B/RQBivdL0a9rtYf2NDZPJo2mNlLroUlMgISTKI93Tyd51iAKqihuIzQ=@vger.kernel.org X-Gm-Message-State: AOJu0YzKRmZBd4GASdjGfEL6AqAI3Mu5E0qqsGLWrlMuPc4nuDWrVq3w sO94KiuNfOQQyd0pX90KX10IVDJq6E9mBi/l5j945G2pHlmy6b58ydc9q/J+3Q== X-Gm-Gg: AR+sD13OjxsNZQjMjC316sxScHM1gfP3esTnOT/gV++Zq4/ZYlU1pnhILHMt3nd/w69 uf+xTkcUChp8qXAQK7H4hOUIQ7JCgKmYFCz8xidLsF38FBHUE8zPlNQFGOq3NfcK0XPu39KnmHF tUwOqI0VG8EQX6ivkkwa1Qe6PtnmLqbX0trRgiJ055YIK4GBeiX2UA6WP1YAgNqAC8wdOZ7GE3U M+k1F/oqVNXucQf8PHcC8yjxnEuTooIsidL/1p/U9ZZp/8LtB0gbLbYJwgRlkA3j2AgOPNL4POL XwTJhjaKmbBOZZCJ1Rb9g+581LNWKb1JjLIUoTjaW+R6ULvqgDdwv3Jv9ts4OSTgFqKEjjBHpkQ GsSz2iSYg7xuMweCNkZn//tn3NZbTLLuEpm0DD1xBlOKeb+3DoK85puRdmUYqAReJPUto9hFTIC HKEMlQcMjn809q3f7VvLqdC2/sW4QI5xSS+wSlYDZJbsfZjk1iKvTUaYm4Teo= X-Received: by 2002:a05:6a20:918e:b0:3c4:46ca:334b with SMTP id adf61e73a8af0-3cb85e2acc2mr8616548637.9.1785956669049; Wed, 05 Aug 2026 12:04:29 -0700 (PDT) Received: from pve-server ([49.205.216.49]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-315867a68fdsm31787485eec.25.2026.08.05.12.04.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Aug 2026 12:04:28 -0700 (PDT) From: Ritesh Harjani (IBM) To: Amit Machhiwal , linuxppc-dev@lists.ozlabs.org, Madhavan Srinivasan Cc: Vaibhav Jain , Amit Machhiwal , Anushree Mathur , 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 v6 0/4] KVM: PPC: Expose CPU compatibility modes for nested guests In-Reply-To: <20260804180705.59160-1-amachhiw@linux.ibm.com> Date: Thu, 06 Aug 2026 00:09:43 +0530 Message-ID: References: <20260804180705.59160-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 provides 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. > > 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. > Sorry, but I am somehow not convinced on whether we need all of this machinary just to get these 3 bits of information, which we are returning today. Since KVM_CHECK_EXTENSION can already return an int, so why can't we use KVM_CAP_PPC_COMPAT_CAPS itself and return the bitmap of supported compat modes to the user? Say if the cap is not supported, we can return 0, otherwise we can return the bitmap of supported compat modes. This will easily allow us to use 31-bits which as I see would be hardly a problem in the near future. In the future if it grows - we can always use KVM_CAP_PPC_COMPAT_CAPS2. This should reduce the code complexity both in the kernel and userspace and we don't even need a new ioctl then. Thoughts? -ritesh