On Mon, 2024-04-29 at 12:18 +0200, 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? Sure thing. > 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). > Fair enough. I'll see if I can come up with something and report back here.
