On Wed, 04 Feb 2015 09:26:11 +0100
Christian Borntraeger borntrae...@de.ibm.com wrote:
the classic channel I/O does set the storage key change/reference and
also triggers errors in the storage key protection value mismatches.
Just a bit of background for the benefit of innocent bystanders:
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,
Am 04.02.2015 um 11:39 schrieb Paolo Bonzini:
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
Am 04.02.2015 um 12:42 schrieb Paolo Bonzini:
On 04/02/2015 12:25, Christian Borntraeger wrote:
Whenever vhost or qemu or a finished aio request wrote content into a
virtio buffer, the HW has set the storage key for that physical page,
which makes it automatically dirty/referenced in the
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
On Wed, 04 Feb 2015 09:26:11 +0100
Christian Borntraeger borntrae...@de.ibm.com 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
On 04/02/2015 12:25, Christian Borntraeger wrote:
Whenever vhost or qemu or a finished aio request wrote content into a
virtio buffer, the HW has set the storage key for that physical page,
which makes it automatically dirty/referenced in the guest visible
storage key.
Ah, I knew the
On Tue, 03 Feb 2015 16:22:32 +0100
Paolo Bonzini pbonz...@redhat.com wrote:
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
On 03/02/2015 13:11, Thomas Huth wrote:
On s390, we've got to make sure to hold the IPTE lock while accessing
virtual memory. So let's add an ioctl for reading and writing virtual
memory to provide this feature for userspace, too.
Signed-off-by: Thomas Huth th...@linux.vnet.ibm.com
On Tue, 03 Feb 2015 14:04:43 +0100
Paolo Bonzini pbonz...@redhat.com wrote:
On 03/02/2015 13:11, Thomas Huth wrote:
On s390, we've got to make sure to hold the IPTE lock while accessing
virtual memory. So let's add an ioctl for reading and writing virtual
memory to provide this feature for
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
On s390, we've got to make sure to hold the IPTE lock while accessing
virtual memory. So let's add an ioctl for reading and writing virtual
memory to provide this feature for userspace, too.
Signed-off-by: Thomas Huth th...@linux.vnet.ibm.com
Reviewed-by: Dominik Dingel din...@linux.vnet.ibm.com
12 matches
Mail list logo
