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@xxxxxxxxxxxxxxx >> 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@xxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
