From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Tosatti Subject: Re: [PATCH/RFC 4/9] KVM: s390: Add MEMOP ioctls for reading/writing guest memory Date: Thu, 19 Mar 2015 20:24:26 -0300 Message-ID: <20150319232426.GA11359@amt.cnet> References: <20150319090759.6acae229@gondolin> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kvm@vger.kernel.org, Christian Borntraeger , Cornelia Huck , Alexander Graf , Jens Freimann To: Thomas Huth Return-path: Received: from mx1.redhat.com ([209.132.183.28]:58951 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751958AbbCSXYz (ORCPT ); Thu, 19 Mar 2015 19:24:55 -0400 Content-Disposition: inline In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On Thu, Mar 19, 2015 at 02:15:18PM +0100, Thomas Huth wrote: > > Date: Wed, 18 Mar 2015 21:23:48 -0300 > > From: Marcelo Tosatti > > > > On Mon, Mar 16, 2015 at 09:51:40AM +0100, Christian Borntraeger wrote: > > > From: Thomas Huth > > > > > > On s390, we've got to make sure to hold the IPTE lock while accessing > > > logical memory. So let's add an ioctl for reading and writing logical > > > memory to provide this feature for userspace, too. > ... > > > > What i was wondering is why you can't translate the address > > in the kernel and let userspace perform the actual read/write? > > The idea here is to protect the read/write access with the ipte-lock, too. > That way, the whole address translation _and_ the read/write access are > protected together against invalidate-page-table operations from other > CPUs, > so the whole memory access looks atomic for other VCPUs. And since we do > not > want to expose the ipte lock directly to user space, both has to be done > in the kernel. > We already had a long internal discussion about this in our team, and > indeed, if the ipte-lock would be the only "problem" that we face on s390, > we might also come up with a solution where the memory read/write access > is done in userspace instead. However, for full architecture compliance, > we later have got to support the so-called "storage keys" during memory > accesses, too, and this can hardly be done accurately and safely from > userspace. So I'm afraid, it's somewhat ugly that we've got to provide an > ioctl here to read/write the guest memory, but it's the only feasible > solution that I could think of. I see, thanks.