All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anushree Mathur <anushree.mathur@linux.ibm.com>
To: Amit Machhiwal <amachhiw@linux.ibm.com>,
	qemu-ppc@nongnu.org, Harsh Prateek Bora <harshpb@linux.ibm.com>
Cc: Vaibhav Jain <vaibhav@linux.ibm.com>,
	Nicholas Piggin <npiggin@gmail.com>,
	Chinmay Rath <rathc@linux.ibm.com>,
	Glenn Miles <milesg@linux.ibm.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	qemu-devel@nongnu.org, kvm@vger.kernel.org,
	anushree.mathur@linux.ibm.com
Subject: Re: [PATCH v2 0/3] ppc/kvm: Handle CPU compatibility mode correctly for nested guests
Date: Fri, 15 May 2026 16:22:56 +0530	[thread overview]
Message-ID: <ace856fe-bd1e-46b1-b587-6cae408efd5e@linux.ibm.com> (raw)
In-Reply-To: <20260502140021.69712-1-amachhiw@linux.ibm.com>



On 02/05/26 7:30 PM, Amit Machhiwal wrote:
> 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 issues for nested virtualization. When booting a nested KVM
> guest, QEMU may derive the CPU model from the raw hardware PVR and attempt
> to configure the guest accordingly. However, the host is constrained by the
> compatibility level negotiated with the hypervisor, and requests exceeding
> that level are rejected by KVM, leading to guest boot failures such as:
>
>    KVM-NESTEDv2: couldn't set guest wide elements
>
> This series addresses the issue in two ways:
>
> 1. Do not silently fall back to raw mode when KVM rejects a requested
>     compatibility level during CAS. Instead, propagate the error so invalid
>     configurations are visible and fail early.
>
> 2. Query the effective CPU compatibility modes supported by the host via
>     KVM and use this information to select an appropriate CPU model for
>     nested guests.
>
> With these changes, QEMU avoids masking KVM errors and ensures that nested
> guests are configured with CPU models consistent with the host
> compatibility mode, allowing them to boot correctly.
>
> Patch summary:
>    [1/3] hw/ppc/spapr: Do not fallback to raw mode when KVM rejects compat
>    [2/3] [DO_NOT_MERGE] linux-headers: Add uapi header changes
>    [3/3] target/ppc/kvm: Use host compatibility mode for nested guests
>
> Changes in v2:
> - Patch 3: Guard compatibility mode code with #if defined(TARGET_PPC64)
>    to fix compilation for ppc32 targets. The POWER9/10/11 PVR constants
>    are only defined for 64-bit builds, and compatibility modes are only
>    relevant for 64-bit systems.
>
> Tested on:
>    - Power11 pSeries LPAR in Power10 compatibility mode
>    - Power10 PowerNV and QEMU PowerNV 11 TCG L0 host
>
> CI test results: https://gitlab.com/amachhiw/qemu/-/pipelines/2494987253
>
> Note: Patch 2 is marked DO_NOT_MERGE as it contains linux-headers updates
> that will be synced separately once the corresponding kernel patches are
> merged.
>
> The corresponding Linux patches have been posted [1]
>
> [1] https://lore.kernel.org/all/20260430054906.94431-1-amachhiw@linux.ibm.com/
>
> Amit Machhiwal (3):
>    hw/ppc/spapr: Do not fallback to raw mode when KVM rejects compat
>    [DO_NOT_MERGE] linux-headers: Add uapi header changes
>    target/ppc/kvm: Use host compatibility mode for nested guests
>
>   hw/ppc/spapr_hcall.c            |  9 ++++++
>   linux-headers/asm-powerpc/kvm.h |  7 ++++
>   linux-headers/linux/kvm.h       |  3 ++
>   target/ppc/kvm.c                | 57 +++++++++++++++++++++++++++++++++
>   4 files changed, 76 insertions(+)
>
>
> base-commit: 3d626609ccae61a2e552bccd59c7a0931bab8261



Hi Amit,
I tried booting up a guest on P11 lpar booted with P10 compat mode 
applying your patch along with the linux patch series and it has been 
working perfectly fine.

Host lscpu:

lscpu
Architecture:                ppc64le
   Byte Order:                Little Endian
CPU(s):                      80
   On-line CPU(s) list:       0-79
Model name:                  POWER10 (architected), altivec supported


Guest lscpu:

lscpu
Architecture:                ppc64le
   Byte Order:                Little Endian
CPU(s):                      10
   On-line CPU(s) list:       0-9
Model name:                  POWER10 (architected), altivec supported

Feel free to add :

Tested-by: Anushree Mathur <anushree.mathur@linux.ibm.com>

Thank you!
Anushree Mathur



      parent reply	other threads:[~2026-05-15 10:53 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-02 14:00 [PATCH v2 0/3] ppc/kvm: Handle CPU compatibility mode correctly for nested guests Amit Machhiwal
2026-05-02 14:00 ` [PATCH v2 1/3] hw/ppc/spapr: Do not fallback to raw mode when KVM rejects compat Amit Machhiwal
2026-05-02 14:00 ` [PATCH v2 2/3] [DO_NOT_MERGE] linux-headers: Add uapi header changes Amit Machhiwal
2026-05-02 14:00 ` [PATCH v2 3/3] target/ppc/kvm: Use host compatibility mode for nested guests Amit Machhiwal
2026-05-15 10:52 ` Anushree Mathur [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ace856fe-bd1e-46b1-b587-6cae408efd5e@linux.ibm.com \
    --to=anushree.mathur@linux.ibm.com \
    --cc=amachhiw@linux.ibm.com \
    --cc=harshpb@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=milesg@linux.ibm.com \
    --cc=npiggin@gmail.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=rathc@linux.ibm.com \
    --cc=vaibhav@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.