From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41701) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIxMy-0004MH-Kn for qemu-devel@nongnu.org; Wed, 04 Feb 2015 05:39:41 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YIxMu-00086J-9H for qemu-devel@nongnu.org; Wed, 04 Feb 2015 05:39:40 -0500 Received: from mail-we0-x235.google.com ([2a00:1450:400c:c03::235]:60821) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIxMt-00085N-Ve for qemu-devel@nongnu.org; Wed, 04 Feb 2015 05:39:36 -0500 Received: by mail-we0-f181.google.com with SMTP id k48so872368wev.12 for ; Wed, 04 Feb 2015 02:39:35 -0800 (PST) Sender: Paolo Bonzini Message-ID: <54D1F6E2.1040201@redhat.com> Date: Wed, 04 Feb 2015 11:39:30 +0100 From: Paolo Bonzini 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> In-Reply-To: <54D1D7A3.8010508@de.ibm.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: Christian Borntraeger , Thomas Huth Cc: cornelia.huck@de.ibm.com, qemu-devel@nongnu.org, kvm@vger.kernel.org, agraf@suse.de On 04/02/2015 09:26, Christian Borntraeger wrote: > 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. That makes sense. >> 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. Emulating that in QEMU would be very hard. Every DMA read/write would have to go through a bounce buffer, but QEMU block device models for example try hard to read from host disk directly into guest memory. > 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? :) Paolo > 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 >> > > -- > 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 >