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
Bug is not really fixed, instead the SHM_HUGETLB flag is ignored.
Note that it is not straightforward to properly fix this,
as this implies either to learn aspacemgr what huge pages are.
Also, the trick used in the fix for 333051 cannot be used easily,
because the SHM_HUGETLB flag is given in shmget, while the mmap
is done in shmat.
So, the easiest is to just ignore the SHM_HUGETLB flag.
SHM_HUGETLB is supposed to only give a performance impact.
Ignoring it should be benign.
Theoretically, the caller might expect a sucessful shmget(SHM_HUGETLB)+shmat
to give pages aligned on e.g. 1MB.
In this case, bad luck, the program will misbehave under valgrind.
To warn of this, a warning is given (once) when SHM_HUGETLB is seen.
The map_unmap.c test has been restructured somewaht to allow
TEST_SHM_HUGETLB to be tested independently (or not) of the TEST_MAP_HUGETLB.
Note also that by default, testing MAP_HUGETLB and SHM_HUGETLB
is disabled as usually, huge pages are not enabled.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14683
to issue a false complaint. Fixes BZ #339706
Source patch by David Herrmann (dh.herrmann@gmail.com).
Testcase by myself.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14646
the parameter. QEMU does pass 0 nevertheless as parameter.
bugzilla: [Bug 339424] Full support of KVM ioctl
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14569
To track POSIX glibc and the kernel agreed to change the type of the
sa_flags field in struct sigaction to an int. There is now a int
__glibc_reserved0 padding field that can be passed undefined.
See https://sourceware.org/ml/libc-alpha/2014-09/msg00161.html
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14508
