[PATCH] KVM: s390: vsie: retry SIE when unable to get vsie_page

[PATCH] KVM: s390: vsie: retry SIE when unable to get vsie_page

[Eric Farman]

SIE may exit because of pending host work, such as handling an interrupt,
in which case VSIE rewinds the guest PSW such that it is transparently
resumed (see Fixes tag). There is still one scenario where those conditions
are not present, but that the VSIE processor returns with effectively rc=0,
resulting in additional (and unnecessary) guest work to be performed.

For this case, rewind the guest PSW as we do in the other non-error exits.

Fixes: 33a729a1770b ("KVM: s390: vsie: retry SIE instruction on host intercepts")
Signed-off-by: Eric Farman <farman@linux.ibm.com>
---
 arch/s390/kvm/vsie.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/s390/kvm/vsie.c b/arch/s390/kvm/vsie.c
index b526621d2a1b..b8064c6a4b57 100644
--- a/arch/s390/kvm/vsie.c
+++ b/arch/s390/kvm/vsie.c
@@ -1498,11 +1498,13 @@ int kvm_s390_handle_vsie(struct kvm_vcpu *vcpu)
 	}
 
 	vsie_page = get_vsie_page(vcpu->kvm, scb_addr);
-	if (IS_ERR(vsie_page))
+	if (IS_ERR(vsie_page)) {
 		return PTR_ERR(vsie_page);
-	else if (!vsie_page)
+	} else if (!vsie_page) {
 		/* double use of sie control block - simply do nothing */
+		kvm_s390_rewind_psw(vcpu, 4);
 		return 0;
+	}
 
 	rc = pin_scb(vcpu, vsie_page, scb_addr);
 	if (rc)
-- 
2.51.0

Re: [PATCH] KVM: s390: vsie: retry SIE when unable to get vsie_page

[Janosch Frank]

On 12/17/25 04:01, Eric Farman wrote:
> SIE may exit because of pending host work, such as handling an interrupt,
> in which case VSIE rewinds the guest PSW such that it is transparently
> resumed (see Fixes tag). There is still one scenario where those conditions
> are not present, but that the VSIE processor returns with effectively rc=0,
> resulting in additional (and unnecessary) guest work to be performed.
> 
> For this case, rewind the guest PSW as we do in the other non-error exits.
> 
> Fixes: 33a729a1770b ("KVM: s390: vsie: retry SIE instruction on host intercepts")
> Signed-off-by: Eric Farman <farman@linux.ibm.com>

This is purely cosmetic to have all instances look the same, right?

Re: [PATCH] KVM: s390: vsie: retry SIE when unable to get vsie_page

[Eric Farman]

On Mon, 2026-01-05 at 13:41 +0100, Janosch Frank wrote:
> On 12/17/25 04:01, Eric Farman wrote:
> > SIE may exit because of pending host work, such as handling an interrupt,
> > in which case VSIE rewinds the guest PSW such that it is transparently
> > resumed (see Fixes tag). There is still one scenario where those conditions
> > are not present, but that the VSIE processor returns with effectively rc=0,
> > resulting in additional (and unnecessary) guest work to be performed.
> > 
> > For this case, rewind the guest PSW as we do in the other non-error exits.
> > 
> > Fixes: 33a729a1770b ("KVM: s390: vsie: retry SIE instruction on host intercepts")
> > Signed-off-by: Eric Farman <farman@linux.ibm.com>
> 
> This is purely cosmetic to have all instances look the same, right?

Nope, I can take this path with particularly high I/O loads on the system, which ends up
(incorrectly) sending the intercept to the guest.

Re: [PATCH] KVM: s390: vsie: retry SIE when unable to get vsie_page

[Christoph Schlameuss]

On Wed Dec 17, 2025 at 4:01 AM CET, Eric Farman wrote:
> SIE may exit because of pending host work, such as handling an interrupt,
> in which case VSIE rewinds the guest PSW such that it is transparently
> resumed (see Fixes tag). There is still one scenario where those conditions
> are not present, but that the VSIE processor returns with effectively rc=0,
> resulting in additional (and unnecessary) guest work to be performed.
>
> For this case, rewind the guest PSW as we do in the other non-error exits.
>
> Fixes: 33a729a1770b ("KVM: s390: vsie: retry SIE instruction on host intercepts")
> Signed-off-by: Eric Farman <farman@linux.ibm.com>

LGTM

Reviewed-by: Christoph Schlameuss <schlameuss@linux.ibm.com>

Re: [PATCH] KVM: s390: vsie: retry SIE when unable to get vsie_page

[Claudio Imbrenda]

On Mon, 05 Jan 2026 10:46:53 -0500
Eric Farman <farman@linux.ibm.com> wrote:

