[Qemu-devel] sparc hflags support?

[Qemu-devel] sparc hflags support?

[Robert Reif]

I'm looking at adding more complete support for different sparc32
CPUs, MMUs,  cache controllers and systems.

Each CPU/MMU/cache controller combination is slightly different and
requires its own unique state.  For example the two CPUs currently
supported save the boot mode in different bits in the MMU control
register: 0x2000 for the SuperSparc and 0x4000 for the TurboSparc.
Others bits will need to be saved in the MMU and cache controllers
as better hardware emulation is added.

It looks like other architectures handle this by computing hflags
in the target directories but sparc determines the flags value to save
in common code. 

Are there plans to add hflags support to sparc?  I'm willing work
on it but I don't have the experience yet to tackle a job like this
without help.

Re: [Qemu-devel] sparc hflags support?

[Paul Brook]

On Sunday 04 November 2007, Robert Reif wrote:
> I'm looking at adding more complete support for different sparc32
> CPUs, MMUs,  cache controllers and systems.
>
> Each CPU/MMU/cache controller combination is slightly different and
> requires its own unique state.  For example the two CPUs currently
> supported save the boot mode in different bits in the MMU control
> register: 0x2000 for the SuperSparc and 0x4000 for the TurboSparc.
> Others bits will need to be saved in the MMU and cache controllers
> as better hardware emulation is added.

If it's something that only changes rarely (e.g. when switching from early 
boot to a real OS environment) you can just do a tb flush.

Does mmu/cache mode actually effect the instruction semantics? 

Paul

Re: [Qemu-devel] sparc hflags support?

[Blue Swirl]

On 11/5/07, Paul Brook <paul@codesourcery.com> wrote:
> On Sunday 04 November 2007, Robert Reif wrote:
> > I'm looking at adding more complete support for different sparc32
> > CPUs, MMUs,  cache controllers and systems.
> >
> > Each CPU/MMU/cache controller combination is slightly different and
> > requires its own unique state.  For example the two CPUs currently
> > supported save the boot mode in different bits in the MMU control
> > register: 0x2000 for the SuperSparc and 0x4000 for the TurboSparc.
> > Others bits will need to be saved in the MMU and cache controllers
> > as better hardware emulation is added.
>
> If it's something that only changes rarely (e.g. when switching from early
> boot to a real OS environment) you can just do a tb flush.

Boot mode is used even earlier. It's enabled on reset and it forces
the boot rom to occupy all of the address space. Boot rom disables it
after relocating itself and enabling the MMU. On Sparc the MMU is
never disabled after that, even during boot.

> Does mmu/cache mode actually effect the instruction semantics?

No, only instruction fetches, though I don't know about the cache controllers.

Re: [Qemu-devel] sparc hflags support?

[Blue Swirl]

On 11/5/07, Robert Reif <reif@earthlink.net> wrote:
> I'm looking at adding more complete support for different sparc32
> CPUs, MMUs,  cache controllers and systems.

Great! The only problems I see are that OpenBIOS support needs to be
added for the new CPUs and supporting all CPUs with one image may
become a bit complex.

> Each CPU/MMU/cache controller combination is slightly different and
> requires its own unique state.  For example the two CPUs currently
> supported save the boot mode in different bits in the MMU control
> register: 0x2000 for the SuperSparc and 0x4000 for the TurboSparc.
> Others bits will need to be saved in the MMU and cache controllers
> as better hardware emulation is added.

I think other targets have better design for supporting different CPU
types, for example MIPS and PPC.

> It looks like other architectures handle this by computing hflags
> in the target directories but sparc determines the flags value to save
> in common code.
>
> Are there plans to add hflags support to sparc?  I'm willing work
> on it but I don't have the experience yet to tackle a job like this
> without help.

It could bring some performance benefit. Just try to move the tb flags
computation to op_helper.c. Every time hflags elements change,
recompute the flags. I'd be happy to try to help you.