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 09:26:11 +0100 Message-ID: <54D1D7A3.8010508@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> 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 e06smtp13.uk.ibm.com ([195.75.94.109]:56980 "EHLO e06smtp13.uk.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932870AbbBDI0S (ORCPT ); Wed, 4 Feb 2015 03:26:18 -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 08:26:16 -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 3B59817D805F for ; Wed, 4 Feb 2015 08:26:21 +0000 (GMT) Received: from d06av10.portsmouth.uk.ibm.com (d06av10.portsmouth.uk.ibm.com [9.149.37.251]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t148QDS06423036 for ; Wed, 4 Feb 2015 08:26:13 GMT Received: from d06av10.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av10.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t148QCIe020490 for ; Wed, 4 Feb 2015 01:26:13 -0700 In-Reply-To: <54D0E7B8.2060501@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Am 03.02.2015 um 16:22 schrieb Paolo Bonzini: > > > On 03/02/2015 16:16, Thomas Huth wrote: >> Actually, I'd prefer to keep the "virtual" in the defines for the type >> of operation below: When it comes to s390 storage keys, we likely might >> need some calls for reading and writing to physical memory, too. Then >> we could simply extend this ioctl instead of inventing a new one. Rereading that. Shall we replace "virtual" with "logical"? That is what is used architecturally when we mean "do whatever is appropriate right now" That can boil down to virtual via DAT, virtual via access register mode, real if DAT is off... and if fact your kernel implementation does that. > > Can you explain why it is necessary to read/write physical addresses > from user space? In the case of QEMU, I'm worried that you would have > to invent your own memory read/write APIs that are different from > everything else. > > On real s390 zPCI, does bus-master DMA update storage keys? the classic channel I/O does set the storage key change/reference and also triggers errors in the storage key protection value mismatches. The PCI IOTA structure does contain a storage key value for accesses, so I assume its the same here, but I dont know for sure. 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. We can then add a ccw later on to set a different key if we ever need that. > >>> Not really true, as you don't check it. So "It is not used by KVM with >>> the currently defined set of flags" is a better explanation. >> >> ok ... and maybe add "should be set to zero" ? > > If you don't check it, it is misleading to document this. > > Paolo > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >