Re: [Qemu-devel] [PATCH RFC 1/1] KVM: s390: Add MEMOP ioctl for reading/writing guest memory

[Christian Borntraeger <borntraeger@de.ibm.com>]

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, too. Then
>> we could simply extend this ioctl instead of inventing a new one.

Rereading that. Shall we replace "virtual" with "logical"? That is what is
used architecturally when we mean "do whatever is appropriate right now"
That can boil down to virtual via DAT, virtual via access register mode, 
real if DAT is off... and if fact your kernel implementation does that.


> 
> Can you explain why it is necessary to read/write physical addresses
> from user space?  In the case of QEMU, I'm worried that you would have
> to invent your own memory read/write APIs that are different from
> everything else.
> 
> On real s390 zPCI, does bus-master DMA update storage keys?

the classic channel I/O does set the storage key change/reference and
also triggers errors in the storage key protection value mismatches.

The PCI IOTA structure does contain a storage key value for accesses,
so I assume its the same here, but I dont know for sure.

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 anyway.
We can then add a ccw later on to set a different key if we ever need
that.


> 
>>> Not really true, as you don't check it.  So "It is not used by KVM with
>>> the currently defined set of flags" is a better explanation.
>>
>> ok ... and maybe add "should be set to zero" ?
> 
> If you don't check it, it is misleading to document this.
> 
> Paolo
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>