[Linux PPC] KVM PR and KVM HV do not work if the kernel was compiled with PREEMPT

[Linux PPC] KVM PR and KVM HV do not work if the kernel was compiled with PREEMPT

[Christian Zigotzky]

Hello,

KVM PR and KVM HV do not work if the kernel was compiled with PREEMPT.

The entire FSL Cyrus+ board freezes when using KVM HV with PREEMPT.

The guest kernel doesn't boot if we use KVM PR with a PREEMPT kernel on 
the PA Semi Nemo board.

We were previously able to disable PREEMPT in the kernel configuration, 
but the latest git kernels now enable it by default and it is no longer 
possible to disable it.

I created a patch for disabling PREEMPT today. [1]

Is it possible to let us decide whether to activate PREEMPT or not?

Thanks in advance,

Christian

[1] 
https://raw.githubusercontent.com/chzigotzky/kernels/a74fa6179eaeafcea7ad89f0e61c30ace038daf2/patches/X1000/Kconfig.preempt.patch
[2] Bug report: https://github.com/chzigotzky/kernels/issues/19

Re: [Linux PPC] KVM PR and KVM HV do not work if the kernel was compiled with PREEMPT

[Shrikanth Hegde]

On 2/14/26 7:32 PM, Christian Zigotzky wrote:
> Hello,
> 
> KVM PR and KVM HV do not work if the kernel was compiled with PREEMPT.
> 
> The entire FSL Cyrus+ board freezes when using KVM HV with PREEMPT.
> 
> The guest kernel doesn't boot if we use KVM PR with a PREEMPT kernel on 
> the PA Semi Nemo board.
> 
> We were previously able to disable PREEMPT in the kernel configuration, 
> but the latest git kernels now enable it by default and it is no longer 
> possible to disable it.
> 
> I created a patch for disabling PREEMPT today. [1]
> 
> Is it possible to let us decide whether to activate PREEMPT or not?
> 
> Thanks in advance,
> 
> Christian
> 
> [1] https://raw.githubusercontent.com/chzigotzky/kernels/ 
> a74fa6179eaeafcea7ad89f0e61c30ace038daf2/patches/X1000/ 
> Kconfig.preempt.patch
> [2] Bug report: https://github.com/chzigotzky/kernels/issues/19


Hi.

Do you have any trace why it is stuck? That would be useful.



My initial take is cond_resched is a nop. So we might be stuck there.
Eventually it should have come out though.

Could you please give the below patch a try and let me know?
Note: This likely still needs lazy bit handling. So keep in preempt=full.
(Not tested)


diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index 7667563fb9ff..fe215d1177fe 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -4901,7 +4901,7 @@ int kvmhv_run_single_vcpu(struct kvm_vcpu *vcpu, u64 time_limit,
         }
  
         if (need_resched())