> On Mon, 2026-01-05 at 13:41 +0100, Janosch Frank wrote:
> > On 12/17/25 04:01, Eric Farman wrote:  
> > > SIE may exit because of pending host work, such as handling an interrupt,
> > > in which case VSIE rewinds the guest PSW such that it is transparently
> > > resumed (see Fixes tag). There is still one scenario where those conditions

can you add a few words to (very briefly) explain what the scenario is?

> > > are not present, but that the VSIE processor returns with effectively rc=0,
> > > resulting in additional (and unnecessary) guest work to be performed.
> > > 
> > > For this case, rewind the guest PSW as we do in the other non-error exits.
> > > 
> > > Fixes: 33a729a1770b ("KVM: s390: vsie: retry SIE instruction on host intercepts")
> > > Signed-off-by: Eric Farman <farman@linux.ibm.com>  
> > 
> > This is purely cosmetic to have all instances look the same, right?  
> 
> Nope, I can take this path with particularly high I/O loads on the system, which ends up
> (incorrectly) sending the intercept to the guest.

this is a good candidate for the explanation I mentioned above :)


(the patch itself looks fine)

Re: [PATCH] KVM: s390: vsie: retry SIE when unable to get vsie_page

[Eric Farman]

On Wed, 2026-01-14 at 10:50 +0100, Claudio Imbrenda wrote:
> On Mon, 05 Jan 2026 10:46:53 -0500
> Eric Farman <farman@linux.ibm.com> wrote:
> 
> > On Mon, 2026-01-05 at 13:41 +0100, Janosch Frank wrote:
> > > On 12/17/25 04:01, Eric Farman wrote:  
> > > > SIE may exit because of pending host work, such as handling an interrupt,
> > > > in which case VSIE rewinds the guest PSW such that it is transparently
> > > > resumed (see Fixes tag). There is still one scenario where those conditions
> 
> can you add a few words to (very briefly) explain what the scenario is?

Maybe if this paragraph were rewritten this way, instead?

--8<--
SIE may exit because of pending host work, such as handling an interrupt,
in which case VSIE rewinds the guest PSW such that it is transparently
resumed (see Fixes tag). Unlike those other places that return rc=0, this
return leaves the guest PSW in place, requiring the guest to handle an
intercept that was meant to be serviced by the host. This showed up when
testing heavy I/O workloads, when multiple vcpus attempted to dispatch the
same SIE block and incurred failures inserting them into the radix tree.
-->8--

@Janosch, if that ends up being okay, can you update the patch or do you want me to send a v2?

> 
> > > > are not present, but that the VSIE processor returns with effectively rc=0,
> > > > resulting in additional (and unnecessary) guest work to be performed.
> > > > 
> > > > For this case, rewind the guest PSW as we do in the other non-error exits.
> > > > 
> > > > Fixes: 33a729a1770b ("KVM: s390: vsie: retry SIE instruction on host intercepts")
> > > > Signed-off-by: Eric Farman <farman@linux.ibm.com>  
> > > 
> > > This is purely cosmetic to have all instances look the same, right?  
> > 
> > Nope, I can take this path with particularly high I/O loads on the system, which ends up
> > (incorrectly) sending the intercept to the guest.
> 
> this is a good candidate for the explanation I mentioned above :)
> 
> 
> (the patch itself looks fine)

Re: [PATCH] KVM: s390: vsie: retry SIE when unable to get vsie_page

[Eric Farman]

On Thu, 2026-01-15 at 16:17 -0500, Eric Farman wrote:
> On Wed, 2026-01-14 at 10:50 +0100, Claudio Imbrenda wrote:
> > On Mon, 05 Jan 2026 10:46:53 -0500
> > Eric Farman <farman@linux.ibm.com> wrote:
> > 
> > > On Mon, 2026-01-05 at 13:41 +0100, Janosch Frank wrote:
> > > > On 12/17/25 04:01, Eric Farman wrote:  
> > > > > SIE may exit because of pending host work, such as handling an interrupt,
> > > > > in which case VSIE rewinds the guest PSW such that it is transparently
> > > > > resumed (see Fixes tag). There is still one scenario where those conditions
> > 
> > can you add a few words to (very briefly) explain what the scenario is?
> 
> Maybe if this paragraph were rewritten this way, instead?
> 
> --8<--
> SIE may exit because of pending host work, such as handling an interrupt,
> in which case VSIE rewinds the guest PSW such that it is transparently
> resumed (see Fixes tag). Unlike those other places that return rc=0, this
> return leaves the guest PSW in place, requiring the guest to handle an
> intercept that was meant to be serviced by the host. This showed up when
> testing heavy I/O workloads, when multiple vcpus attempted to dispatch the
> same SIE block and incurred failures inserting them into the radix tree.
> -->8--

