On Thu, Dec 15, 2011 at 05:49:19PM +0100, Christian Borntraeger wrote: > 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)
Yeah, I had a major braino.. > 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? No, you did not. However, I still think it's wrong to have an early exit if the vma is not writable. Since the guest can set the guest change bit, but it is is not possible with this interface, but I can see now that the purpose was to avoid an overindication of the change bit. oh well... -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
