[Qemu-devel] Potential sparc32 MMU bug

[Qemu-devel] Potential sparc32 MMU bug

[Peter]

While working on getting SunOS to boot under qemu, I ran into a very
odd bug, and I'm not sure whose fault it is.

The SunOS bootloader tries to install trap 0 by writing to the trap
table.  The trap table is in the .text (read-only) section of the
OpenBIOS ROM.

The bug is that the write to the read-only section silently fails --
it doesn't cause an interrupt in the VM.

It looks like the VM believes all of the ROM is rwx (based on my
examination of cpu_sparc_handle_mmu_fault).  I presume the write fails
because of Linux's memory protection (since the OpenBIOS ELF is
mmap'd).  But I'm not sure why the disallowed write doesn't cause
_something_ to happen.

Should qemu be catching the failed write and passing it on to the VM?
Does qemu need to tell the VM's MMU which portions of the loaded ROM
are read-only?  Or does OpenBIOS need to inform the VM's MMU that the
loaded .text section is read-only?

I presume it's something OpenBIOS should be doing, but that mailing
list is very very quiet, and I figured I'd make sure it wasn't an
underlying qemu bug.

How should qemu be handling this?  What parts of qemu should I look at next?

If people are interested in booting SunOS under qemu, you may want to
check out my posting to the OpenBIOS mailing list, since most (if not
all) of the problems are OpenBIOS's.

Re: [Qemu-devel] Potential sparc32 MMU bug

[Paul Brook]

On Friday 16 February 2007 16:55, Peter wrote:
> While working on getting SunOS to boot under qemu, I ran into a very
> odd bug, and I'm not sure whose fault it is.
>
> The SunOS bootloader tries to install trap 0 by writing to the trap
> table.  The trap table is in the .text (read-only) section of the
> OpenBIOS ROM.

I don't know about sparc, but it's normal for writes to ROM to be ignored.
However by my reading the sparc bios is loaded into RAM anyway, so it 
shouldn't matter.

Paul

Re: [Qemu-devel] Potential sparc32 MMU bug

[Peter]

It definitely gets blocked by something: if I leave the the trap table
in the .text section, the write silently fails.  If I move the trap
table to the .data section, the write succeeds.  If I move the trap
table over to .rodata, the write fails again.  What are you looking at
that suggests the whole sparc bios is loaded read/write?

On 2/16/07, Paul Brook <paul@codesourcery.com> wrote:
> On Friday 16 February 2007 16:55, Peter wrote:
> > While working on getting SunOS to boot under qemu, I ran into a very
> > odd bug, and I'm not sure whose fault it is.
> >
> > The SunOS bootloader tries to install trap 0 by writing to the trap
> > table.  The trap table is in the .text (read-only) section of the
> > OpenBIOS ROM.
>
> I don't know about sparc, but it's normal for writes to ROM to be ignored.
> However by my reading the sparc bios is loaded into RAM anyway, so it
> shouldn't matter.
>
> Paul
>

Re: [Qemu-devel] Potential sparc32 MMU bug

[Paul Brook]

> > I don't know about sparc, but it's normal for writes to ROM to be
> > ignored. However by my reading the sparc bios is loaded into RAM anyway,
> > so it shouldn't matter.
>
> It definitely gets blocked by something: if I leave the the trap table
> in the .text section, the write silently fails.  If I move the trap
> table to the .data section, the write succeeds.  If I move the trap
> table over to .rodata, the write fails again.  What are you looking at
> that suggests the whole sparc bios is loaded read/write?

I was mistaken. There is a ROM area defined, it's just the elf loader doesn't 
care whether it's loading to rom or ram.

My comment about rom writes being silently ignored still applies.

Paul

Re: [Qemu-devel] Potential sparc32 MMU bug

[Peter]

Where is the policy of silently ignoring ROM writes implemented?  It
may not be the proper behavior for sparc, and I'd like to tinker with
it.  I'm just not sure where the write is getting suppressed (or,
alternatively, where the exception is getting suppressed).

