Re: [PATCH] KVM: PPC: Book3S HV: Validate arch_compat against host compatibility mode

[Amit Machhiwal <amachhiw@linux.ibm.com>]

Hi Gautam,

Thanks for testing this patch.

On 2026/06/08 02:11 PM, Gautam Menghani wrote:
> On Fri, Jun 05, 2026 at 12:55:50PM +0530, Vaibhav Jain wrote:
> > Hi Gautam,
> > 
> > Thanks for testing this patch. Few questions:
> > Gautam Menghani <gautam@linux.ibm.com> writes:
> > 
> > > On Wed, Jun 03, 2026 at 07:45:39PM +0530, Amit Machhiwal wrote:
> > >> On IBM POWER systems, newer processor generations can operate in
> > >> compatibility modes corresponding to earlier generations. This becomes
> > >> relevant for nested virtualization, where nested KVM guests may need to
> > >> run with a specific processor compatibility level.
> > >> 
> > <snip>
> > >
> > > I booted a KVM guest on LPAR with this patch in the following scenarios:
> > <snip>
> > 
> > > 3. P11 guest on P11 host booted in P10 compat mode: No error observed
> > This should have resulted in an error since booting a P11 guest on P10
> > compat mode host is not allowed with/without this patch. Can you please
> > check your test env and share the boot results.

Yes, this should have errored out if the patch were tested in
combination with the QEMU patches posted here [1]. 

> 
> - lscpu output (host P11 LPAR booted in p10 compat mode)
> # lscpu
> Architecture:                ppc64le
>   Byte Order:                Little Endian
> CPU(s):                      960
>   On-line CPU(s) list:       0-959
> Model name:                  POWER10 (architected), altivec supported
>   Model:                     2.0 (pvr 0082 0200)
>   Thread(s) per core:        8
>   Core(s) per socket:        15
>   Socket(s):                 8
>   Physical sockets:          4
>   Physical chips:            2
>   Physical cores/chip:       16
> 
> 
> - lscpu output from guest
> # lscpu
> Architecture:             ppc64le
>   Byte Order:             Little Endian
> CPU(s):                   4
>   On-line CPU(s) list:    0-3
> Model name:               Power11 (raw), altivec supported
>   Model:                  2.0 (pvr 0082 0200)
>   Thread(s) per core:     1
>   Core(s) per socket:     4
>   Socket(s):              1
> 
> 
> 
> - QEMU command line
> /usr/bin/qemu-system-ppc64 -device virtio-blk-pci,drive=drive0,id=virtblk0 \

So, this patch was indeed tested on a distro qemu binary.

But without the above mentioned QEMU patches, currently the '-EINVAL'
returned in this patch (or any other error returned for the compat
ioctl) is simply ignored by QEMU (which Patch#1 in the QEMU series is
trying to fix) and continues with arch_compat == 0, making the guest
continue with raw PVR support.

Now when we again land up in gs_msg_ops_vcpu_fill_info() in the guest
entry path, with the current logic and arch_compat being 0, we try to
set an appropriate value by looking at the cpu features, which in this
case, turns out to be the P10 LPVR. Subsequently, H_GUEST_SET_STATE is
called with this value of arch_compat and L0 never compalains about it
and guest continues to boot in P11 RAW mode while it shouldn't. The
guest booting in raw mode can be confirmed from the below information
from L2 guest:

  # lsprop /sys/firmware/devicetree/base/cpus/PowerPC\,POWER11@0/cpu-version 
  /sys/firmware/devicetree/base/cpus/PowerPC,POWER11@0/cpu-version
                   00820200 (8520192

Having said this, we should not only be relying on userspace/vmm to
handle this situation but detect this in KVM and error out as
appropriate. I'm currenlty working on the v2 of this patch for handling
this case and will post it after some more testing.


>     -drive file=/home/gautam/images/fc41.qcow2,format=qcow2,if=none,id=drive0 \
>     -m 100G -smp 4 -cpu host -nographic -machine pseries,ic-mode=xics -accel kvm

[1] https://lore.kernel.org/all/20260502140021.69712-1-amachhiw@linux.ibm.com/

Thanks,
Amit

> 
> 
> Thanks,
> Gautam