[Qemu-devel] Developing new user-level target?

[Qemu-devel] Developing new user-level target?

[Patrick Mackinlay]

In searching across the net, I've managed to stumble across QEMU, which may 
be the best starting point for a project I have in mind. I'd like some 
feedback on the difficulty of doing what I propose, or if there are any more 
appropriate systems that people are aware of that may better satisfy my 
requirements.

Essentially, I have an interest in some older (mid to late 80's) UNIX 
computer systems. The one I'm particularly interested in used the CLIPPER 
processor (one of the first fully commercialised RISC CPUs) and a version of 
SVR3 named CLIX.

I'm interested in adding support for this system to QEMU. In the first 
instance, I'd like to get a user-level target working. Without having looked 
at any of the source yet, can someone comment on the difficulty of adding 
support for a new CPU? Following that, my next biggest concern is supporting 
not only the COFF executable format (does QEMU support only ELF at the 
moment?), but the translation from the native to Linux system calls.

As a final complexity, I'd like to (eventually) host all this on Windows - 
either natively under Win32, or more probably under the Interix subsystem 
included in Microsoft's Services For Unix (SFU). Again, the question arises 
regarding the system call translation component - how much work is involved 
in adapting this to suit a different (although still UNIX) target and a 
non-Linux host?

BTW, before anyone asks, I'm specifically interested in the user-level 
target right now. Producing a full system level emulation is interesting, 
but I have almost no documentation of the other system hardware and I think 
it's going to be quite an exercise in reverse-engineering to figure out 
enough to write emulation code.

Regards,
Pat Mackinlay.

Re: [Qemu-devel] Developing new user-level target?

[Fabrice Bellard]

Hi,

User level emulation in QEMU only supports Linux as host _and_ guest. 
Supporting a different Unix would be very difficult except for simple 
console programs.

If the hardware is simple enough, it would be better to go for full 
system emulation right from the beginning.

Fabrice.

Patrick Mackinlay wrote:
> In searching across the net, I've managed to stumble across QEMU, which 
> may be the best starting point for a project I have in mind. I'd like 
> some feedback on the difficulty of doing what I propose, or if there are 
> any more appropriate systems that people are aware of that may better 
> satisfy my requirements.
> 
> Essentially, I have an interest in some older (mid to late 80's) UNIX 
> computer systems. The one I'm particularly interested in used the 
> CLIPPER processor (one of the first fully commercialised RISC CPUs) and 
> a version of SVR3 named CLIX.
> 
> I'm interested in adding support for this system to QEMU. In the first 
> instance, I'd like to get a user-level target working. Without having 
> looked at any of the source yet, can someone comment on the difficulty 
> of adding support for a new CPU? Following that, my next biggest concern 
> is supporting not only the COFF executable format (does QEMU support 
> only ELF at the moment?), but the translation from the native to Linux 
> system calls.
> 
> As a final complexity, I'd like to (eventually) host all this on Windows 
> - either natively under Win32, or more probably under the Interix 
> subsystem included in Microsoft's Services For Unix (SFU). Again, the 
> question arises regarding the system call translation component - how 
> much work is involved in adapting this to suit a different (although 
> still UNIX) target and a non-Linux host?
> 
> BTW, before anyone asks, I'm specifically interested in the user-level 
> target right now. Producing a full system level emulation is 
> interesting, but I have almost no documentation of the other system 
> hardware and I think it's going to be quite an exercise in 
> reverse-engineering to figure out enough to write emulation code.
> 
> Regards,
> Pat Mackinlay.
> 
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 

Re: [Qemu-devel] Developing new user-level target?

[Patrick Mackinlay]

>User level emulation in QEMU only supports Linux as host _and_ guest. 
>Supporting a different Unix >would be very difficult except for simple 
>console programs.

I understand this is the case right now, but I'm curious to know how 
difficult it might be to tackle the changes required? Let's assume to begin 
with that the new target Unix contains only system calls which are a subset 
of Linux (a pretty good bet). Essentially what we're talking about here is 
mapping the parameters from the target set onto the required host system 
calls? Presumably even now, with different host/target CPU's, some argument 
reformatting is required?

Also, I assume that even a small subset of those calls is enough to get a 
large number of programs working? Finally, in my case, the types of programs 
I'd most like access to are things like compilers, assemblers etc, so their 
subset of calls should be quite small.

Is there some additional complexity involved that I'm not aware of?

>If the hardware is simple enough, it would be better to go for full system 
>emulation right from the >beginning.

This premise is the tricky part. Whilst many of the system components are 
fairly standard and have documentation available, there are some FPGA's that 
hold the whole lot together and emulating those may be difficult without 
detailed "inside information". On the other hand, being able to trace the 
target OS (and its diagnostic monitor code) inside an emulation environment 
like QEMU may actually be the best way to actively discover the hardware 
details.

Comments?

Regards,
Pat Mackinlay.