From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christian Borntraeger Subject: Re: [PATCH RFC 0/1] KVM: ioctl for reading/writing guest memory Date: Tue, 03 Feb 2015 14:05:32 +0100 Message-ID: <54D0C79C.409@de.ibm.com> References: <1422965498-11500-1-git-send-email-thuth@linux.vnet.ibm.com> <54D0C64D.8090400@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: agraf@suse.de, cornelia.huck@de.ibm.com To: Paolo Bonzini , Thomas Huth , kvm@vger.kernel.org, qemu-devel@nongnu.org Return-path: Received: from e06smtp16.uk.ibm.com ([195.75.94.112]:60292 "EHLO e06smtp16.uk.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755707AbbBCNFh (ORCPT ); Tue, 3 Feb 2015 08:05:37 -0500 Received: from /spool/local by e06smtp16.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 3 Feb 2015 13:05:35 -0000 Received: from b06cxnps3074.portsmouth.uk.ibm.com (d06relay09.portsmouth.uk.ibm.com [9.149.109.194]) by d06dlp01.portsmouth.uk.ibm.com (Postfix) with ESMTP id 5C19B17D8066 for ; Tue, 3 Feb 2015 13:05:41 +0000 (GMT) Received: from d06av05.portsmouth.uk.ibm.com (d06av05.portsmouth.uk.ibm.com [9.149.37.229]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t13D5XAq64159804 for ; Tue, 3 Feb 2015 13:05:33 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 t13D5WrC030944 for ; Tue, 3 Feb 2015 06:05:33 -0700 In-Reply-To: <54D0C64D.8090400@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Am 03.02.2015 um 13:59 schrieb Paolo Bonzini: > > > On 03/02/2015 13:11, Thomas Huth wrote: >> The userspace (QEMU) then can simply call this ioctl when it wants >> to read or write from/to virtual guest memory. Then kernel then takes >> the IPTE-lock, walks the MMU table of the guest to find out the >> physical address that corresponds to the virtual address, copies >> the requested amount of bytes from the userspace buffer to guest >> memory or the other way round, and finally frees the IPTE-lock again. >> >> Does that sound like a viable solution (IMHO it does ;-))? Or should >> I maybe try to pursue another approach? > > It looks feasible to me as well. Yes, we discussed this internally a lot and things are really tricky. The ipte lock could be exported to userspace, but we might also need to handle storage keys (and key protection) in an atomic fashion, so this really looks like the only safe way. I guess we will give it some more testing, but to me it looks like a good candidate for kvm/next after 3.20-rc1. Christian