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
Matt Thomas 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
Hi. On 8 Oct 2013, at 11:13 AM, Michael 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 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
Hello, on Monday 07 October 2013 20:48:04 Masao Uebayashi wrote: > On Tue, Oct 8, 2013 at 7:24 AM, Matt Thomas 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
Re: "processor" abstraction
On Tue, Oct 8, 2013 at 7:24 AM, Matt Thomas wrote: > > A lot of systems are coming with compute/peripheral processors with > limited ram, etc. For example? How are those compute/peripheral processors connected?
Re: "processor" abstraction
> 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? > Ideas are welcome. I would suggest something minimal, then let people develop it and see where it goes. 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 I think a harder question will be privilege decisions. Who gets to frob which coprocessors? When? How is this enforced? Another harder question is inventing a suitable abstraction for "processor state", especially if (eg) the coprocessor and the host processor have different native register sizes, or there's some state that's expensive to get/set and only occasionally useful. What about granting the coprocessor access to host processor resources (memory, device registers, etc)? Some hardware may be able to do this only in limited ways, other may not support it at all. What about (eg) traps on the coprocessor? Breakpoints (which are often implemented as traps)? What about coprocessors which lack direct ways for the host to do some of the above? There's also the question of how much gets moved under this umbrella. What about, eg, the 56k on a NeXT? What about CPUs embedded in peripheral devices? (Most of them aren't normally used as processors, but some peripherals allow the CPU to give them code to run; this is usually thought of as firmware for the device, but there's no reason it has to be). What about a blitter chip? What about FPUs? At least part of this depends on the intended application. The only case where I ever did anything much like this personally was with 4.3 on a MicroVAX-II which had a KA620 (a slightly tweaked MicroVAX-II) in it as an auxiliary processor; it was doing robotics and the KA620 was running the control law. I built a small kernel which the host booted on the aux; that particular implementation was heavily application-specific, but I think it could have been done with the above abstractions /~\ 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
"processor" abstraction
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? Ideas are welcome.
