Messages in this thread | | | Date | Wed, 5 Oct 2022 08:32:33 +0200 | Subject | Re: [PATCH v1 2/9] KVM: s390: Extend MEM_OP ioctl by storage key checked cmpxchg | From | Thomas Huth <> |
| |
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@linux.ibm.com> > --- > > > 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.
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?
Thomas
| |