From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christian Borntraeger Subject: Re: [PATCH RFC 1/1] KVM: s390: Add MEMOP ioctl for reading/writing guest memory Date: Wed, 04 Feb 2015 12:25:04 +0100 Message-ID: <54D20190.9060201@de.ibm.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: cornelia.huck@de.ibm.com, qemu-devel@nongnu.org, kvm@vger.kernel.org, agraf@suse.de To: Paolo Bonzini , Thomas Huth Return-path: Received: from e06smtp12.uk.ibm.com ([195.75.94.108]:51974 "EHLO e06smtp12.uk.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751232AbbBDLZK (ORCPT ); Wed, 4 Feb 2015 06:25:10 -0500 Received: from /spool/local by e06smtp12.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 4 Feb 2015 11:25:08 -0000 Received: from b06cxnps3074.portsmouth.uk.ibm.com (d06relay09.portsmouth.uk.ibm.com [9.149.109.194]) by d06dlp03.portsmouth.uk.ibm.com (Postfix) with ESMTP id 4FC921B08078 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 b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t14BP6an51118320 for ; Wed, 4 Feb 2015 11:25:06 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 t14BP5Lp014445 for ; Wed, 4 Feb 2015 06:25:06 -0500 In-Reply-To: <54D1F6E2.1040201@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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