On 14.02.2018 11:42, David Hildenbrand wrote: > >>>>> 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) > b, this is an implicit RCP bypass (same goes for fc=1 r3 entries). This might be even independent of the SKF if I'm not mistaken.
Attachment:
signature.asc
Description: OpenPGP digital signature
