On 4/29/24 12:18, Christian Borntraeger wrote:
Am 04.03.24 um 16:37 schrieb Eric Farman:
On Mon, 2024-03-04 at 09:44 +0100, Christian Borntraeger wrote:
Am 04.03.24 um 09:35 schrieb David Hildenbrand:
On 01.03.24 21:43, Eric Farman wrote:
It's possible that SIE exits for work that the host needs to
perform
rather than something that is intended for the guest.
A Linux guest will ignore this intercept code since there is
nothing
for it to do, but a more robust solution would rewind the PSW
back to
the SIE instruction. This will transparently resume the guest
once
the host completes its work, without the guest needing to process
what is effectively a NOP and re-issue SIE itself.
I recall that 0-intercepts are valid by the architecture. Further,
I recall that there were some rather tricky corner cases where
avoiding 0-intercepts would not be that easy.
Any chance you recall any details of those corner cases? I can try to
chase some of them down.
Now, it's been a while ago, and maybe I misremember. SoI'm trusting
people with access to documentation can review this.
Yes, 0-intercepts are allowed, and this also happens when LPAR has an
exit.
From an offline conversation I'd had some months back:
"""
The arch does allow ICODE=0 to be stored, but it's supposed to happen
only upon a host interruption -- in which case the old PSW is supposed
to point back at the SIE, to resume guest execution if the host should
LPSW oldPSW.
"""
Just re-read the architecture again and I agree, the SIE instruction should
be nullified. So we should go forward with this somehow.
Eric, can you maybe add this to devel for CI coverage so that we see if there
are corner cases? Maybe also try to do some performance things (how many IPIs
can we get in guest2 when a guest3 is running and how many IPIs are possible
in a guest3).
This patch has had contact with the CI for quite a while and I'm
gathering patches.
Is this an ack now?
