On 15/12/11 17:11, Heiko Carstens wrote: > Why again is this needed? Or put in other words: what prevents a guest to > change the storage key contents via sske of a page that is mapped read-only > into the guest address space? > As far as I can see: nothing. Interestingly I could -in theory- do some nice > stuff like: > - map a file from a read-only filesystem (which doesn't have a writepage > aops function) into guest address space > - let the guest set the change bit in the storage key of a page that belongs > to that file mapping via sske > - watch the fun that happens when the host tries to write the page back Huh? The guest itself can neither set the dirty bit of the real storage key nor set the dirty bit the host change bit of the pgste via guest SSKE. The transition 0->1 will only be done in the guest change bit of the pgste. (Otherwise we would not have a separate guest/host view of change/referenced) This interface here is for userspace (to change the guest storage key on behalf of the guest, e.g. for life guest relocation). Since we might have to touch the real storage key and this is host code millicode will not protect us from doing stupid things like it does for guest code, we better check before we touch the real storage key. Or did I misread your question? Christian -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
