This ioctl argument struct has never had such a member.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15386
More recent Xen toolstacks use this for the SID_TO_CONTEXT operation
only, even when XSM is not in use.
XSM is actually an abstraction layer, of which the only current
implementation is FLASK. So this blindly assumes that the backend is
FLASK. Should another XSM backend be invented then we will have to
sort of detecting the correct one.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15384
XENMEM_machphys_compat_mfn_list is functionally identical to
XENMEM_machphys_mfn_list but returns a different list from Xen.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15379
The XEN_DOMCTL_[gs]et_vcpu_msrs work simiarly to the other get/set pairs,
taking a vcpu, buffer and size. A query with a buffer of NULL is a request
for the maximum size.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15370
The VKI_XEN_DOMCTL_[gs]et_ext_vcpucontext hypercalls have had interface
changes, but are largly just extentions of the existing structure.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15369
The change causing the sysctl bump is not in an implemented subop yet, so no
change is required. The change causing the domctl bump is in an implemented
subop, but has also been reverted in favor of a different way of performing
the same actions. Therefore, there is no net difference.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15365
Valgrind aspects, to match vex r3124.
See bug 339778 - Linux/TileGx platform support to Valgrind
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15080
named 'now' with this contents:
#!
/bin/date
the platform selection logic does this:
--11196:1:launcher no tool requested, defaulting to 'memcheck'
--11196:2:launcher selecting platform for './now'
--11196:2:launcher selecting platform for './now'
--11196:2:launcher opened './now'
--11196:2:launcher read 13 bytes from './now'
--11196:2:launcher selecting platform for ''
--11196:2:launcher selecting platform for '/home/florian/bin/'
--11196:2:launcher opened '/home/florian/bin/'
--11196:2:launcher selected platform 'unknown'
--11196:1:launcher no platform detected, defaulting platform to 'amd64-linux'
That is not quite right. Instead the platform should be determined by
examining the default shell.
Additionally, define VKI_BINPRM_BUF_SIZE because on linux only that many
characters are considered on a #! line. C.f. <linux>/fs/binfmt_script.c
m_ume/* needs to be adapted as well but that is a different patch.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15068
Some architectures, e.g. s390, don't have dedicated recvmmsg and sendmmsg
system calls, but use the socketcall multiplexing system call with
SYS_RECVMMSG or SYS_SENDMMSG (just like the accept4 systemcall can also
be called through socketcall). Create separate helpers for recvmmsg and
sendmmsg helpers that can be used by either the direct syscall or the
socket call.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14964
syscall numbers, and dummy wrappers for bsdthread_ctl and
sysctlbyname. Mash up of patches from fxcoudert@gcc.gnu.org and Rhys
Kidd (rhyskidd@gmail.com). Part of bug 339045.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14698
