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 <mtosatti@xxxxxxxxxx> > > > > On Mon, Mar 16, 2015 at 09:51:40AM +0100, Christian Borntraeger wrote: > > > From: Thomas Huth <thuth@xxxxxxxxxxxxxxxxxx> > > > > > > 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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
