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

[Paolo Bonzini <pbonzini@redhat.com>]

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 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.

That makes sense.

>> 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.

Emulating that in QEMU would be very hard.  Every DMA read/write would
have to go through a bounce buffer, but QEMU block device models for
example try hard to read from host disk directly into guest memory.

> 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.

Can you explain the last sentence? :)

Paolo

> 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
>>
> 
> --
> 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
>