On 2/16/07, Paul Brook <paul@codesourcery.com> wrote:
> > > I don't know about sparc, but it's normal for writes to ROM to be
> > > ignored. However by my reading the sparc bios is loaded into RAM anyway,
> > > so it shouldn't matter.
> >
> > It definitely gets blocked by something: if I leave the the trap table
> > in the .text section, the write silently fails.  If I move the trap
> > table to the .data section, the write succeeds.  If I move the trap
> > table over to .rodata, the write fails again.  What are you looking at
> > that suggests the whole sparc bios is loaded read/write?
>
> I was mistaken. There is a ROM area defined, it's just the elf loader doesn't
> care whether it's loading to rom or ram.
>
> My comment about rom writes being silently ignored still applies.
>
> Paul
>
>

Re: [Qemu-devel] Potential sparc32 MMU bug

[Peter Creath]

By banging on get_physical_address, I was able to confirm that qemu
will properly assert an exception if the VM's MMU believes the page is
read-only.

How does env->mmuregs[] get mapped to the VM's MMU?  I would normally
write this off as an OpenBIOS bug, but it seems like bad behavior for
an emulator to silently suppress all such access violations.  At least
there should be a way to turn the suppression off for debugging -- or
at least a way for QEMU to log the suppressed error.

Is there such a way that I've missed?


On 2/16/07, Peter <pjcreath+openbios@gmail.com> wrote:
> Where is the policy of silently ignoring ROM writes implemented?  It
> may not be the proper behavior for sparc, and I'd like to tinker with
> it.  I'm just not sure where the write is getting suppressed (or,
> alternatively, where the exception is getting suppressed).
>
> On 2/16/07, Paul Brook <paul@codesourcery.com> wrote:
> > > > I don't know about sparc, but it's normal for writes to ROM to be
> > > > ignored. However by my reading the sparc bios is loaded into RAM anyway,
> > > > so it shouldn't matter.
> > >
> > > It definitely gets blocked by something: if I leave the the trap table
> > > in the .text section, the write silently fails.  If I move the trap
> > > table to the .data section, the write succeeds.  If I move the trap
> > > table over to .rodata, the write fails again.  What are you looking at
> > > that suggests the whole sparc bios is loaded read/write?
> >
> > I was mistaken. There is a ROM area defined, it's just the elf loader doesn't
> > care whether it's loading to rom or ram.
> >
> > My comment about rom writes being silently ignored still applies.
> >
> > Paul
> >
> >
>

RE: [Qemu-devel] Potential sparc32 MMU bug

[Blue Swirl]

>While working on getting SunOS to boot under qemu, I ran into a very
>odd bug, and I'm not sure whose fault it is.

Excellent, there are not too many Sparc developers!

>The SunOS bootloader tries to install trap 0 by writing to the trap
>table.  The trap table is in the .text (read-only) section of the
>OpenBIOS ROM.
>
>The bug is that the write to the read-only section silently fails --
>it doesn't cause an interrupt in the VM.
>
>It looks like the VM believes all of the ROM is rwx (based on my
>examination of cpu_sparc_handle_mmu_fault).  I presume the write fails
>because of Linux's memory protection (since the OpenBIOS ELF is
>mmap'd).  But I'm not sure why the disallowed write doesn't cause
>_something_ to happen.
>
>Should qemu be catching the failed write and passing it on to the VM?
>Does qemu need to tell the VM's MMU which portions of the loaded ROM
>are read-only?  Or does OpenBIOS need to inform the VM's MMU that the
>loaded .text section is read-only?
>
>I presume it's something OpenBIOS should be doing, but that mailing
>list is very very quiet, and I figured I'd make sure it wasn't an
>underlying qemu bug.
>
>How should qemu be handling this?  What parts of qemu should I look at 
>next?

OpenBIOS programs the MMU as the first thing in startup, please see 
arch/sparc32/head.S. It maps the .text area of ROM with 1:1 mapping, the 
protection is RWX despite the comment saying that it's execute-only (sorry). 
This explains why the fault does not happen. In OpenBIOS, .data is not used 
at all, only .rodata and .bss, so changing just the ELF directive does not 
help but the ROM should be copied to RAM.

Qemu is correct (unless writes to ROM on real Sparc hardware cause MMU/IOMMU 
faults), but OpenBIOS should be modified. We should continue this in 
OpenBIOS mailing list as this is not related to Qemu.

_________________________________________________________________
Don't just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/