qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] qemu alpha?


From: J. Mayer
Subject: Re: [Qemu-devel] qemu alpha?
Date: Tue, 23 Oct 2007 00:38:03 +0200

On Mon, 2007-10-22 at 09:43 +0200, Oliver Falk wrote:
> On 10/21/2007 01:06 PM, J. Mayer wrote:
> > On Sun, 2007-10-21 at 05:43 -0500, Rob Landley wrote:
> >> On Saturday 20 October 2007 3:56:12 am J. Mayer wrote:
> >>> On Fri, 2007-10-19 at 19:49 -0500, Rob Landley wrote:
> >>>> On Sunday 14 October 2007 5:14:27 am J. Mayer wrote:
> >>>>> On Sun, 2007-10-14 at 11:19 +0200, Oliver Falk wrote:
> >>>>>> Hi list!
> >>>>> Hi you !
> >>>>>
> >>>>>> Just wanted to know how far the progress on alpha target is? I would
> >>>>>> be happy if I have some 'virtual alpha' to test new isos.
> >>>>>>
> >>>>>> If I can help some way (I have a few alphas around). Let me know.
> >>>>> I'm happy to see someone interresting in improving Alpha support, which
> >>>>> is .... very alpha for now !
> >>>> I'm interested in testing Alpha too, but I haven't seem a
> >>>> qemu-system-alpha show up yet.  Alas, I have no hardware or specific
> >>>> expertise in this platform, I'm just trying to build and boot Linux
> >>>> kernels (and corresponding root filesystems) on as many emulated target
> >>>> platforms as I can.
> >>> There are a lot of things missing for qemu-system-alpha to be available:
> >>> - the PALCode emulation is far from being complete or even usable
> >> I have no idea what that is.
> > 
> > The PALCode is mainly equivalent to the microcode of most CPU
> > architectures. What is different to microcode is that is uses only
> > regular Alpha instructions, just adding 4 instructions to access special
> > "hardware registers" and access the memory with different priviledge
> > levels. Another main idea is that everyone can write its own PALCode
> > image and switch to it at run-time. Then, for example, the PALCode ABI
> > is not the same one if you run Linux or Windows NT. The PALCode handles
> > all complex operations. For example, the CPU provides only TLB and the
> > MMU tables search is actually implemented in software, in the PALCode.
> > This greatly simplifies the CPU design and allows a high level of
> > flexibility. And if your OS need a specific ABI for example to handle
> > CPU exception, you define your ABI, write the PALCode using Alpha insns
> > and use it ! The Alpha CPU also provide an instruction to do PALCode
> > calls from the OS or applications.
> > There are 3 (4 ?) "native" PALCode ABIs documented in the Alpha CPUs
> > specifications then those can be emulated at the host side in Qemu. It
> > is in fact needed to emulate a subset of the PALCode even to run
> > user-mode programs.
> 
> Pretty good explained! Thanks!
> 
> 
> 
> However, what do you need to make the alpha emulation work? Does ssh to
> an Alpha help you? I'm quite sure I can offer you access to some ev5
> machine very soon and I might give access to some ds10 (ev67 machine).
> There's also some ds10 (ev6 'only') machine in Australia, that actually
> works as a builder for the AlphaCore project - but it's not mine and I
> would need to ask if I can give access to someone else...

I actually do not have a lot of time to spend of Alpha emulation, that's
why it would be great if some could test and compare the execution of
simple programs (then later more complicated one) in order to find the
most obvious emulation bugs, with the linux-user mode emulation.
For this, an access to any Alpha machine could help a lot.
For the full system emulation, a lot of work is to be done, mostly the
PALCode emulation and putting together all elements of an actual
hardware machine. Note that the PALCode emulation could be avoided if
the emulator is able to run native PALCode image but I don't know if
those images are easily available...

-- 
J. Mayer <address@hidden>
Never organized





reply via email to

[Prev in Thread] Current Thread [Next in Thread]