Re: processor abstraction
Matt Thomas m...@3am-software.com writes: A lot of systems are coming with compute/peripheral processors with limited ram, etc. I was wondering what the abstraction should be? Obviously, mmap()'ing their memory would be nice. But what about stopping/starting? Messaging? How about using/extending the ptrace API to handle this? It looks like the primitives required are the same (+mmap you mention). And it would make sense to be able to attach to a qemu/coprocessor-provided process. The current API cannot immediately offer this because PT_GETREGS/PT_SETREGS takes a struct reg which is tied to the host processor. But I think adapting ptrace() to be cross-arch friendly would be nice and easy. An idea to stick to existing abstractions for the coprocessor case could be to have it launched as a stopped process. We could get the pid through an ioctl on a dev node (used also for mmapping). Remaining question: who does the process belong to? Must be root if it's started automatically early by the kernel, but we could start it when someone opens the dev node first with the credentials of the process opening the node. Aymeric
Re: processor abstraction
[...] compute/peripheral processors [...] abstraction [...] How about using/extending the ptrace API to handle this? It looks like the primitives required are the same (+mmap you mention). And it would make sense to be able to attach to a qemu/coprocessor-provided process. [...] An idea to stick to existing abstractions for the coprocessor case could be to have it launched as a stopped process. [...] I like this in general. But there's a potential issue I see: the ptrace interface is designed for userland processes, so its CPU state interfaces contain only the stuff appropriate to userland. But coprocessors have their own, separate, notion of privileged state; getting and setting coprocessor state would involve a bunch of stuff ptrace is not prepared to handle. It's possible fixing this could be rolled into the cross-arch fixes that would be necessary. But it's also possible it's not that simple; I haven't though about it for more than a few minutes. It would also mean extending your process abstraction, since the `process' running on a coprocessor differs in some significant ways from an ordinary host process. Again, this might be easy, but it also might not. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: processor abstraction
Hello, on Monday 07 October 2013 18:50:53 Mouse wrote: As for the minimal abstraction? Here's a strawman: - mmap to access the coprocessor's memory - ways (read/write? ioctl?) to do various things: - - halt - - single-step - - run - - grab processor state (registers c) - - set processor state -- trigger interrupt(s) or other messaging mechanisms -- read/write private memory which may not (easily) be mmap()able? I think a harder question will be privilege decisions. Who gets to frob which coprocessors? When? How is this enforced? And to open another can of worms - decide which parts of host memory the coprocessor may access. On SoCs it may be things like video memory which could be anywhere and may not even be physically contiguous. have fun Michael
Re: processor abstraction
Hi. On 8 Oct 2013, at 11:13 AM, Michael macallan1...@gmail.com wrote: on Monday 07 October 2013 18:50:53 Mouse wrote: As for the minimal abstraction? Here's a strawman: - mmap to access the coprocessor's memory - ways (read/write? ioctl?) to do various things: - - halt - - single-step - - run - - grab processor state (registers c) - - set processor state -- trigger interrupt(s) or other messaging mechanisms -- read/write private memory which may not (easily) be mmap()able? Indeed, I have DSP56002 card for Amiga waiting to be supported. It's connected via clock port interface (4 bits of address space, 8 bits of data, single interrupt line to host CPU). The 96kB of DSP SRAM is not available directly from host CPU. For a long time I'm tempted to add support for it, having such abstraction would be very helpful. -- Best regards, Radoslaw Kujawa signature.asc Description: Message signed with OpenPGP using GPGMail
Re: processor abstraction
Hello, on Monday 07 October 2013 20:48:04 Masao Uebayashi wrote: On Tue, Oct 8, 2013 at 7:24 AM, Matt Thomas m...@3am-software.com wrote: A lot of systems are coming with compute/peripheral processors with limited ram, etc. For example? I guess he means things like the DSPs found in OMAP SoCs, SGI's VICE, possibly Cell's SPEs, maybe even things like the 8051 integrated into things like the Silicon Motion SM502. May or may not have their own MMUs or analogues ( VICE has some private RAM and host-controlled DMA machinery for example ), usually there's a mechanism to send interrupts between host and peripheral processors. have fun Michael
