On Thu, Sep 27, 2012 at 03:45:50PM +0100, Peter Maydell wrote:

On 27 September 2012 15:13, Will Deacon [off-list ref] wrote:

quoted

On Wed, Sep 26, 2012 at 02:43:14AM +0100, Christoffer Dall wrote:

quoted

this API has been discussed to death on the KVM lists, and we can of
course revive that if the regset makes it nicer - I'd prefer getting
this upstream the way that it is now though, where GET_REG / SET_REG
seems to be the way forward from a KVM perspective.

I'm sure the API has been discussed, but I've not seen that conversation and
I'm also not aware about whether or not regsets were considered as a
possibility for this stuff.

Can you point me at some documentation for regsets? It's a bit
difficult to have a sensible conversation about their suitability
otherwise...

The actual regset structure (struct user_regset) is internal to the kernel,
so it's not very well documented. As far as userspace interaction goes, the
usual method is via an iovec (see readv/writev) which is well documented, but
of course the kvm ioctl would still need documenting. For ptrace, that's just
a small paragraph in a user header:

/*
 * Generic ptrace interface that exports the architecture specific regsets
 * using the corresponding NT_* types (which are also used in the core dump).
 * Please note that the NT_PRSTATUS note type in a core dump contains a full
 * 'struct elf_prstatus'. But the user_regset for NT_PRSTATUS contains just the
 * elf_gregset_t that is the pr_reg field of 'struct elf_prstatus'. For all the
 * other user_regset flavors, the user_regset layout and the ELF core dump note
 * payload are exactly the same layout.
 *
 * This interface usage is as follows:
 *      struct iovec iov = { buf, len};
 *
 *      ret = ptrace(PTRACE_GETREGSET/PTRACE_SETREGSET, pid, NT_XXX_TYPE, &iov);
 *
 * On the successful completion, iov.len will be updated by the kernel,
 * specifying how much the kernel has written/read to/from the user's iov.buf.
 */

but obviously you'd probably have something under Documentation/.

(The potentially tricky area to handle is the cp15 registers, where
it's quite likely that new registers might be added later and so
userspace has to be able to query the kernel for what is supported
and possibly deal with the kernel reporting attempts to set read
only bits within registers, etc. Using the same ABI for simpler
cases like the GPRs and FP registers is then just a matter of
being consistent in the interface we expose to userspace.)

You *could* split up cp15 into lots of regsets but realistically that's going
to hurt down the line. GPR and FP would be good though.

Will