Spoke to Claudio offline, and he suggested the following edit to the above:

--8<--
SIE may exit because of pending host work, such as handling an interrupt,
in which case VSIE rewinds the guest PSW such that it is transparently
resumed (see Fixes tag). Unlike those other places that return rc=0, this
return leaves the guest PSW in place, requiring the guest to handle a
spurious intercept. This showed up when testing heavy I/O workloads,
when multiple vcpus attempted to dispatch the same SIE block and incurred
failures inserting them into the radix tree.
-->8--

> 
> @Janosch, if that ends up being okay, can you update the patch or do you want me to send a v2?
> 
> > 
> > > > > are not present, but that the VSIE processor returns with effectively rc=0,
> > > > > resulting in additional (and unnecessary) guest work to be performed.
> > > > > 
> > > > > For this case, rewind the guest PSW as we do in the other non-error exits.
> > > > > 
> > > > > Fixes: 33a729a1770b ("KVM: s390: vsie: retry SIE instruction on host intercepts")
> > > > > Signed-off-by: Eric Farman <farman@linux.ibm.com>  
> > > > 
> > > > This is purely cosmetic to have all instances look the same, right?  
> > > 
> > > Nope, I can take this path with particularly high I/O loads on the system, which ends up
> > > (incorrectly) sending the intercept to the guest.
> > 
> > this is a good candidate for the explanation I mentioned above :)
> > 
> > 
> > (the patch itself looks fine)

Re: [PATCH] KVM: s390: vsie: retry SIE when unable to get vsie_page

[Claudio Imbrenda]

On Fri, 16 Jan 2026 10:45:22 -0500
Eric Farman <farman@linux.ibm.com> wrote:

> On Thu, 2026-01-15 at 16:17 -0500, Eric Farman wrote:
> > On Wed, 2026-01-14 at 10:50 +0100, Claudio Imbrenda wrote:  
> > > On Mon, 05 Jan 2026 10:46:53 -0500
> > > Eric Farman <farman@linux.ibm.com> wrote:
> > >   
> > > > On Mon, 2026-01-05 at 13:41 +0100, Janosch Frank wrote:  
> > > > > On 12/17/25 04:01, Eric Farman wrote:    
> > > > > > SIE may exit because of pending host work, such as handling an interrupt,
> > > > > > in which case VSIE rewinds the guest PSW such that it is transparently
> > > > > > resumed (see Fixes tag). There is still one scenario where those conditions  
> > > 
> > > can you add a few words to (very briefly) explain what the scenario is?  
> > 
> > Maybe if this paragraph were rewritten this way, instead?
> > 
> > --8<--
> > SIE may exit because of pending host work, such as handling an interrupt,
> > in which case VSIE rewinds the guest PSW such that it is transparently
> > resumed (see Fixes tag). Unlike those other places that return rc=0, this
> > return leaves the guest PSW in place, requiring the guest to handle an
> > intercept that was meant to be serviced by the host. This showed up when
> > testing heavy I/O workloads, when multiple vcpus attempted to dispatch the
> > same SIE block and incurred failures inserting them into the radix tree.  
> > -->8--  
> 
> Spoke to Claudio offline, and he suggested the following edit to the above:
> 
> --8<--
> SIE may exit because of pending host work, such as handling an interrupt,
> in which case VSIE rewinds the guest PSW such that it is transparently
> resumed (see Fixes tag). Unlike those other places that return rc=0, this
> return leaves the guest PSW in place, requiring the guest to handle a
> spurious intercept. This showed up when testing heavy I/O workloads,
> when multiple vcpus attempted to dispatch the same SIE block and incurred
> failures inserting them into the radix tree.
> -->8--  

with the above text:

Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>


> 
> > 
> > @Janosch, if that ends up being okay, can you update the patch or do you want me to send a v2?
> >   
> > >   
> > > > > > are not present, but that the VSIE processor returns with effectively rc=0,
> > > > > > resulting in additional (and unnecessary) guest work to be performed.
> > > > > > 
> > > > > > For this case, rewind the guest PSW as we do in the other non-error exits.
> > > > > > 
> > > > > > Fixes: 33a729a1770b ("KVM: s390: vsie: retry SIE instruction on host intercepts")
> > > > > > Signed-off-by: Eric Farman <farman@linux.ibm.com>    
> > > > > 
> > > > > This is purely cosmetic to have all instances look the same, right?    
> > > > 
> > > > Nope, I can take this path with particularly high I/O loads on the system, which ends up
> > > > (incorrectly) sending the intercept to the guest.  
> > > 
> > > this is a good candidate for the explanation I mentioned above :)
> > > 
> > > 
> > > (the patch itself looks fine)  

