KVM: s390: Add MEMOP ioctls for reading/writing guest memory
A message that is not in the archive (sent off-list or not yet received): 20150319090759.6acae229@gondolin
Quoted 9 lines
Date: Wed, 18 Mar 2015 21:23:48 -0300
From: Marcelo Tosatti <[email protected]>Quoted 5 lines · Christian Borntraeger
From: Thomas Huth <[email protected]>
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.
...
Quoted 3 lines
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.
Thomas
Quoted 23 lines · Thomas Huth
Quoted 9 lines
Date: Wed, 18 Mar 2015 21:23:48 -0300
From: Marcelo Tosatti <[email protected]>Quoted 5 lines · Christian Borntraeger
From: Thomas Huth <[email protected]>
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.
...
Quoted 3 lines
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
Quoted 8 lines
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.