From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42222) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIytC-0002vM-6m for qemu-devel@nongnu.org; Wed, 04 Feb 2015 07:17:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YIyt8-0004cd-Rw for qemu-devel@nongnu.org; Wed, 04 Feb 2015 07:17:02 -0500 Received: from e06smtp13.uk.ibm.com ([195.75.94.109]:35727) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIyt8-0004cW-HZ for qemu-devel@nongnu.org; Wed, 04 Feb 2015 07:16:58 -0500 Received: from /spool/local by e06smtp13.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 4 Feb 2015 12:16:57 -0000 Received: from b06cxnps4076.portsmouth.uk.ibm.com (d06relay13.portsmouth.uk.ibm.com [9.149.109.198]) by d06dlp02.portsmouth.uk.ibm.com (Postfix) with ESMTP id C8B152190046 for ; Wed, 4 Feb 2015 12:16:50 +0000 (GMT) Received: from d06av05.portsmouth.uk.ibm.com (d06av05.portsmouth.uk.ibm.com [9.149.37.229]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t14CGs6w66453548 for ; Wed, 4 Feb 2015 12:16:54 GMT Received: from d06av05.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av05.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t14CGspY007990 for ; Wed, 4 Feb 2015 05:16:54 -0700 Message-ID: <54D20DB5.7010205@de.ibm.com> Date: Wed, 04 Feb 2015 13:16:53 +0100 From: Christian Borntraeger MIME-Version: 1.0 References: <1422965498-11500-1-git-send-email-thuth@linux.vnet.ibm.com> <1422965498-11500-2-git-send-email-thuth@linux.vnet.ibm.com> <54D0C76B.70603@redhat.com> <20150203161601.1319f7ef@oc7435384737.ibm.com> <54D0E7B8.2060501@redhat.com> <54D1D7A3.8010508@de.ibm.com> <54D1F6E2.1040201@redhat.com> <54D20190.9060201@de.ibm.com> <54D205B7.7080109@redhat.com> In-Reply-To: <54D205B7.7080109@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH RFC 1/1] KVM: s390: Add MEMOP ioctl for reading/writing guest memory List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , Thomas Huth Cc: cornelia.huck@de.ibm.com, qemu-devel@nongnu.org, kvm@vger.kernel.org, agraf@suse.de Am 04.02.2015 um 12:42 schrieb Paolo Bonzini: > > > On 04/02/2015 12:25, Christian Borntraeger wrote: >> Whenever vhost or qemu or a finished aio request wrote content into a >> virtio buffer, the HW has set the storage key for that physical page, >> which makes it automatically dirty/referenced in the guest visible >> storage key. > > Ah, I knew the storage keys were per-physical page, but I wasn't sure if > they were separate for the host and the guest. That's obvious now. Just something on top: the storage key is per physical page. Just once. It contains C/R/ACC/F (change, reference, access key, fetch protection) But: there is also the pgste page table extension. That is used to separate both by doing logically ORs. The host and millicode will do the right shifting copying to keep both values separate, but when the physical storage key gets dirty, the host and the guest view is now "changed==yes" > > Can we detect non-zero storage key in emulated zPCI requests, and fail > the request somehow? Not right now. Even the kernel KVM module does not do this for emulated instructions (as Linux has always key 0). Somewhen we might want to add that capability, but its obviously not trivial for I/O like things. It would get easier if we avoid VFIO etc and just had used the hardware support, though. but as far as I can see this is not an option in QEMU. Christian