[GSoC-2014] Introducing Myself
Hi. I am interested in participating in Google Summer of Code - 2014 with Linaro and working on two of the ideas from Ideas page [1]: AArch64 porting of Free Software Packages - I am amazed going through the details mentioned at [2] about the use of assembly in packages. I would like to discover more, and figure out where I could contribute. Port UEFI to Low-Cost Embedded Platform - Although I have not used a system with UEFI before, I want to know more about the low level interaction that occurs between the kernel and the hardware. Please help me get started and gain a better understanding of what implementing each of these ideas would involve. About me: I can program with C, Perl, Python, Processing and Shell Scripts. I built a game for the Intel Perceptual Computing Challenge-2013 [3] and have experience with development for the Beagleboard and Pandaboard. I am currently reading Greg K-H's Linux Device Drivers to figure out how drivers work. I am also learning the x86 assembly language. I have been an open source user for a long time, and have a commit integrated into GNOME's Anjuta IDE [4] I recently worked with Red Hat on testing the effectiveness of random number generators on a virtual machine with qemu.[5] I also have a fair know-how of git. [1] https://wiki.linaro.org/SummerOfCode2014/ProjectIdeas [2] https://wiki.linaro.org/LEG/Engineering/OPTIM/Assembly [3] http://varadgautam.wordpress.com/2013/09/26/bender-a-game-using-the-intel-perceptual-sdk/ [4] https://git.gnome.org/browse/anjuta/commit/?id=eb10532632014b59505c788ffad4c79706586dce [5] http://varadgautam.wordpress.com/2013/12/17/dieharder-tests-on-a-qemu-vm-1-setup/ Thanks. Varad ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Qemu-devel] Call for testing QEMU aarch64-linux-user emulation
Michael Matz writes: > Hi, > > On Tue, 25 Feb 2014, Peter Maydell wrote: > >> On 25 February 2014 13:33, Michael Matz wrote >> > The biggest road-block is that signal vs syscall handling is >> > fundamentally broken in linux-user and it's unfixable without >> > assembler implementations of the syscall caller. >> >> I'm not entirely sure it's possible to fix even with >> hand-rolled assembly, to be honest. > > I am fairly sure. The problem is "simply" to detect if the signal arrived > while inside the kernel (doing the syscalls job) or still or already > outside. This structure helps with that: Is this "simply" a case of having a precise state in/around syscalls? AIUI we already have such a mechanism for dealing with faults in translated code so this is all aimed at when an asynchronous signal arrives somewhere in QEMU's own code. So this case be: * the execution/translation loop * a helper function * a syscall (helper jump out of execution/translation loop?) I wonder if it would be possible to defer the handing of the signal back to the process until we know we are precise? -- Alex Bennée Finding this all eerily familiar. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Qemu-devel] Call for testing QEMU aarch64-linux-user emulation
> Am 28.02.2014 um 22:21 schrieb Peter Maydell : > >> On 28 February 2014 14:12, Alex Bennée wrote: >> Is this "simply" a case of having a precise state in/around syscalls? > > No. > >> AIUI we already have such a mechanism for dealing with faults in >> translated code so this is all aimed at when an asynchronous signal >> arrives somewhere in QEMU's own code. > > The major problem is that system calls are supposed to be > atomic wrt signals, ie for the guest we must appear to > either take the signal first, or have the syscall return > EINTR, or take it after. Further, we mustn't make a host > syscall that is supposed to be interrupted by a signal if > the signal has already arrived, because we'll hang. > > http://lists.gnu.org/archive/html/qemu-devel/2011-12/msg00384.html > has a fuller description of the problem, though note that > my analysis of the solution is incorrect. I think Michael's > right that we could deal with this if we had known native > asm for the syscall sequence. (We probably want to separate > out the interruptible syscalls so we can continue to use > straightforward "just call libc" code for the bulk of them > which are non-interruptible.) Could we check the instruction at the sognaling pc and check if it's a known syscall instruction? No need to replace glibc wrappers then. Alex > > thanks > -- PMM ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Qemu-devel] Call for testing QEMU aarch64-linux-user emulation
On 28 February 2014 14:12, Alex Bennée wrote: > Is this "simply" a case of having a precise state in/around syscalls? No. > AIUI we already have such a mechanism for dealing with faults in > translated code so this is all aimed at when an asynchronous signal > arrives somewhere in QEMU's own code. The major problem is that system calls are supposed to be atomic wrt signals, ie for the guest we must appear to either take the signal first, or have the syscall return EINTR, or take it after. Further, we mustn't make a host syscall that is supposed to be interrupted by a signal if the signal has already arrived, because we'll hang. http://lists.gnu.org/archive/html/qemu-devel/2011-12/msg00384.html has a fuller description of the problem, though note that my analysis of the solution is incorrect. I think Michael's right that we could deal with this if we had known native asm for the syscall sequence. (We probably want to separate out the interruptible syscalls so we can continue to use straightforward "just call libc" code for the bulk of them which are non-interruptible.) thanks -- PMM ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Qemu-devel] Call for testing QEMU aarch64-linux-user emulation
On 28 February 2014 14:27, Alexander Graf wrote: > Could we check the instruction at the sognaling pc and check > if it's a known syscall instruction? No need to replace glibc > wrappers then. No, because the behaviour we want for "started handling syscall in qemu" through to "PC anything up to but not including the syscall insn" is "back out and take signal then try again", which means we need to be able to unwind anything we were doing. If we (effectively) longjmp out of the middle of glibc we're liable to leave locked mutexes and otherwise mess up glibc internals. Also we need to be able to distinguish "not got to syscall insn yet" from "after syscall insn", which isn't possible to determine if all you have is "PC is inside glibc but not actually at the syscall insn". There really aren't all that many interruptible syscalls, though, so we can probably live with handrolling those. thanks -- PMM ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Qemu-devel] Call for testing QEMU aarch64-linux-user emulation
Peter Maydell writes: > On 28 February 2014 14:27, Alexander Graf wrote: >> Could we check the instruction at the sognaling pc and check >> if it's a known syscall instruction? No need to replace glibc >> wrappers then. > > No, because the behaviour we want for "started handling > syscall in qemu" through to "PC anything up to but not > including the syscall insn" is "back out and take signal > then try again", which means we need to be able to unwind > anything we were doing. If we (effectively) longjmp out of > the middle of glibc we're liable to leave locked mutexes > and otherwise mess up glibc internals. The other option is roll the real PC forward until you know you are at a point that everything is in a known state - in this case a labelled syscall instruction. You can achieve this with a host interpreter (which would be a lot of work to add to QEMU) or maybe achieve the same magic with ptrace? If you really want to avoid too much messing about you mask off all your signals until you really know you can do something about them. It goes without saying I hope that any serious attempt to fix this needs a decent set of test cases because the edge cases are numerous. -- Alex Bennée ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Qemu-devel] Call for testing QEMU aarch64-linux-user emulation
On 28 February 2014 17:08, Alex Bennée wrote: > > Peter Maydell writes: > >> On 28 February 2014 14:27, Alexander Graf wrote: >>> Could we check the instruction at the sognaling pc and check >>> if it's a known syscall instruction? No need to replace glibc >>> wrappers then. >> >> No, because the behaviour we want for "started handling >> syscall in qemu" through to "PC anything up to but not >> including the syscall insn" is "back out and take signal >> then try again", which means we need to be able to unwind >> anything we were doing. If we (effectively) longjmp out of >> the middle of glibc we're liable to leave locked mutexes >> and otherwise mess up glibc internals. > > The other option is roll the real PC forward until you know you are at a > point that everything is in a known state - in this case a labelled > syscall instruction. I don't see how rolling the host PC forward would work. We can't take the guest signal where we are, we can't go forward because that would imply executing the host syscall (which might now block): the only thing we can do is roll back to a point where we can make it appear we hadn't executed the guest syscall insn yet, and then take the guest signal. Masking signals doesn't work in general because you need the signal to be unblocked while you do the host syscall (so it can correctly return EINTR if the signal comes in while it's doing stuff), and there's no way to atomically unblock-and-do-syscall (and certainly no way to do that if your syscall is buried inside glibc). thanks -- PMM ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
