[Qemu-devel] State of sparc64-softmmu

[Qemu-devel] State of sparc64-softmmu

[Anthony Liguori]

Hi,

I noticed that sparc64-softmmu's build is broken in the latest git.  The 
reason for this is that the default --target-list doesn't include 
sparc64-softmmu so it's getting through my compile tests.

But this leads me to wonder, is this just an oversite or is there 
something wrong with sparc64-softmmu that we don't recommend building it 
by default?

-- 
Regards,

Anthony Liguori

Re: [Qemu-devel] State of sparc64-softmmu

[Paul Brook]

> But this leads me to wonder, is this just an oversite or is there
> something wrong with sparc64-softmmu that we don't recommend building it
> by default?

My understanding it that there are still several large chunks remaining to be 
implemented, and it can not boot any real guest operating systems.

Paul

Re: [Qemu-devel] State of sparc64-softmmu

[Anthony Liguori]

Paul Brook wrote:
>> But this leads me to wonder, is this just an oversite or is there
>> something wrong with sparc64-softmmu that we don't recommend building it
>> by default?
>>     
>
> My understanding it that there are still several large chunks remaining to be 
> implemented, and it can not boot any real guest operating systems.
>   

If it's not building by default, it's going to bitrot (it already has).

So I'd suggest either making it build by default or removing it from the 
tree and moving it into a separate tree.

-- 
Regards,

Anthony Liguori

Re: [Qemu-devel] State of sparc64-softmmu

[Paul Brook]

On Monday 22 June 2009, Anthony Liguori wrote:
> Paul Brook wrote:
> >> But this leads me to wonder, is this just an oversite or is there
> >> something wrong with sparc64-softmmu that we don't recommend building it
> >> by default?
> >
> > My understanding it that there are still several large chunks remaining
> > to be implemented, and it can not boot any real guest operating systems.
>
> If it's not building by default, it's going to bitrot (it already has).

Yes, although without any runtime tests it's still likely to suffer quite 
badly from bitrot.

Paul

Re: [Qemu-devel] State of sparc64-softmmu

[Blue Swirl]

On 6/23/09, Paul Brook <paul@codesourcery.com> wrote:
> On Monday 22 June 2009, Anthony Liguori wrote:
>  > Paul Brook wrote:
>  > >> But this leads me to wonder, is this just an oversite or is there
>  > >> something wrong with sparc64-softmmu that we don't recommend building it
>  > >> by default?
>  > >
>  > > My understanding it that there are still several large chunks remaining
>  > > to be implemented, and it can not boot any real guest operating systems.
>  >
>  > If it's not building by default, it's going to bitrot (it already has).
>
>
> Yes, although without any runtime tests it's still likely to suffer quite
>  badly from bitrot.

We provide openbios-sparc64 ROM image which can be used standalone for
quick tests. Then CD boot from various distro images (Linux, HelenOS,
OpenSolaris) can be tested, loading works (except for OpenSolaris) but
the kernels does not get very far. Also, Sparc32 Linux user software
can be tested with sparc32plus emulator, this tests the compatibility
mode of the CPU but not 64 bit features. I'm using the above in my
test setup.

In addition, OpenBSD/Sparc64 userland is fully 64 bits and V9, so
bsd-user can test the 64 bit CPU features. This part is not finished
yet. Booting from BSD CD images does not work.

Re: [Qemu-devel] State of sparc64-softmmu

[Blue Swirl]

On 6/23/09, Anthony Liguori <aliguori@us.ibm.com> wrote:
> Paul Brook wrote:
>
> >
> > > But this leads me to wonder, is this just an oversite or is there
> > > something wrong with sparc64-softmmu that we don't recommend building it
> > > by default?
> > >
> > >
> >
> > My understanding it that there are still several large chunks remaining to
> be implemented, and it can not boot any real guest operating systems.
> >
> >
>
>  If it's not building by default, it's going to bitrot (it already has).

Only for short periods, I frequently test it.

>  So I'd suggest either making it build by default or removing it from the
> tree and moving it into a separate tree.

Ok, I'll enable it.