From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57100) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIyLs-0004vd-PJ for qemu-devel@nongnu.org; Wed, 04 Feb 2015 06:42:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YIyLn-0006KM-N2 for qemu-devel@nongnu.org; Wed, 04 Feb 2015 06:42:36 -0500 Received: from e06smtp17.uk.ibm.com ([195.75.94.113]:59813) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIy51-0008C6-Eh for qemu-devel@nongnu.org; Wed, 04 Feb 2015 06:25:11 -0500 Received: from /spool/local by e06smtp17.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 4 Feb 2015 11:25:09 -0000 Received: from b06cxnps4076.portsmouth.uk.ibm.com (d06relay13.portsmouth.uk.ibm.com [9.149.109.198]) by d06dlp01.portsmouth.uk.ibm.com (Postfix) with ESMTP id D2FFA17D8062 for ; Wed, 4 Feb 2015 11:25:13 +0000 (GMT) Received: from d06av07.portsmouth.uk.ibm.com (d06av07.portsmouth.uk.ibm.com [9.149.37.248]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t14BP5DK55312484 for ; Wed, 4 Feb 2015 11:25:05 GMT Received: from d06av07.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av07.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t14BP5Lj014445 for ; Wed, 4 Feb 2015 06:25:05 -0500 Message-ID: <54D20190.9060201@de.ibm.com> Date: Wed, 04 Feb 2015 12:25:04 +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> In-Reply-To: <54D1F6E2.1040201@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 11:39 schrieb Paolo Bonzini: >> Conny: >> I am asking myself, if we should explicitly add a comment in the >> virtio-ccw spec, that all accesses are assumed to be with key 0 and >> thus never cause key protection. The change/reference bit is set >> by the underlying I/O or memory copy anyway. > > Can you explain the last sentence? :) 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. For completeness sake: Now, if the guest does not use the storage key, but instead the new fault based software dirty tracking, it wont notice the change bit. The guest I/O itself when finished will mark the struct page as Dirty, just like on x86. Makes sense? Christian