On Wed, 2022-10-05 at 08:32 +0200, Thomas Huth wrote: > On 30/09/2022 23.07, Janis Schoetterl-Glausch wrote: > > User space can use the MEM_OP ioctl to make storage key checked reads > > and writes to the guest, however, it has no way of performing atomic, > > key checked, accesses to the guest. > > Extend the MEM_OP ioctl in order to allow for this, by adding a cmpxchg > > mode. For now, support this mode for absolute accesses only. > > > > This mode can be use, for example, to set the device-state-change > > indicator and the adapter-local-summary indicator atomically. > > > > Signed-off-by: Janis Schoetterl-Glausch <scgl@xxxxxxxxxxxxx> > > --- > > > > > > The return value of MEM_OP is: > > 0 on success, > > < 0 on generic error (e.g. -EFAULT or -ENOMEM), > > > 0 if an exception occurred while walking the page tables > > A cmpxchg failing because the old value doesn't match is neither an > > error nor an exception, so the question is how best to signal that > > condition. This is not strictly necessary since user space can compare > > the value of old after the MEM_OP with the value it set. If they're > > different the cmpxchg failed. It might be a better user interface if > > there is an easier way to see if the cmpxchg failed. > > This patch sets the cmpxchg flag bit to 0 on a successful cmpxchg. > > This way you can compare against a constant instead of the old old > > value. > > This has the disadvantage of being a bit weird, other suggestions > > welcome. > > This also breaks the old API of defining the ioctl as _IOW only ... with > your change to the flags field, it effectively gets IOWR instead. Oh, right. > > Maybe it would be better to put all the new logic into a new struct and only > pass a pointer to that struct in kvm_s390_mem_op, so that the ioctl stays > IOW ? ... or maybe even introduce a completely new ioctl for this > functionality instead? Hmmm, the latter seems a bit ugly since there is so much commonality with the existing memop. > > Thomas >
