From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christian Borntraeger Subject: Re: [patch 10/12] [PATCH] kvm-s390: storage key interface Date: Thu, 15 Dec 2011 17:49:19 +0100 Message-ID: <4EEA250F.9030703@de.ibm.com> References: <20111214122347.275452567@de.ibm.com> <20111214123127.030416104@de.ibm.com> <4EE9CBB3.3000707@de.ibm.com> <20111215161106.GA2742@osiris.boeblingen.de.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Carsten Otte , Avi Kivity , Marcelo Tossati , borntrae@linux.vnet.ibm.com, heicars2@linux.vnet.ibm.com, mschwid2@linux.vnet.ibm.com, huckc@linux.vnet.ibm.com, KVM , Joachim von Buttlar , Jens Freimann , agraf@suse.de To: Heiko Carstens Return-path: Received: from e06smtp13.uk.ibm.com ([195.75.94.109]:47449 "EHLO e06smtp13.uk.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756284Ab1LOQtw (ORCPT ); Thu, 15 Dec 2011 11:49:52 -0500 Received: from /spool/local by e06smtp13.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 15 Dec 2011 16:49:51 -0000 Received: from d06av11.portsmouth.uk.ibm.com (d06av11.portsmouth.uk.ibm.com [9.149.37.252]) by d06nrmr1806.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id pBFGnhtx2756732 for ; Thu, 15 Dec 2011 16:49:43 GMT Received: from d06av11.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av11.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id pBFGng6e016519 for ; Thu, 15 Dec 2011 09:49:43 -0700 In-Reply-To: <20111215161106.GA2742@osiris.boeblingen.de.ibm.com> Sender: kvm-owner@vger.kernel.org List-ID: 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