[Qemu-devel] Modding an Arch

[Qemu-devel] Modding an Arch

[William Pearson]

I'm hoping to do some research on a slightly odd form of resource
allocation in an arch. Not sure which yet, hoping for some advise. My
only real world assembler practice has been 68K (a while ago), but I
have coded in my own assembler before on another homebrew very limited
odd VM.

I'm going to be changing these things, whilst keeping the rest constant,

 - how IRQs are assigned to handlers
 - how memory is protected
 - boot sequence
 - security levels
 - what the bios does when it finds devices
 - possibly adding a few instructions to the arch to facillitate the above
 - Paging in some fashion (might be removed)

These will be added

 - security in interactions with a special persistant memory (hard
disk alike) which will be what is booted
 - a device handled by the arch (rather than software)

My goal is to get a demo that works up quickly-ish (a year or two
while learning the arch, doing research and writing a very minimal
demo OS probably in asm), but can also be extended nicely into a
proper working system sometime down the line. I don't care about
backwards compatibility. But easy porting tools across would be nice.

So my questions are,

1) Is qemu a sensible thing to do this in.
2) If so which arch should I mod
3) What should I look at apart from stuff referenced in this thread

http://lists.gnu.org/archive/html/qemu-devel/2005-12/msg00157.html

Feel free to message me off-list if you want details of the arch, they
are a bit raw still though, as I'm still in the process of figuring
them out.

 Will Pearson

Re: [Qemu-devel] Modding an Arch

[Blue Swirl]

On 1/20/08, William Pearson <wil.pearson@gmail.com> wrote:
> I'm hoping to do some research on a slightly odd form of resource
> allocation in an arch. Not sure which yet, hoping for some advise. My
> only real world assembler practice has been 68K (a while ago), but I
> have coded in my own assembler before on another homebrew very limited
> odd VM.
>
> I'm going to be changing these things, whilst keeping the rest constant,
>
>  - how IRQs are assigned to handlers
>  - how memory is protected
>  - boot sequence
>  - security levels
>  - what the bios does when it finds devices
>  - possibly adding a few instructions to the arch to facillitate the above
>  - Paging in some fashion (might be removed)

Some of these are handled at OS or bios level, not at hardware level.
With Qemu you can change the HW side to whatever you want.

> These will be added
>
>  - security in interactions with a special persistant memory (hard
> disk alike) which will be what is booted

Special flash-like memory is not difficult to emulate.

>  - a device handled by the arch (rather than software)

What arch, host or emulated target?

> My goal is to get a demo that works up quickly-ish (a year or two
> while learning the arch, doing research and writing a very minimal
> demo OS probably in asm), but can also be extended nicely into a
> proper working system sometime down the line. I don't care about
> backwards compatibility. But easy porting tools across would be nice.
>
> So my questions are,
>
> 1) Is qemu a sensible thing to do this in.

For most cases yes. Qemu is aiming for fast emulation and therefore
takes some shortcuts. That breaks security devices that are based on
counting instruction cycles.

You also have to consider the BIOS issue, most probably you want to
change the BIOS to match the changes, unless you are aiming for a very
small embedded system.

> 2) If so which arch should I mod

Totally biased opinion: Sparc32. The instruction set is very minimal
and easy to learn, likewise for MMU and IOMMU. The system architecture
is very nice compared to baroque constructions like PC, though
documentation can be bit sparse. You have full source for OpenBIOS
(Open Firmware), and it also isolates the HW side from OS. That makes
adapting Linux to the new HW a bit easier if you want to try an
incremental approach. Many university OS projects in the 90s used
Sparc.

> 3) What should I look at apart from stuff referenced in this thread
>
> http://lists.gnu.org/archive/html/qemu-devel/2005-12/msg00157.html

http://www.openbios.org