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 <[email protected]> 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/[email protected]/ Thanks, Amit > > > Thanks, > Gautam
