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

[Cornelia Huck]

On Wed, 04 Feb 2015 09:26:11 +0100
Christian Borntraeger <address@hidden> 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:

When classic channel I/O is initiated, the caller provides a so-called
operation request block (orb) which references the actual channel
program it wants to start. In this same orb, the caller also provides
the storage key to be used for all memory fetches (either of the
individual channel commands or of the memory they reference).

qemu interpretation of channel commands currently ignores all of this.

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

I don't think we need to clarify anything for the normal channel
commands used by virtio: They are treated as any other channel command
wrt key protection; and the lack of key checking is a feature of qemu,
not of the spec.

For the memory used for the virtqueues, I agree that we should clarify
that we assume key 0. I'm not sure whether there's a case for extending
this in the future, but who knows.

I'll probably have to open an issue against the virtio spec for this.