-               cond_resched();
+               schedule();
  
         kvmppc_update_vpas(vcpu);
  
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 9a89a6d98f97..54963c1d8b58 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -86,7 +86,7 @@ int kvmppc_prepare_to_enter(struct kvm_vcpu *vcpu)
         while (true) {
                 if (need_resched()) {
                         local_irq_enable();
-                       cond_resched();
+                       schedule();
                         hard_irq_disable();
                         continue;
                 }

[Linux PPC] KVM PR and KVM HV do not work if the kernel was compiled with PREEMPT

[Christian Zigotzky]

Hi,

Thank you for your patch. I tested the latest git kernel with your patch 
today. Unfortunately the system freezes while booting the VM with KVM HV.

Cheers,
Christian


On 17/02/26 06:02, Shrikanth Hegde wrote:
>
>
> On 2/14/26 7:32 PM, Christian Zigotzky wrote:
>> Hello,
>>
>> KVM PR and KVM HV do not work if the kernel was compiled with PREEMPT.
>>
>> The entire FSL Cyrus+ board freezes when using KVM HV with PREEMPT.
>>
>> The guest kernel doesn't boot if we use KVM PR with a PREEMPT kernel 
>> on the PA Semi Nemo board.
>>
>> We were previously able to disable PREEMPT in the kernel 
>> configuration, but the latest git kernels now enable it by default 
>> and it is no longer possible to disable it.
>>
>> I created a patch for disabling PREEMPT today. [1]
>>
>> Is it possible to let us decide whether to activate PREEMPT or not?
>>
>> Thanks in advance,
>>
>> Christian
>>
>> [1] https://raw.githubusercontent.com/chzigotzky/kernels/ 
>> a74fa6179eaeafcea7ad89f0e61c30ace038daf2/patches/X1000/ 
>> Kconfig.preempt.patch
>> [2] Bug report: https://github.com/chzigotzky/kernels/issues/19
>
>
> Hi.
>
> Do you have any trace why it is stuck? That would be useful.
>
>
>
> My initial take is cond_resched is a nop. So we might be stuck there.
> Eventually it should have come out though.
>
> Could you please give the below patch a try and let me know?
> Note: This likely still needs lazy bit handling. So keep in preempt=full.
> (Not tested)
>
>
> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
> index 7667563fb9ff..fe215d1177fe 100644
> --- a/arch/powerpc/kvm/book3s_hv.c
> +++ b/arch/powerpc/kvm/book3s_hv.c
> @@ -4901,7 +4901,7 @@ int kvmhv_run_single_vcpu(struct kvm_vcpu *vcpu, 
> u64 time_limit,
>         }
>
>         if (need_resched())
> -               cond_resched();
> +               schedule();
>
>         kvmppc_update_vpas(vcpu);
>
> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
> index 9a89a6d98f97..54963c1d8b58 100644
> --- a/arch/powerpc/kvm/powerpc.c
> +++ b/arch/powerpc/kvm/powerpc.c
> @@ -86,7 +86,7 @@ int kvmppc_prepare_to_enter(struct kvm_vcpu *vcpu)
>         while (true) {
>                 if (need_resched()) {
>                         local_irq_enable();
> -                       cond_resched();
> +                       schedule();
>                         hard_irq_disable();
>                         continue;
>                 }


-- 
Sent with BrassMonkey 33.9.1 (https://github.com/chzigotzky/Web-Browsers-and-Suites-for-Linux-PPC/releases/tag/BrassMonkey_33.9.1)

Re: [Linux PPC] KVM PR and KVM HV do not work if the kernel was compiled with PREEMPT

[Shrikanth Hegde]

On 2/17/26 2:22 PM, Christian Zigotzky wrote:
> Hi,
> 
> Thank you for your patch. I tested the latest git kernel with your patch 
> today. Unfortunately the system freezes while booting the VM with KVM HV.
> 
> Cheers,
> Christian
> 
> 
Would it be possible to share the console log or boot log of KVM to the
point it freezes?

[Linux PPC] KVM PR and KVM HV do not work if the kernel was compiled with PREEMPT

[Christian Zigotzky]

On 17/02/26 10:03, Shrikanth Hegde wrote:
>
>
> On 2/17/26 2:22 PM, Christian Zigotzky wrote:
>> Hi,
>>
>> Thank you for your patch. I tested the latest git kernel with your 
>> patch today. Unfortunately the system freezes while booting the VM 
>> with KVM HV.
>>
>> Cheers,
>> Christian
>>
>>
> Would it be possible to share the console log or boot log of KVM to the
> point it freezes?

Unfortunately there aren't any error messages.

I also tried it with:

gdb --args qemu-system-ppc64 -M ppce500 -cpu e5500 -m 1024 -kernel 
uImage-7.0-preempt -drive 
format=raw,file=void-live-powerpc-20230317-updated2.img,index=0,if=virtio 
-netdev user,id=mynet0 -device virtio-net,netdev=mynet0 -append "rw 
root=/dev/vda" -device virtio-gpu-pci -device virtio-mouse-pci -device 
virtio-keyboard-pci -enable-kvm -smp 4

and with gdb in the guest:

qemu-system-ppc64 -s -S -M ppce500 -cpu e5500 -m 1024 -kernel 
uImage-7.0-preempt -drive 
format=raw,file=void-live-powerpc-20230317-updated2.img,index=0,if=virtio 
-netdev user,id=mynet0 -device virtio-net,netdev=mynet0 -append "rw 
root=/dev/vda" -device virtio-gpu-pci -device virtio-mouse-pci -device 
virtio-keyboard-pci -enable-kvm -smp 4

The system freezed without any error messages.

-- 
Sent with BrassMonkey 33.9.1 (https://github.com/chzigotzky/Web-Browsers-and-Suites-for-Linux-PPC/releases/tag/BrassMonkey_33.9.1)

Re: [Linux PPC] KVM PR and KVM HV do not work if the kernel was compiled with PREEMPT

[Madhavan Srinivasan]

On 2/17/26 3:14 PM, Christian Zigotzky wrote:
> On 17/02/26 10:03, Shrikanth Hegde wrote:
>>
>>
>> On 2/17/26 2:22 PM, Christian Zigotzky wrote:
>>> Hi,
>>>
>>> Thank you for your patch. I tested the latest git kernel with your 
>>> patch today. Unfortunately the system freezes while booting the VM 
>>> with KVM HV.
>>>
>>> Cheers,
>>> Christian
>>>
>>>
>> Would it be possible to share the console log or boot log of KVM to the
>> point it freezes?
>
> Unfortunately there aren't any error messages.
>
> I also tried it with:
>
> gdb --args qemu-system-ppc64 -M ppce500 -cpu e5500 -m 1024 -kernel 
> uImage-7.0-preempt -drive 
> format=raw,file=void-live-powerpc-20230317-updated2.img,index=0,if=virtio 
> -netdev user,id=mynet0 -device virtio-net,netdev=mynet0 -append "rw 
> root=/dev/vda" -device virtio-gpu-pci -device virtio-mouse-pci -device 
> virtio-keyboard-pci -enable-kvm -smp 4
>
> and with gdb in the guest:
>
> qemu-system-ppc64 -s -S -M ppce500 -cpu e5500 -m 1024 -kernel 
> uImage-7.0-preempt -drive 
> format=raw,file=void-live-powerpc-20230317-updated2.img,index=0,if=virtio 
> -netdev user,id=mynet0 -device virtio-net,netdev=mynet0 -append "rw 
> root=/dev/vda" -device virtio-gpu-pci -device virtio-mouse-pci -device 
> virtio-keyboard-pci -enable-kvm -smp 4
>
> The system freezed without any error messages.
can you please share the config.
I tried kvm-hv in my power8/power9 and seems to boot fine without any 
issues with today's upstream
Maddy

[Linux PPC] KVM PR and KVM HV do not work if the kernel was compiled with PREEMPT

[Christian Zigotzky]

On 17/02/26 11:17 Madhavan Srinivasan wrote:
>
> On 2/17/26 3:14 PM, Christian Zigotzky wrote:
>> On 17/02/26 10:03, Shrikanth Hegde wrote:
>>>
>>>
>>> On 2/17/26 2:22 PM, Christian Zigotzky wrote:
>>>> Hi,
>>>>
>>>> Thank you for your patch. I tested the latest git kernel with your 
>>>> patch today. Unfortunately the system freezes while booting the VM 
>>>> with KVM HV.
>>>>
>>>> Cheers,
>>>> Christian
>>>>
>>>>
>>> Would it be possible to share the console log or boot log of KVM to the
>>> point it freezes?
>>
>> Unfortunately there aren't any error messages.
>>
>> I also tried it with:
>>
>> gdb --args qemu-system-ppc64 -M ppce500 -cpu e5500 -m 1024 -kernel 
>> uImage-7.0-preempt -drive 
>> format=raw,file=void-live-powerpc-20230317-updated2.img,index=0,if=virtio 
>> -netdev user,id=mynet0 -device virtio-net,netdev=mynet0 -append "rw 
>> root=/dev/vda" -device virtio-gpu-pci -device virtio-mouse-pci 
>> -device virtio-keyboard-pci -enable-kvm -smp 4
>>
>> and with gdb in the guest:
>>
>> qemu-system-ppc64 -s -S -M ppce500 -cpu e5500 -m 1024 -kernel 
>> uImage-7.0-preempt -drive 
>> format=raw,file=void-live-powerpc-20230317-updated2.img,index=0,if=virtio 
>> -netdev user,id=mynet0 -device virtio-net,netdev=mynet0 -append "rw 
>> root=/dev/vda" -device virtio-gpu-pci -device virtio-mouse-pci 
>> -device virtio-keyboard-pci -enable-kvm -smp 4
>>
>> The system freezed without any error messages.
> can you please share the config.
> I tried kvm-hv in my power8/power9 and seems to boot fine without any 
> issues with today's upstream
> Maddy
Here are the configs.

With PREEMPT: 
https://github.com/chzigotzky/kernels/blob/d50d259ca63dd2b3b9a9eaabc82e5cc69c8cc9f0/configs/e5500_defconfig

Without PREEMPT: 
https://github.com/chzigotzky/kernels/blob/main/configs/e5500_defconfig

- Christian

Re: [Linux PPC] KVM PR and KVM HV do not work if the kernel was compiled with PREEMPT

[Shrikanth Hegde]

On 2/17/26 3:56 PM, Christian Zigotzky wrote:
> On 17/02/26 11:17 Madhavan Srinivasan wrote:
>>
>> On 2/17/26 3:14 PM, Christian Zigotzky wrote:
>>> On 17/02/26 10:03, Shrikanth Hegde wrote:
>>>>
>>>>
>>>> On 2/17/26 2:22 PM, Christian Zigotzky wrote:
>>>>> Hi,
>>>>>
>>>>> Thank you for your patch. I tested the latest git kernel with your 
>>>>> patch today. Unfortunately the system freezes while booting the VM 
>>>>> with KVM HV.
>>>>>
>>>>> Cheers,
>>>>> Christian
>>>>>
>>>>>
>>>> Would it be possible to share the console log or boot log of KVM to the
>>>> point it freezes?
>>>
>>> Unfortunately there aren't any error messages.
>>>
>>> I also tried it with:
>>>
>>> gdb --args qemu-system-ppc64 -M ppce500 -cpu e5500 -m 1024 -kernel 
>>> uImage-7.0-preempt -drive format=raw,file=void-live-powerpc-20230317- 
>>> updated2.img,index=0,if=virtio -netdev user,id=mynet0 -device virtio- 
>>> net,netdev=mynet0 -append "rw root=/dev/vda" -device virtio-gpu-pci - 
>>> device virtio-mouse-pci -device virtio-keyboard-pci -enable-kvm -smp 4
>>>
>>> and with gdb in the guest:
>>>
>>> qemu-system-ppc64 -s -S -M ppce500 -cpu e5500 -m 1024 -kernel 
>>> uImage-7.0-preempt -drive format=raw,file=void-live-powerpc-20230317- 
>>> updated2.img,index=0,if=virtio -netdev user,id=mynet0 -device virtio- 
>>> net,netdev=mynet0 -append "rw root=/dev/vda" -device virtio-gpu-pci - 
>>> device virtio-mouse-pci -device virtio-keyboard-pci -enable-kvm -smp 4
>>>
>>> The system freezed without any error messages.

Anything on host console?

>> can you please share the config.
>> I tried kvm-hv in my power8/power9 and seems to boot fine without any 
>> issues with today's upstream
>> Maddy
> Here are the configs.
> 
> With PREEMPT: https://github.com/chzigotzky/kernels/blob/ 
> d50d259ca63dd2b3b9a9eaabc82e5cc69c8cc9f0/configs/e5500_defconfig
> 
> Without PREEMPT: https://github.com/chzigotzky/kernels/blob/main/ 
> configs/e5500_defconfig
> 
> - Christian

I looked at the code. there was one more place where cond_resched was 
there.

If possible give the below try.
(Note: Didn;t replicate your issue)

---

diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index 7667563fb9ff..bf0ca49c9915 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -4825,10 +4825,13 @@ static int kvmppc_run_vcpu(struct kvm_vcpu *vcpu)
  		vc->runner = vcpu;
  		if (n_ceded == vc->n_runnable) {
  			kvmppc_vcore_blocked(vc);
-		} else if (need_resched()) {
+		} else if (need_resched() || spin_needbreak(&vc->lock)) {
  			kvmppc_vcore_preempt(vc);
  			/* Let something else run */
-			cond_resched_lock(&vc->lock);
+			spin_unlock(&vc->lock);
+			schedule();
+			//cond_resched_lock(&vc->lock);
+			spin_lock(&vc->lock);
  			if (vc->vcore_state == VCORE_PREEMPT)
  				kvmppc_vcore_end_preempt(vc);
  		} else {
@@ -4901,7 +4904,7 @@ int kvmhv_run_single_vcpu(struct kvm_vcpu *vcpu, 
u64 time_limit,
  	}

  	if (need_resched())
-		cond_resched();
+		schedule();

  	kvmppc_update_vpas(vcpu);

diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 9a89a6d98f97..54963c1d8b58 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -86,7 +86,7 @@ int kvmppc_prepare_to_enter(struct kvm_vcpu *vcpu)
  	while (true) {
  		if (need_resched()) {
  			local_irq_enable();
-			cond_resched();
+			schedule();
  			hard_irq_disable();
  			continue;
  		}

[Linux PPC] KVM PR and KVM HV do not work if the kernel was compiled with PREEMPT

[Christian Zigotzky]

On 17/02/26 12:34, Shrikanth Hegde wrote:
>
>
> On 2/17/26 3:56 PM, Christian Zigotzky wrote:
>> On 17/02/26 11:17 Madhavan Srinivasan wrote:
>>>
>>> On 2/17/26 3:14 PM, Christian Zigotzky wrote:
>>>> On 17/02/26 10:03, Shrikanth Hegde wrote:
>>>>>
>>>>>
>>>>> On 2/17/26 2:22 PM, Christian Zigotzky wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Thank you for your patch. I tested the latest git kernel with 
>>>>>> your patch today. Unfortunately the system freezes while booting 
>>>>>> the VM with KVM HV.
>>>>>>
>>>>>> Cheers,
>>>>>> Christian
>>>>>>
>>>>>>
>>>>> Would it be possible to share the console log or boot log of KVM 
>>>>> to the
>>>>> point it freezes?
>>>>
>>>> Unfortunately there aren't any error messages.
>>>>
>>>> I also tried it with:
>>>>
>>>> gdb --args qemu-system-ppc64 -M ppce500 -cpu e5500 -m 1024 -kernel 
>>>> uImage-7.0-preempt -drive 
>>>> format=raw,file=void-live-powerpc-20230317- 
>>>> updated2.img,index=0,if=virtio -netdev user,id=mynet0 -device 
>>>> virtio- net,netdev=mynet0 -append "rw root=/dev/vda" -device 
>>>> virtio-gpu-pci - device virtio-mouse-pci -device 
>>>> virtio-keyboard-pci -enable-kvm -smp 4
>>>>
>>>> and with gdb in the guest:
>>>>
>>>> qemu-system-ppc64 -s -S -M ppce500 -cpu e5500 -m 1024 -kernel 
>>>> uImage-7.0-preempt -drive 
>>>> format=raw,file=void-live-powerpc-20230317- 
>>>> updated2.img,index=0,if=virtio -netdev user,id=mynet0 -device 
>>>> virtio- net,netdev=mynet0 -append "rw root=/dev/vda" -device 
>>>> virtio-gpu-pci - device virtio-mouse-pci -device 
>>>> virtio-keyboard-pci -enable-kvm -smp 4
>>>>
>>>> The system freezed without any error messages.
>
> Anything on host console?
>
>>> can you please share the config.
>>> I tried kvm-hv in my power8/power9 and seems to boot fine without 
>>> any issues with today's upstream
>>> Maddy
>> Here are the configs.
>>
>> With PREEMPT: https://github.com/chzigotzky/kernels/blob/ 
>> d50d259ca63dd2b3b9a9eaabc82e5cc69c8cc9f0/configs/e5500_defconfig
>>
>> Without PREEMPT: https://github.com/chzigotzky/kernels/blob/main/ 
>> configs/e5500_defconfig
>>
>> - Christian
>
> I looked at the code. there was one more place where cond_resched was 
> there.
>
> If possible give the below try.
> (Note: Didn;t replicate your issue)
>
> ---
>
> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
> index 7667563fb9ff..bf0ca49c9915 100644
> --- a/arch/powerpc/kvm/book3s_hv.c
> +++ b/arch/powerpc/kvm/book3s_hv.c
> @@ -4825,10 +4825,13 @@ static int kvmppc_run_vcpu(struct kvm_vcpu *vcpu)
>          vc->runner = vcpu;
>          if (n_ceded == vc->n_runnable) {
>              kvmppc_vcore_blocked(vc);
> -        } else if (need_resched()) {
> +        } else if (need_resched() || spin_needbreak(&vc->lock)) {
>              kvmppc_vcore_preempt(vc);
>              /* Let something else run */
> -            cond_resched_lock(&vc->lock);
> +            spin_unlock(&vc->lock);
> +            schedule();
> +            //cond_resched_lock(&vc->lock);
> +            spin_lock(&vc->lock);
>              if (vc->vcore_state == VCORE_PREEMPT)
>                  kvmppc_vcore_end_preempt(vc);
>          } else {
> @@ -4901,7 +4904,7 @@ int kvmhv_run_single_vcpu(struct kvm_vcpu *vcpu, 
> u64 time_limit,
>      }
>
>      if (need_resched())
> -        cond_resched();
> +        schedule();
>
>      kvmppc_update_vpas(vcpu);
>
> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
> index 9a89a6d98f97..54963c1d8b58 100644
> --- a/arch/powerpc/kvm/powerpc.c
> +++ b/arch/powerpc/kvm/powerpc.c
> @@ -86,7 +86,7 @@ int kvmppc_prepare_to_enter(struct kvm_vcpu *vcpu)
>      while (true) {
>          if (need_resched()) {
>              local_irq_enable();
> -            cond_resched();
> +            schedule();
>              hard_irq_disable();
>              continue;
>          }
>
Hello Shrikanth,

I tested your patch today. The patched preempt kernel boots on my e5500 
host and in an e5500 VM. Unfortunately my guest and host freeze after 
loading the VirtIO-GPU.

Thanks for your help,

Christian

-- 
Sent with BrassMonkey 33.9.1 (https://github.com/chzigotzky/Web-Browsers-and-Suites-for-Linux-PPC/releases/tag/BrassMonkey_33.9.1)

Re: [Linux PPC] KVM PR and KVM HV do not work if the kernel was compiled with PREEMPT

[Shrikanth Hegde]

Hi Christian.


>> If possible give the below try.
>> (Note: Didn;t replicate your issue)
>>
>> ---
>>
>> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
>> index 7667563fb9ff..bf0ca49c9915 100644
>> --- a/arch/powerpc/kvm/book3s_hv.c
>> +++ b/arch/powerpc/kvm/book3s_hv.c
>> @@ -4825,10 +4825,13 @@ static int kvmppc_run_vcpu(struct kvm_vcpu *vcpu)
>>          vc->runner = vcpu;
>>          if (n_ceded == vc->n_runnable) {
>>              kvmppc_vcore_blocked(vc);
>> -        } else if (need_resched()) {
>> +        } else if (need_resched() || spin_needbreak(&vc->lock)) {
>>              kvmppc_vcore_preempt(vc);
>>              /* Let something else run */
>> -            cond_resched_lock(&vc->lock);
>> +            spin_unlock(&vc->lock);
>> +            schedule();
>> +            //cond_resched_lock(&vc->lock);
>> +            spin_lock(&vc->lock);
>>              if (vc->vcore_state == VCORE_PREEMPT)
>>                  kvmppc_vcore_end_preempt(vc);
>>          } else {
>> @@ -4901,7 +4904,7 @@ int kvmhv_run_single_vcpu(struct kvm_vcpu *vcpu, 
>> u64 time_limit,
>>      }
>>
>>      if (need_resched())
>> -        cond_resched();
>> +        schedule();
>>
>>      kvmppc_update_vpas(vcpu);
>>
>> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
>> index 9a89a6d98f97..54963c1d8b58 100644
>> --- a/arch/powerpc/kvm/powerpc.c
>> +++ b/arch/powerpc/kvm/powerpc.c
>> @@ -86,7 +86,7 @@ int kvmppc_prepare_to_enter(struct kvm_vcpu *vcpu)
>>      while (true) {
>>          if (need_resched()) {
>>              local_irq_enable();
>> -            cond_resched();
>> +            schedule();
>>              hard_irq_disable();
>>              continue;
>>          }
>>
> Hello Shrikanth,
> t
> I tested your patch today. The patched preempt kernel boots on my e5500 
> host and in an e5500 VM. Unfortunately my guest and host freeze after 
> loading the VirtIO-GPU.
> 
> Thanks for your help,
> 
> Christian

Glad it helps you to boot into.

Since you said even host freezes, host maybe crashing.
Do you have the console log when you load the VirtIO-GPU?

[Linux PPC] 7.0-rc1: e500_mmu.c:923:26: error: assignment to 'struct tlbe_priv *' from incompatible pointer type 'struct tlbe_ref *'

[Christian Zigotzky]

Hello,

Compiling issue for e5500 machines for the RC1 of kernel 7.0:

arch/powerpc/kvm/e500_mmu.c: In function 'kvmppc_e500_tlb_init':
arch/powerpc/kvm/e500_mmu.c:923:26: error: assignment to 'struct 
tlbe_priv *' from incompatible pointer type 'struct tlbe_ref *' 
[-Werror=incompatible-pointer-types]
   923 |  vcpu_e500->gtlb_priv[0] = kzalloc_objs(struct tlbe_ref,
       |                          ^
arch/powerpc/kvm/e500_mmu.c:928:26: error: assignment to 'struct 
tlbe_priv *' from incompatible pointer type 'struct tlbe_ref *' 
[-Werror=incompatible-pointer-types]
   928 |  vcpu_e500->gtlb_priv[1] = kzalloc_objs(struct tlbe_ref,

Temporary solution: # CONFIG_VIRTUALIZATION is not set

Please solve this issue.

Thanks,
Christian

Re: [Linux PPC] 7.0-rc1: e500_mmu.c:923:26: error: assignment to 'struct tlbe_priv *' from incompatible pointer type 'struct tlbe_ref *'

[Christophe Leroy (CS GROUP)]

+Kees

Hello,

Le 23/02/2026 à 17:48, Christian Zigotzky a écrit :
> Hello,
> 
> Compiling issue for e5500 machines for the RC1 of kernel 7.0:
> 
> arch/powerpc/kvm/e500_mmu.c: In function 'kvmppc_e500_tlb_init':
> arch/powerpc/kvm/e500_mmu.c:923:26: error: assignment to 'struct 
> tlbe_priv *' from incompatible pointer type 'struct tlbe_ref *' [- 
> Werror=incompatible-pointer-types]
>    923 |  vcpu_e500->gtlb_priv[0] = kzalloc_objs(struct tlbe_ref,
>        |                          ^
> arch/powerpc/kvm/e500_mmu.c:928:26: error: assignment to 'struct 
> tlbe_priv *' from incompatible pointer type 'struct tlbe_ref *' [- 
> Werror=incompatible-pointer-types]
>    928 |  vcpu_e500->gtlb_priv[1] = kzalloc_objs(struct tlbe_ref,
> 
> Temporary solution: # CONFIG_VIRTUALIZATION is not set
> 
> Please solve this issue.
> 

Must be one of:

189f164e573e Convert remaining multi-line kmalloc_obj/flex GFP_KERNEL uses
bf4afc53b77a Convert 'alloc_obj' family to use the new default 
GFP_KERNEL argument
69050f8d6d07 treewide: Replace kmalloc with kmalloc_obj for non-scalar types


Christophe

Re: [Linux PPC] 7.0-rc1: e500_mmu.c:923:26: error: assignment to 'struct tlbe_priv *' from incompatible pointer type 'struct tlbe_ref *'

[Christophe Leroy (CS GROUP)]

Le 23/02/2026 à 19:07, Christophe Leroy (CS GROUP) a écrit :
> +Kees
> 
> Hello,
> 
> Le 23/02/2026 à 17:48, Christian Zigotzky a écrit :
>> Hello,
>>
>> Compiling issue for e5500 machines for the RC1 of kernel 7.0:
>>
>> arch/powerpc/kvm/e500_mmu.c: In function 'kvmppc_e500_tlb_init':
>> arch/powerpc/kvm/e500_mmu.c:923:26: error: assignment to 'struct 
>> tlbe_priv *' from incompatible pointer type 'struct tlbe_ref *' [- 
>> Werror=incompatible-pointer-types]
>>    923 |  vcpu_e500->gtlb_priv[0] = kzalloc_objs(struct tlbe_ref,
>>        |                          ^
>> arch/powerpc/kvm/e500_mmu.c:928:26: error: assignment to 'struct 
>> tlbe_priv *' from incompatible pointer type 'struct tlbe_ref *' [- 
>> Werror=incompatible-pointer-types]
>>    928 |  vcpu_e500->gtlb_priv[1] = kzalloc_objs(struct tlbe_ref,
>>
>> Temporary solution: # CONFIG_VIRTUALIZATION is not set
>>
>> Please solve this issue.
>>
> 
> Must be one of:
> 
> 189f164e573e Convert remaining multi-line kmalloc_obj/flex GFP_KERNEL uses
> bf4afc53b77a Convert 'alloc_obj' family to use the new default 
> GFP_KERNEL argument
> 69050f8d6d07 treewide: Replace kmalloc with kmalloc_obj for non-scalar 
> types
> 

Can you try following change:

diff --git a/arch/powerpc/kvm/e500_mmu.c b/arch/powerpc/kvm/e500_mmu.c
index 48580c85f23b..75ed1496ead5 100644
--- a/arch/powerpc/kvm/e500_mmu.c
+++ b/arch/powerpc/kvm/e500_mmu.c
@@ -920,12 +920,12 @@ int kvmppc_e500_tlb_init(struct kvmppc_vcpu_e500 
*vcpu_e500)
  	vcpu_e500->gtlb_offset[0] = 0;
  	vcpu_e500->gtlb_offset[1] = KVM_E500_TLB0_SIZE;

-	vcpu_e500->gtlb_priv[0] = kzalloc_objs(struct tlbe_ref,
+	vcpu_e500->gtlb_priv[0] = kzalloc_objs(struct tlbe_priv,
  					       vcpu_e500->gtlb_params[0].entries);
  	if (!vcpu_e500->gtlb_priv[0])
  		goto free_vcpu;

-	vcpu_e500->gtlb_priv[1] = kzalloc_objs(struct tlbe_ref,
+	vcpu_e500->gtlb_priv[1] = kzalloc_objs(struct tlbe_priv,
  					       vcpu_e500->gtlb_params[1].entries);
  	if (!vcpu_e500->gtlb_priv[1])
  		goto free_vcpu;

---
Christophe

Re: [Linux PPC] 7.0-rc1: e500_mmu.c:923:26: error: assignment to 'struct tlbe_priv *' from incompatible pointer type 'struct tlbe_ref *'

[Kees Cook]

On Mon, Feb 23, 2026 at 08:38:29PM +0100, Christophe Leroy (CS GROUP) wrote:
> 
> 
> Le 23/02/2026 à 19:07, Christophe Leroy (CS GROUP) a écrit :
> > +Kees
> > 
> > Hello,
> > 
> > Le 23/02/2026 à 17:48, Christian Zigotzky a écrit :
> > > Hello,
> > > 
> > > Compiling issue for e5500 machines for the RC1 of kernel 7.0:
> > > 
> > > arch/powerpc/kvm/e500_mmu.c: In function 'kvmppc_e500_tlb_init':
> > > arch/powerpc/kvm/e500_mmu.c:923:26: error: assignment to 'struct
> > > tlbe_priv *' from incompatible pointer type 'struct tlbe_ref *' [-
> > > Werror=incompatible-pointer-types]
> > >    923 |  vcpu_e500->gtlb_priv[0] = kzalloc_objs(struct tlbe_ref,
> > >        |                          ^
> > > arch/powerpc/kvm/e500_mmu.c:928:26: error: assignment to 'struct
> > > tlbe_priv *' from incompatible pointer type 'struct tlbe_ref *' [-
> > > Werror=incompatible-pointer-types]
> > >    928 |  vcpu_e500->gtlb_priv[1] = kzalloc_objs(struct tlbe_ref,
> > > 
> > > Temporary solution: # CONFIG_VIRTUALIZATION is not set
> > > 
> > > Please solve this issue.
> > > 
> > 
> > Must be one of:
> > 
> > 189f164e573e Convert remaining multi-line kmalloc_obj/flex GFP_KERNEL uses
> > bf4afc53b77a Convert 'alloc_obj' family to use the new default
> > GFP_KERNEL argument
> > 69050f8d6d07 treewide: Replace kmalloc with kmalloc_obj for non-scalar
> > types
> > 
> 
> Can you try following change:
> 
> diff --git a/arch/powerpc/kvm/e500_mmu.c b/arch/powerpc/kvm/e500_mmu.c
> index 48580c85f23b..75ed1496ead5 100644
> --- a/arch/powerpc/kvm/e500_mmu.c
> +++ b/arch/powerpc/kvm/e500_mmu.c
> @@ -920,12 +920,12 @@ int kvmppc_e500_tlb_init(struct kvmppc_vcpu_e500
> *vcpu_e500)
>  	vcpu_e500->gtlb_offset[0] = 0;
>  	vcpu_e500->gtlb_offset[1] = KVM_E500_TLB0_SIZE;
> 
> -	vcpu_e500->gtlb_priv[0] = kzalloc_objs(struct tlbe_ref,
> +	vcpu_e500->gtlb_priv[0] = kzalloc_objs(struct tlbe_priv,
>  					       vcpu_e500->gtlb_params[0].entries);
>  	if (!vcpu_e500->gtlb_priv[0])
>  		goto free_vcpu;
> 
> -	vcpu_e500->gtlb_priv[1] = kzalloc_objs(struct tlbe_ref,
> +	vcpu_e500->gtlb_priv[1] = kzalloc_objs(struct tlbe_priv,
>  					       vcpu_e500->gtlb_params[1].entries);
>  	if (!vcpu_e500->gtlb_priv[1])
>  		goto free_vcpu;

That looks like the correct fix to me. The old type was the correct size,
but was just the wrong type. Sorry I missed it when doing my tree-wide
multi-arch builds! What build target (or Kconfig) was needed to reach
this code?

Fixes: 69050f8d6d07 ("treewide: Replace kmalloc with kmalloc_obj for non-scalar types")
Reviewed-by: Kees Cook <kees@kernel.org>

Thanks!

-- 
Kees Cook

Re: [Linux PPC] 7.0-rc1: e500_mmu.c:923:26: error: assignment to 'struct tlbe_priv *' from incompatible pointer type 'struct tlbe_ref *'

[Christian Zigotzky]

On 23/02/26 23:40, Kees Cook wrote:
> On Mon, Feb 23, 2026 at 08:38:29PM +0100, Christophe Leroy (CS GROUP) wrote:
>>
>> Le 23/02/2026 à 19:07, Christophe Leroy (CS GROUP) a écrit :
>>> +Kees
>>>
>>> Hello,
>>>
>>> Le 23/02/2026 à 17:48, Christian Zigotzky a écrit :
>>>> Hello,
>>>>
>>>> Compiling issue for e5500 machines for the RC1 of kernel 7.0:
>>>>
>>>> arch/powerpc/kvm/e500_mmu.c: In function 'kvmppc_e500_tlb_init':
>>>> arch/powerpc/kvm/e500_mmu.c:923:26: error: assignment to 'struct
>>>> tlbe_priv *' from incompatible pointer type 'struct tlbe_ref *' [-
>>>> Werror=incompatible-pointer-types]
>>>>     923 |  vcpu_e500->gtlb_priv[0] = kzalloc_objs(struct tlbe_ref,
>>>>         |                          ^
>>>> arch/powerpc/kvm/e500_mmu.c:928:26: error: assignment to 'struct
>>>> tlbe_priv *' from incompatible pointer type 'struct tlbe_ref *' [-
>>>> Werror=incompatible-pointer-types]
>>>>     928 |  vcpu_e500->gtlb_priv[1] = kzalloc_objs(struct tlbe_ref,
>>>>
>>>> Temporary solution: # CONFIG_VIRTUALIZATION is not set
>>>>
>>>> Please solve this issue.
>>>>
>>> Must be one of:
>>>
>>> 189f164e573e Convert remaining multi-line kmalloc_obj/flex GFP_KERNEL uses
>>> bf4afc53b77a Convert 'alloc_obj' family to use the new default
>>> GFP_KERNEL argument
>>> 69050f8d6d07 treewide: Replace kmalloc with kmalloc_obj for non-scalar
>>> types
>>>
>> Can you try following change:
>>
>> diff --git a/arch/powerpc/kvm/e500_mmu.c b/arch/powerpc/kvm/e500_mmu.c
>> index 48580c85f23b..75ed1496ead5 100644
>> --- a/arch/powerpc/kvm/e500_mmu.c
>> +++ b/arch/powerpc/kvm/e500_mmu.c
>> @@ -920,12 +920,12 @@ int kvmppc_e500_tlb_init(struct kvmppc_vcpu_e500
>> *vcpu_e500)
>>   	vcpu_e500->gtlb_offset[0] = 0;
>>   	vcpu_e500->gtlb_offset[1] = KVM_E500_TLB0_SIZE;
>>
>> -	vcpu_e500->gtlb_priv[0] = kzalloc_objs(struct tlbe_ref,
>> +	vcpu_e500->gtlb_priv[0] = kzalloc_objs(struct tlbe_priv,
>>   					       vcpu_e500->gtlb_params[0].entries);
>>   	if (!vcpu_e500->gtlb_priv[0])
>>   		goto free_vcpu;
>>
>> -	vcpu_e500->gtlb_priv[1] = kzalloc_objs(struct tlbe_ref,
>> +	vcpu_e500->gtlb_priv[1] = kzalloc_objs(struct tlbe_priv,
>>   					       vcpu_e500->gtlb_params[1].entries);
>>   	if (!vcpu_e500->gtlb_priv[1])
>>   		goto free_vcpu;
> That looks like the correct fix to me. The old type was the correct size,
> but was just the wrong type. Sorry I missed it when doing my tree-wide
> multi-arch builds! What build target (or Kconfig) was needed to reach
> this code?
>
> Fixes: 69050f8d6d07 ("treewide: Replace kmalloc with kmalloc_obj for non-scalar types")
> Reviewed-by: Kees Cook <kees@kernel.org>
>
> Thanks!
>

It works. Thank you. Tested-by: Christian Zigotzky <chzigotzky@xenosoft.de>

-- 
Sent with BrassMonkey 33.9.1 (https://github.com/chzigotzky/Web-Browsers-and-Suites-for-Linux-PPC/releases/tag/BrassMonkey_33.9.1)

Re: [Linux PPC] 7.0-rc1: e500_mmu.c:923:26: error: assignment to 'struct tlbe_priv *' from incompatible pointer type 'struct tlbe_ref *'

[Christophe Leroy (CS GROUP)]

Le 23/02/2026 à 23:40, Kees Cook a écrit :
> On Mon, Feb 23, 2026 at 08:38:29PM +0100, Christophe Leroy (CS GROUP) wrote:
>>
>>
>> Le 23/02/2026 à 19:07, Christophe Leroy (CS GROUP) a écrit :
>>> +Kees
>>>
>>> Hello,
>>>
>>> Le 23/02/2026 à 17:48, Christian Zigotzky a écrit :
>>>> Hello,
>>>>
>>>> Compiling issue for e5500 machines for the RC1 of kernel 7.0:
>>>>
>>>> arch/powerpc/kvm/e500_mmu.c: In function 'kvmppc_e500_tlb_init':
>>>> arch/powerpc/kvm/e500_mmu.c:923:26: error: assignment to 'struct
>>>> tlbe_priv *' from incompatible pointer type 'struct tlbe_ref *' [-
>>>> Werror=incompatible-pointer-types]
>>>>     923 |  vcpu_e500->gtlb_priv[0] = kzalloc_objs(struct tlbe_ref,
>>>>         |                          ^
>>>> arch/powerpc/kvm/e500_mmu.c:928:26: error: assignment to 'struct
>>>> tlbe_priv *' from incompatible pointer type 'struct tlbe_ref *' [-
>>>> Werror=incompatible-pointer-types]
>>>>     928 |  vcpu_e500->gtlb_priv[1] = kzalloc_objs(struct tlbe_ref,
>>>>
>>>> Temporary solution: # CONFIG_VIRTUALIZATION is not set
>>>>
>>>> Please solve this issue.
>>>>
>>>
>>> Must be one of:
>>>
>>> 189f164e573e Convert remaining multi-line kmalloc_obj/flex GFP_KERNEL uses
>>> bf4afc53b77a Convert 'alloc_obj' family to use the new default
>>> GFP_KERNEL argument
>>> 69050f8d6d07 treewide: Replace kmalloc with kmalloc_obj for non-scalar
>>> types
>>>
>>
>> Can you try following change:
>>
>> diff --git a/arch/powerpc/kvm/e500_mmu.c b/arch/powerpc/kvm/e500_mmu.c
>> index 48580c85f23b..75ed1496ead5 100644
>> --- a/arch/powerpc/kvm/e500_mmu.c
>> +++ b/arch/powerpc/kvm/e500_mmu.c
>> @@ -920,12 +920,12 @@ int kvmppc_e500_tlb_init(struct kvmppc_vcpu_e500
>> *vcpu_e500)
>>   	vcpu_e500->gtlb_offset[0] = 0;
>>   	vcpu_e500->gtlb_offset[1] = KVM_E500_TLB0_SIZE;
>>
>> -	vcpu_e500->gtlb_priv[0] = kzalloc_objs(struct tlbe_ref,
>> +	vcpu_e500->gtlb_priv[0] = kzalloc_objs(struct tlbe_priv,
>>   					       vcpu_e500->gtlb_params[0].entries);
>>   	if (!vcpu_e500->gtlb_priv[0])
>>   		goto free_vcpu;
>>
>> -	vcpu_e500->gtlb_priv[1] = kzalloc_objs(struct tlbe_ref,
>> +	vcpu_e500->gtlb_priv[1] = kzalloc_objs(struct tlbe_priv,
>>   					       vcpu_e500->gtlb_params[1].entries);
>>   	if (!vcpu_e500->gtlb_priv[1])
>>   		goto free_vcpu;
> 
> That looks like the correct fix to me. The old type was the correct size,
> but was just the wrong type. Sorry I missed it when doing my tree-wide
> multi-arch builds! What build target (or Kconfig) was needed to reach
> this code?

I used ppc64e_defconfig + CONFIG_VIRTUALIZATION=y
+ CONFIG_KVM_E500MC=y


> 
> Fixes: 69050f8d6d07 ("treewide: Replace kmalloc with kmalloc_obj for non-scalar types")
> Reviewed-by: Kees Cook <kees@kernel.org>
> 
> Thanks!
> 

[Linux PPC] Disable PREEMPT

[Christian Zigotzky]

Hello,

We were previously able to disable PREEMPT in the kernel configuration, 
but the latest kernels now enable it by default and it is no longer 
possible to disable it.

Is it possible to let us decide whether to activate PREEMPT or not?

Currently we use the following revert patch for our non-preempt kernels.

--- a/kernel/Kconfig.preempt    2026-02-14 10:06:32.000000000 +0000
+++ b/kernel/Kconfig.preempt    2026-02-08 21:03:27.000000000 +0000
@@ -16,13 +16,11 @@ config ARCH_HAS_PREEMPT_LAZY

  choice
      prompt "Preemption Model"
-    default PREEMPT_LAZY if ARCH_HAS_PREEMPT_LAZY
      default PREEMPT_NONE

  config PREEMPT_NONE
      bool "No Forced Preemption (Server)"
      depends on !PREEMPT_RT
-    depends on ARCH_NO_PREEMPT
      select PREEMPT_NONE_BUILD if !PREEMPT_DYNAMIC
      help
        This is the traditional Linux preemption model, geared towards
@@ -37,7 +35,6 @@ config PREEMPT_NONE

  config PREEMPT_VOLUNTARY
      bool "Voluntary Kernel Preemption (Desktop)"
-    depends on !ARCH_HAS_PREEMPT_LAZY
      depends on !ARCH_NO_PREEMPT
      depends on !PREEMPT_RT
      select PREEMPT_VOLUNTARY_BUILD if !PREEMPT_DYNAMIC

---

Thanks in advance,

Christian

Re: [Linux PPC] Disable PREEMPT

[Shrikanth Hegde]

Hi Christian.


Is this sent as a patch or just a reply to the thread?

If it is sent as patch, Please follow these guidelines.
https://docs.kernel.org/process/submitting-patches.html

On 2/25/26 11:24 AM, Christian Zigotzky wrote:
> Hello,
> 
> We were previously able to disable PREEMPT in the kernel configuration, 
> but the latest kernels now enable it by default and it is no longer 
> possible to disable it.
> 
> Is it possible to let us decide whether to activate PREEMPT or not?
> 
> Currently we use the following revert patch for our non-preempt kernels.
> 
> --- a/kernel/Kconfig.preempt    2026-02-14 10:06:32.000000000 +0000
> +++ b/kernel/Kconfig.preempt    2026-02-08 21:03:27.000000000 +0000
> @@ -16,13 +16,11 @@ config ARCH_HAS_PREEMPT_LAZY
> 
>   choice
>       prompt "Preemption Model"
> -    default PREEMPT_LAZY if ARCH_HAS_PREEMPT_LAZY
>       default PREEMPT_NONE
> 
>   config PREEMPT_NONE
>       bool "No Forced Preemption (Server)"
>       depends on !PREEMPT_RT
> -    depends on ARCH_NO_PREEMPT
>       select PREEMPT_NONE_BUILD if !PREEMPT_DYNAMIC
>       help
>         This is the traditional Linux preemption model, geared towards
> @@ -37,7 +35,6 @@ config PREEMPT_NONE
> 
>   config PREEMPT_VOLUNTARY
>       bool "Voluntary Kernel Preemption (Desktop)"
> -    depends on !ARCH_HAS_PREEMPT_LAZY
>       depends on !ARCH_NO_PREEMPT
>       depends on !PREEMPT_RT
>       select PREEMPT_VOLUNTARY_BUILD if !PREEMPT_DYNAMIC
> 

I would instead fix any issue we have in PREEMPT FULL/LAZY rather than falling back to
old methods.

btw, did the previous patch sent, which you said helps you to boot, can you confirm
it did help you? If yes, i can send it as patch, since cond_resched if called from boot cpu
might be stuck in the loop forever.

IIRC, after boot, you had some driver causing crash. If so, share backtrace of the crash?
If you don't use that driver, is the guest stable?

Re: [Linux PPC] Disable PREEMPT

[Christophe Leroy (CS GROUP)]

+Peter

Hi Christian,

Le 25/02/2026 à 06:54, Christian Zigotzky a écrit :
> Hello,
> 
> We were previously able to disable PREEMPT in the kernel configuration, 
> but the latest kernels now enable it by default and it is no longer 
> possible to disable it.
> 
> Is it possible to let us decide whether to activate PREEMPT or not?

Can you give more details on why you want to be able to deactivate PREEMPT ?

Read https://github.com/torvalds/linux/commit/7dadeaa6e851e


> 
> Currently we use the following revert patch for our non-preempt kernels.
> 
> --- a/kernel/Kconfig.preempt    2026-02-14 10:06:32.000000000 +0000
> +++ b/kernel/Kconfig.preempt    2026-02-08 21:03:27.000000000 +0000
> @@ -16,13 +16,11 @@ config ARCH_HAS_PREEMPT_LAZY
> 
>   choice
>       prompt "Preemption Model"
> -    default PREEMPT_LAZY if ARCH_HAS_PREEMPT_LAZY
>       default PREEMPT_NONE
> 
>   config PREEMPT_NONE
>       bool "No Forced Preemption (Server)"
>       depends on !PREEMPT_RT
> -    depends on ARCH_NO_PREEMPT
>       select PREEMPT_NONE_BUILD if !PREEMPT_DYNAMIC
>       help
>         This is the traditional Linux preemption model, geared towards
> @@ -37,7 +35,6 @@ config PREEMPT_NONE
> 
>   config PREEMPT_VOLUNTARY
>       bool "Voluntary Kernel Preemption (Desktop)"
> -    depends on !ARCH_HAS_PREEMPT_LAZY
>       depends on !ARCH_NO_PREEMPT
>       depends on !PREEMPT_RT
>       select PREEMPT_VOLUNTARY_BUILD if !PREEMPT_DYNAMIC
> 
> ---
> 
> Thanks in advance,
> 
> Christian
> 

Re: [Linux PPC] Disable PREEMPT

[Peter Zijlstra]

On Wed, Feb 25, 2026 at 08:16:46AM +0100, Christophe Leroy (CS GROUP) wrote:
> +Peter
> 
> Hi Christian,
> 
> Le 25/02/2026 à 06:54, Christian Zigotzky a écrit :
> > Hello,
> > 
> > We were previously able to disable PREEMPT in the kernel configuration,
> > but the latest kernels now enable it by default and it is no longer
> > possible to disable it.
> > 
> > Is it possible to let us decide whether to activate PREEMPT or not?
> 
> Can you give more details on why you want to be able to deactivate PREEMPT ?
> 
> Read https://github.com/torvalds/linux/commit/7dadeaa6e851e

Right. So to recap, there are and will be more cases where relying on
preemption is mandatory. 

The typical example is huge page memset/memcpy. Currently that is done
in single page chunks with cond_resched() in between, but it is much
better (and faster) to do a full huge page in one go.

Combine this with the endless stream of mostly random cond_resched()
placements due to $reason, and it is all a bit of a maintenance
nightmare.

I suppose the question is; why do you think you require non-preempt
kernels?

[Linux PPC] Disable PREEMPT

[Christian Zigotzky]

On 25/02/26 08:16, Christophe Leroy (CS GROUP) wrote:
> +Peter
>
> Hi Christian,
>
> Le 25/02/2026 à 06:54, Christian Zigotzky a écrit :
>> Hello,
>>
>> We were previously able to disable PREEMPT in the kernel 
>> configuration, but the latest kernels now enable it by default and it 
>> is no longer possible to disable it.
>>
>> Is it possible to let us decide whether to activate PREEMPT or not?
>
> Can you give more details on why you want to be able to deactivate 
> PREEMPT ?
>
> Read https://github.com/torvalds/linux/commit/7dadeaa6e851e
I use PREEMPT_NONE kernels on my Linux PPC servers. (Without desktop)
>
>
>>
>> Currently we use the following revert patch for our non-preempt kernels.
>>
>> --- a/kernel/Kconfig.preempt    2026-02-14 10:06:32.000000000 +0000
>> +++ b/kernel/Kconfig.preempt    2026-02-08 21:03:27.000000000 +0000
>> @@ -16,13 +16,11 @@ config ARCH_HAS_PREEMPT_LAZY
>>
>>   choice
>>       prompt "Preemption Model"
>> -    default PREEMPT_LAZY if ARCH_HAS_PREEMPT_LAZY
>>       default PREEMPT_NONE
>>
>>   config PREEMPT_NONE
>>       bool "No Forced Preemption (Server)"
>>       depends on !PREEMPT_RT
>> -    depends on ARCH_NO_PREEMPT
>>       select PREEMPT_NONE_BUILD if !PREEMPT_DYNAMIC
>>       help
>>         This is the traditional Linux preemption model, geared towards
>> @@ -37,7 +35,6 @@ config PREEMPT_NONE
>>
>>   config PREEMPT_VOLUNTARY
>>       bool "Voluntary Kernel Preemption (Desktop)"
>> -    depends on !ARCH_HAS_PREEMPT_LAZY
>>       depends on !ARCH_NO_PREEMPT
>>       depends on !PREEMPT_RT
>>       select PREEMPT_VOLUNTARY_BUILD if !PREEMPT_DYNAMIC
>>
>> ---
>>
>> Thanks in advance,
>>
>> Christian
>>
>


-- 
Sent with BrassMonkey 33.9.1 (https://github.com/chzigotzky/Web-Browsers-and-Suites-for-Linux-PPC/releases/tag/BrassMonkey_33.9.1)

Re: [Linux PPC] Disable PREEMPT

[Christophe Leroy (CS GROUP)]

Hi Christian,

Le 26/02/2026 à 06:37, Christian Zigotzky a écrit :
> On 25/02/26 08:16, Christophe Leroy (CS GROUP) wrote:
>> +Peter
>>
>> Hi Christian,
>>
>> Le 25/02/2026 à 06:54, Christian Zigotzky a écrit :
>>> Hello,
>>>
>>> We were previously able to disable PREEMPT in the kernel 
>>> configuration, but the latest kernels now enable it by default and it 
>>> is no longer possible to disable it.
>>>
>>> Is it possible to let us decide whether to activate PREEMPT or not?
>>
>> Can you give more details on why you want to be able to deactivate 
>> PREEMPT ?
>>
>> Read https://eur01.safelinks.protection.outlook.com/? 
>> url=https%3A%2F%2Fgithub.com%2Ftorvalds%2Flinux%2Fcommit%2F7dadeaa6e851e&data=05%7C02%7Cchristophe.leroy2%40cs-soprasteria.com%7C7006c8b4b98c4315a7e508de74f9388a%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639076810956939768%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=6xLB%2FOVSkmgZRamaBM9zaxm%2FUTk9ssf4409QJdiXkDg%3D&reserved=0
> I use PREEMPT_NONE kernels on my Linux PPC servers. (Without desktop)

You are doing that today because it is possible. Tomorrow it will not be 
possible anymore, for the reasons explained by Peter.

My question was not to know what you are doing but why, and why you 
think you still need PREEMPT_NONE and why the modern PREEMPT_LAZY is not 
good enough for you.

Christophe

>>
>>
>>>
>>> Currently we use the following revert patch for our non-preempt kernels.
>>>
>>> --- a/kernel/Kconfig.preempt    2026-02-14 10:06:32.000000000 +0000
>>> +++ b/kernel/Kconfig.preempt    2026-02-08 21:03:27.000000000 +0000
>>> @@ -16,13 +16,11 @@ config ARCH_HAS_PREEMPT_LAZY
>>>
>>>   choice
>>>       prompt "Preemption Model"
>>> -    default PREEMPT_LAZY if ARCH_HAS_PREEMPT_LAZY
>>>       default PREEMPT_NONE
>>>
>>>   config PREEMPT_NONE
>>>       bool "No Forced Preemption (Server)"
>>>       depends on !PREEMPT_RT
>>> -    depends on ARCH_NO_PREEMPT
>>>       select PREEMPT_NONE_BUILD if !PREEMPT_DYNAMIC
>>>       help
>>>         This is the traditional Linux preemption model, geared towards
>>> @@ -37,7 +35,6 @@ config PREEMPT_NONE
>>>
>>>   config PREEMPT_VOLUNTARY
>>>       bool "Voluntary Kernel Preemption (Desktop)"
>>> -    depends on !ARCH_HAS_PREEMPT_LAZY
>>>       depends on !ARCH_NO_PREEMPT
>>>       depends on !PREEMPT_RT
>>>       select PREEMPT_VOLUNTARY_BUILD if !PREEMPT_DYNAMIC
>>>
>>> ---
>>>
>>> Thanks in advance,
>>>
>>> Christian
>>>
>>
> 
>