Re: [PATCH] KVM: s390: vsie: retry SIE when unable to get vsie_page

[Janosch Frank]

On 1/16/26 16:45, Eric Farman wrote:
> On Thu, 2026-01-15 at 16:17 -0500, Eric Farman wrote:
>> On Wed, 2026-01-14 at 10:50 +0100, Claudio Imbrenda wrote:
>>> On Mon, 05 Jan 2026 10:46:53 -0500
>>> Eric Farman <farman@linux.ibm.com> wrote:
>>>
>>>> On Mon, 2026-01-05 at 13:41 +0100, Janosch Frank wrote:
>>>>> On 12/17/25 04:01, Eric Farman wrote:
>>>>>> SIE may exit because of pending host work, such as handling an interrupt,
>>>>>> in which case VSIE rewinds the guest PSW such that it is transparently
>>>>>> resumed (see Fixes tag). There is still one scenario where those conditions
>>>
>>> can you add a few words to (very briefly) explain what the scenario is?
>>
>> Maybe if this paragraph were rewritten this way, instead?
>>
>> --8<--
>> SIE may exit because of pending host work, such as handling an interrupt,
>> in which case VSIE rewinds the guest PSW such that it is transparently
>> resumed (see Fixes tag). Unlike those other places that return rc=0, this
>> return leaves the guest PSW in place, requiring the guest to handle an
>> intercept that was meant to be serviced by the host. This showed up when
>> testing heavy I/O workloads, when multiple vcpus attempted to dispatch the
>> same SIE block and incurred failures inserting them into the radix tree.
>> -->8--
> 
> Spoke to Claudio offline, and he suggested the following edit to the above:
> 
> --8<--
> SIE may exit because of pending host work, such as handling an interrupt,
> in which case VSIE rewinds the guest PSW such that it is transparently
> resumed (see Fixes tag). Unlike those other places that return rc=0, this
> return leaves the guest PSW in place, requiring the guest to handle a
> spurious intercept. This showed up when testing heavy I/O workloads,
> when multiple vcpus attempted to dispatch the same SIE block and incurred
> failures inserting them into the radix tree.
> -->8--
> 
>>
>> @Janosch, if that ends up being okay, can you update the patch or do you want me to send a v2?

I can fix that up.

Re: [PATCH] KVM: s390: vsie: retry SIE when unable to get vsie_page

[Eric Farman]

On Mon, 2026-01-19 at 15:49 +0100, Janosch Frank wrote:
> On 1/16/26 16:45, Eric Farman wrote:
> > On Thu, 2026-01-15 at 16:17 -0500, Eric Farman wrote:
> > > On Wed, 2026-01-14 at 10:50 +0100, Claudio Imbrenda wrote:
> > > > On Mon, 05 Jan 2026 10:46:53 -0500
> > > > Eric Farman <farman@linux.ibm.com> wrote:
> > > > 
> > > > > On Mon, 2026-01-05 at 13:41 +0100, Janosch Frank wrote:
> > > > > > On 12/17/25 04:01, Eric Farman wrote:
> > > > > > > SIE may exit because of pending host work, such as handling an interrupt,
> > > > > > > in which case VSIE rewinds the guest PSW such that it is transparently
> > > > > > > resumed (see Fixes tag). There is still one scenario where those conditions
> > > > 
> > > > can you add a few words to (very briefly) explain what the scenario is?
> > > 
> > > Maybe if this paragraph were rewritten this way, instead?
> > > 
> > > --8<--
> > > SIE may exit because of pending host work, such as handling an interrupt,
> > > in which case VSIE rewinds the guest PSW such that it is transparently
> > > resumed (see Fixes tag). Unlike those other places that return rc=0, this
> > > return leaves the guest PSW in place, requiring the guest to handle an
> > > intercept that was meant to be serviced by the host. This showed up when
> > > testing heavy I/O workloads, when multiple vcpus attempted to dispatch the
> > > same SIE block and incurred failures inserting them into the radix tree.
> > > -->8--
> > 
> > Spoke to Claudio offline, and he suggested the following edit to the above:
> > 
> > --8<--
> > SIE may exit because of pending host work, such as handling an interrupt,
> > in which case VSIE rewinds the guest PSW such that it is transparently
> > resumed (see Fixes tag). Unlike those other places that return rc=0, this
> > return leaves the guest PSW in place, requiring the guest to handle a
> > spurious intercept. This showed up when testing heavy I/O workloads,
> > when multiple vcpus attempted to dispatch the same SIE block and incurred
> > failures inserting them into the radix tree.
> > -->8--
> > 
> > > 
> > > @Janosch, if that ends up being okay, can you update the patch or do you want me to send a v2?
> 
> I can fix that up.

Great, thank you!