>>>> That's interesting, because the SIE can now suddenly work on these >>>> PGSTEs, e.g. not leading to intercepts on certain events (like setting >>>> storage keys). >>>> >>>> How is that intended to be handled? I assume we would somehow have to >>>> forbid the SIE from making use of the PGSTE. But that involves clearing >>>> certain interception controls, which might be problematic. >>> >>> Well, cmma is disabled and storage keys should only be a problem, when >>> the pte is invalid without the pgste lock, which should never be the >>> case for split pmds. >>> >> >> Are you sure? Because the SIE would suddenly stark working on guest >> storage keys stored in the PGSTE if I am not mistaking? So I would >> assume that there would have to be some kind of a sync. >> >> But I don't have any documentation at hand, so i can't tell :) >> > > The pgste lock is that sync and as the gmap is the only way to get to > the pte, we don't have any ptes invalid without the lock. Also > set_guest_storage_keys will find a (userspace) pmd and do a hardware > sske, like it is supposed to. What happens according to the documentation in the following cases: The HW has the storage-key facility enabled and a SKEY operation (ISKE, RRBE, SSKE) hits a huge page: a) Generates an intercept b) Uses the real machine storage key (as there are no pgste) -- Thanks, David / dhildenb
