[Qemu-devel] SPARC64: immediate segfault on startup with git mastervery

[Qemu-devel] SPARC64: immediate segfault on startup with git mastervery

[Mark Cave-Ayland]

Hi Avi/Blue,

I've just updated to git master and found that SPARC64 is broken again; 
a git bisect shows the following commit causes this:


commit f3705d53296d78b14f5823472ae2add16a25a0a5
Author: Avi Kivity <avi@redhat.com>
Date:   Thu Mar 8 16:16:34 2012 +0200

     memory: make phys_page_find() return an unadjusted section

     We'd like to store the section index in the iotlb, so we can't
     adjust it before returning.  Return an unadjusted section and
     instead introduce section_addr(), which does the adjustment later.

     Signed-off-by: Avi Kivity <avi@redhat.com>


The symptom is that qemu-system-sparc64 segfaults immediately on startup 
(note this is with an OpenBIOS image built from SVN r1048). I've 
included a couple of backtraces below:


 From commit f3705d53296d78b14f5823472ae2add16a25a0a5 (first bad commit 
above):


build@kentang:~/rel-qemu-git/bin$ gdb --args ./qemu-system-sparc64 
-cdrom /home/build/src/qemu/sparcimage/milax032sparc.iso -bios 
/home/build/src/openbios/openbios-git/openbios-devel/obj-sparc64/openbios-builtin.elf.nostrip 
-nographic -boot d
GNU gdb (GDB) 7.0.1-debian
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from 
/home/build/rel-qemu-git/bin/qemu-system-sparc64...done.
(gdb) run
Starting program: /home/build/rel-qemu-git/bin/qemu-system-sparc64 
-cdrom /home/build/src/qemu/sparcimage/milax032sparc.iso -bios 
/home/build/src/openbios/openbios-git/openbios-devel/obj-sparc64/openbios-builtin.elf.nostrip 
-nographic -boot d
[Thread debugging using libthread_db enabled]
[New Thread 0x7ffff4aab700 (LWP 17836)]
[New Thread 0x7ffff42aa700 (LWP 17837)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff42aa700 (LWP 17837)]
0x00000000005e2d3a in memory_region_access_valid (mr=0x0, 
addr=134217936, size=4, is_write=true) at 
/home/build/src/qemu/git/qemu/memory.c:838
838         if (mr->ops->valid.accepts
(gdb) bt
#0  0x00000000005e2d3a in memory_region_access_valid (mr=0x0, 
addr=134217936, size=4, is_write=true) at 
/home/build/src/qemu/git/qemu/memory.c:838
#1  0x00000000005e3039 in memory_region_dispatch_write (mr=0x0, 
addr=134217936, data=0, size=4) at 
/home/build/src/qemu/git/qemu/memory.c:916
#2  0x00000000005e5bdb in io_mem_write (io_index=210, addr=134217936, 
val=0, size=4) at /home/build/src/qemu/git/qemu/memory.c:1512
#3  0x00000000005f22fa in io_writeq (physaddr=134217936, val=0, 
addr=134217936, retaddr=0x40001750)
     at /home/build/src/qemu/git/qemu/softmmu_template.h:226
#4  0x00000000005f241c in __stq_mmu (addr=134217936, val=0, mmu_idx=2) 
at /home/build/src/qemu/git/qemu/softmmu_template.h:255
#5  0x0000000040001751 in ?? ()
#6  0x00000000f42a9960 in ?? ()
#7  0x932e4434f5713900 in ?? ()
#8  0x00007ffff42a9980 in ?? ()
#9  0x00000000005fe62e in tcg_out_branch (s=Cannot access memory at 
address 0x7ffffd8
) at /home/build/src/qemu/git/qemu/tcg/i386/tcg-target.c:948
Backtrace stopped: previous frame inner to this frame (corrupt stack?)


Interestingly enough, git master 
(361dea401f529fc136aaeb49c82b2a5bb7faa316) now gives a different backtrace:


build@kentang:~/rel-qemu-git/bin$ gdb --args ./qemu-system-sparc64 
-cdrom /home/build/src/qemu/sparcimage/milax032sparc.iso -bios 
/home/build/src/openbios/openbios-git/openbios-devel/obj-sparc64/openbios-builtin.elf.nostrip 
-nographic -boot d
GNU gdb (GDB) 7.0.1-debian
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from 
/home/build/rel-qemu-git/bin/qemu-system-sparc64...done.
(gdb) run
Starting program: /home/build/rel-qemu-git/bin/qemu-system-sparc64 
-cdrom /home/build/src/qemu/sparcimage/milax032sparc.iso -bios 
/home/build/src/openbios/openbios-git/openbios-devel/obj-sparc64/openbios-builtin.elf.nostrip 
-nographic -boot d
[Thread debugging using libthread_db enabled]
[New Thread 0x7ffff4aab700 (LWP 32400)]
[New Thread 0x7ffff42aa700 (LWP 32401)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff42aa700 (LWP 32401)]
0x00000000005b7173 in get_page_addr_code (env1=0x11f0730, 
addr=2198754820128) at /home/build/src/qemu/git/qemu/exec.c:4602
4602        if (mr != &io_mem_ram && mr != &io_mem_rom
(gdb) bt
#0  0x00000000005b7173 in get_page_addr_code (env1=0x11f0730, 
addr=2198754820128) at /home/build/src/qemu/git/qemu/exec.c:4602
#1  0x00000000005a7f92 in tb_find_slow (env=0x11f0730, pc=2198754820128, 
cs_base=2198754820132, flags=1284)
     at /home/build/src/qemu/git/qemu/cpu-exec.c:95
#2  0x00000000005a821e in tb_find_fast (env=0x11f0730) at 
/home/build/src/qemu/git/qemu/cpu-exec.c:151
#3  0x00000000005a865f in cpu_sparc_exec (env=0x11f0730) at 
/home/build/src/qemu/git/qemu/cpu-exec.c:532
#4  0x00000000005abe3b in tcg_cpu_exec (env=0x11f0730) at 
/home/build/src/qemu/git/qemu/cpus.c:1022
#5  0x00000000005abf48 in tcg_exec_all () at 
/home/build/src/qemu/git/qemu/cpus.c:1054
#6  0x00000000005ab552 in qemu_tcg_cpu_thread_fn (arg=0x11f0730) at 
/home/build/src/qemu/git/qemu/cpus.c:772
#7  0x00007ffff6e458ca in start_thread (arg=<value optimized out>) at 
pthread_create.c:300
#8  0x00007ffff6bac92d in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#9  0x0000000000000000 in ?? ()
(gdb)


Many thanks,

Mark.

Re: [Qemu-devel] SPARC64: immediate segfault on startup with git mastervery

[Avi Kivity]

[-- Attachment #1: Type: text/plain, Size: 1004 bytes --]

On 03/18/2012 04:01 AM, Mark Cave-Ayland wrote:
> Hi Avi/Blue,
>
> I've just updated to git master and found that SPARC64 is broken
> again; a git bisect shows the following commit causes this:
>
>
> commit f3705d53296d78b14f5823472ae2add16a25a0a5
> Author: Avi Kivity <avi@redhat.com>
> Date:   Thu Mar 8 16:16:34 2012 +0200
>
>     memory: make phys_page_find() return an unadjusted section
>
>     We'd like to store the section index in the iotlb, so we can't
>     adjust it before returning.  Return an unadjusted section and
>     instead introduce section_addr(), which does the adjustment later.
>
>     Signed-off-by: Avi Kivity <avi@redhat.com>
>
>
> The symptom is that qemu-system-sparc64 segfaults immediately on
> startup (note this is with an OpenBIOS image built from SVN r1048).
> I've included a couple of backtraces below:
>

Please try the attached patch.

If it fails, can you upload bios and disk images somewhere?

-- 
error compiling committee.c: too many arguments to function


[-- Attachment #2: 0001-sparc64-trim-low-order-bits-from-TLB-entry-during-MM.patch --]
[-- Type: text/x-patch, Size: 1450 bytes --]

>From d1429f0bef16eb850a4ccc879cdc2212b41da40c Mon Sep 17 00:00:00 2001
From: Avi Kivity <avi@redhat.com>
Date: Sun, 18 Mar 2012 11:42:00 +0200
Subject: [PATCH] sparc64: trim low-order bits from TLB entry during MMU
 translation

get_physical_address() returns a physical address with random low bits
set, which confuses tlb_set_page().  Fix by masking the low-order bits.

Signed-off-by: Avi Kivity <avi@redhat.com>
---
 target-sparc/mmu_helper.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/target-sparc/mmu_helper.c b/target-sparc/mmu_helper.c
index 11fb9f5..27f7b27 100644
--- a/target-sparc/mmu_helper.c
+++ b/target-sparc/mmu_helper.c
@@ -491,7 +491,7 @@ static int get_physical_address_data(CPUSPARCState *env,
                    mmu_idx == MMU_USER_SECONDARY_IDX);
 
     if ((env->lsu & DMMU_E) == 0) { /* DMMU disabled */
-        *physical = ultrasparc_truncate_physical(address);
+        *physical = ultrasparc_truncate_physical(address) & TARGET_PAGE_MASK;
         *prot = PAGE_READ | PAGE_WRITE;
         return 0;
     }
@@ -610,7 +610,7 @@ static int get_physical_address_code(CPUSPARCState *env,
 
     if ((env->lsu & IMMU_E) == 0 || (env->pstate & PS_RED) != 0) {
         /* IMMU disabled */
-        *physical = ultrasparc_truncate_physical(address);
+        *physical = ultrasparc_truncate_physical(address) & TARGET_PAGE_MASK;
         *prot = PAGE_EXEC;
         return 0;
     }
-- 
1.7.9

Re: [Qemu-devel] SPARC64: immediate segfault on startup with git mastervery

[Blue Swirl]

On Sun, Mar 18, 2012 at 09:44, Avi Kivity <avi@redhat.com> wrote:
> On 03/18/2012 04:01 AM, Mark Cave-Ayland wrote:
>> Hi Avi/Blue,
>>
>> I've just updated to git master and found that SPARC64 is broken
>> again; a git bisect shows the following commit causes this:
>>
>>
>> commit f3705d53296d78b14f5823472ae2add16a25a0a5
>> Author: Avi Kivity <avi@redhat.com>
>> Date:   Thu Mar 8 16:16:34 2012 +0200
>>
>>     memory: make phys_page_find() return an unadjusted section
>>
>>     We'd like to store the section index in the iotlb, so we can't
>>     adjust it before returning.  Return an unadjusted section and
>>     instead introduce section_addr(), which does the adjustment later.
>>
>>     Signed-off-by: Avi Kivity <avi@redhat.com>
>>
>>
>> The symptom is that qemu-system-sparc64 segfaults immediately on
>> startup (note this is with an OpenBIOS image built from SVN r1048).
>> I've included a couple of backtraces below:
>>
>
> Please try the attached patch.

I tried this approach instead, seems to work (except Sparc32, Sparc64
and PPC displays are still not refreshed correctly). The problem is
that f3705d53296d78b14f5823472ae2add16a25a0a5 converted addr & mask +
section.offset to section_addr(), but in some cases the offset within
page was not wanted.

diff --git a/exec.c b/exec.c
index 8fd50a1..ad455be 100644
--- a/exec.c
+++ b/exec.c
@@ -1474,8 +1474,8 @@ static void breakpoint_invalidate(CPUArchState
*env, target_ulong pc)
           || (section->mr->rom_device && section->mr->readable))) {
         return;
     }
-    ram_addr = (memory_region_get_ram_addr(section->mr) & TARGET_PAGE_MASK)
-        + section_addr(section, addr);
+    ram_addr = (memory_region_get_ram_addr(section->mr)
+                + section_addr(section, pc)) & TARGET_PAGE_MASK;
     tb_invalidate_phys_page_range(ram_addr, ram_addr + 1, 0);
 }
 #endif
@@ -2205,14 +2205,14 @@ void tlb_set_page(CPUArchState *env, target_ulong vaddr,
     }
     if (is_ram_rom_romd(section)) {
         addend = (unsigned long)memory_region_get_ram_ptr(section->mr)
-                                 + section_addr(section, paddr);
+                 + section_addr(section, paddr & TARGET_PAGE_MASK);
     } else {
         addend = 0;
     }
     if (is_ram_rom(section)) {
         /* Normal RAM.  */
-        iotlb = (memory_region_get_ram_addr(section->mr) & TARGET_PAGE_MASK)
-            + section_addr(section, paddr);
+        iotlb = (memory_region_get_ram_addr(section->mr)
+                 + section_addr(section, paddr)) & TARGET_PAGE_MASK;
         if (!section->readonly)
             iotlb |= phys_section_notdirty;
         else
@@ -2225,7 +2225,7 @@ void tlb_set_page(CPUArchState *env, target_ulong vaddr,
            We can't use the high bits of pd for this because
            IO_MEM_ROMD uses these as a ram address.  */
         iotlb = section - phys_sections;
-        iotlb += section_addr(section, paddr);
+        iotlb += section_addr(section, paddr & TARGET_PAGE_MASK);
     }

     code_address = address;
@@ -2265,7 +2265,7 @@ void tlb_set_page(CPUArchState *env, target_ulong vaddr,
         } else if (memory_region_is_ram(section->mr)
                    && !cpu_physical_memory_is_dirty(
                            section->mr->ram_addr
-                           + section_addr(section, paddr))) {
+                           + section_addr(section, paddr &
TARGET_PAGE_MASK))) {
             te->addr_write = address | TLB_NOTDIRTY;
         } else {
             te->addr_write = address;



> If it fails, can you upload bios and disk images somewhere?
>
> --
> error compiling committee.c: too many arguments to function
>

Re: [Qemu-devel] SPARC64: immediate segfault on startup with git mastervery

[Blue Swirl]

On Sun, Mar 18, 2012 at 09:44, Avi Kivity <avi@redhat.com> wrote:
> On 03/18/2012 04:01 AM, Mark Cave-Ayland wrote:
>> Hi Avi/Blue,
>>
>> I've just updated to git master and found that SPARC64 is broken
>> again; a git bisect shows the following commit causes this:
>>
>>
>> commit f3705d53296d78b14f5823472ae2add16a25a0a5
>> Author: Avi Kivity <avi@redhat.com>
>> Date:   Thu Mar 8 16:16:34 2012 +0200
>>
>>     memory: make phys_page_find() return an unadjusted section
>>
>>     We'd like to store the section index in the iotlb, so we can't
>>     adjust it before returning.  Return an unadjusted section and
>>     instead introduce section_addr(), which does the adjustment later.
>>
>>     Signed-off-by: Avi Kivity <avi@redhat.com>
>>
>>
>> The symptom is that qemu-system-sparc64 segfaults immediately on
>> startup (note this is with an OpenBIOS image built from SVN r1048).
>> I've included a couple of backtraces below:
>>
>
> Please try the attached patch.

That works too.

> If it fails, can you upload bios and disk images somewhere?
>
> --
> error compiling committee.c: too many arguments to function
>

Re: [Qemu-devel] SPARC64: immediate segfault on startup with git mastervery

[Mark Cave-Ayland]

On 18/03/12 09:44, Avi Kivity wrote:

>> Hi Avi/Blue,
>>
>> I've just updated to git master and found that SPARC64 is broken
>> again; a git bisect shows the following commit causes this:
>>
>>
>> commit f3705d53296d78b14f5823472ae2add16a25a0a5
>> Author: Avi Kivity<avi@redhat.com>
>> Date:   Thu Mar 8 16:16:34 2012 +0200
>>
>>      memory: make phys_page_find() return an unadjusted section
>>
>>      We'd like to store the section index in the iotlb, so we can't
>>      adjust it before returning.  Return an unadjusted section and
>>      instead introduce section_addr(), which does the adjustment later.
>>
>>      Signed-off-by: Avi Kivity<avi@redhat.com>
>>
>>
>> The symptom is that qemu-system-sparc64 segfaults immediately on
>> startup (note this is with an OpenBIOS image built from SVN r1048).
>> I've included a couple of backtraces below:
>>
>
> Please try the attached patch.
>
> If it fails, can you upload bios and disk images somewhere?

Hi Avi/Blue,

I can confirm that both patches work for me and enable SPARC64 to boot - 
Blue, what is the VGA display issue that you mention? I didn't see any 
display corruption when testing on both SPARC64 and PPC.

Upon inspection I see that Blue's patch seems to be a more of a global 
fix, whereas Avi's seems restricted to SPARC. Does that make Blue's 
patch a "better" solution since it will resolve the same undiscovered 
issue in other targets that make the same assumption?


Many thanks,

Mark.

Re: [Qemu-devel] SPARC64: immediate segfault on startup with git mastervery

[Avi Kivity]

On 03/18/2012 11:51 AM, Blue Swirl wrote:
> On Sun, Mar 18, 2012 at 09:44, Avi Kivity <avi@redhat.com> wrote:
> > On 03/18/2012 04:01 AM, Mark Cave-Ayland wrote:
> >> Hi Avi/Blue,
> >>
> >> I've just updated to git master and found that SPARC64 is broken
> >> again; a git bisect shows the following commit causes this:
> >>
> >>
> >> commit f3705d53296d78b14f5823472ae2add16a25a0a5
> >> Author: Avi Kivity <avi@redhat.com>
> >> Date:   Thu Mar 8 16:16:34 2012 +0200
> >>
> >>     memory: make phys_page_find() return an unadjusted section
> >>
> >>     We'd like to store the section index in the iotlb, so we can't
> >>     adjust it before returning.  Return an unadjusted section and
> >>     instead introduce section_addr(), which does the adjustment later.
> >>
> >>     Signed-off-by: Avi Kivity <avi@redhat.com>
> >>
> >>
> >> The symptom is that qemu-system-sparc64 segfaults immediately on
> >> startup (note this is with an OpenBIOS image built from SVN r1048).
> >> I've included a couple of backtraces below:
> >>
> >
> > Please try the attached patch.
>
> I tried this approach instead, seems to work 

IMO, my patch is better.  tlb_set_page() should not deal with offsets
within a page.

If you prefer your approach, I suggest masking the address up front in
the beginning of tlb_set_page() instead.

> (except Sparc32, Sparc64
> and PPC displays are still not refreshed correctly).

Details about this please.


-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] SPARC64: immediate segfault on startup with git mastervery

[Blue Swirl]

On Sun, Mar 18, 2012 at 10:31, Avi Kivity <avi@redhat.com> wrote:
> On 03/18/2012 11:51 AM, Blue Swirl wrote:
>> On Sun, Mar 18, 2012 at 09:44, Avi Kivity <avi@redhat.com> wrote:
>> > On 03/18/2012 04:01 AM, Mark Cave-Ayland wrote:
>> >> Hi Avi/Blue,
>> >>
>> >> I've just updated to git master and found that SPARC64 is broken
>> >> again; a git bisect shows the following commit causes this:
>> >>
>> >>
>> >> commit f3705d53296d78b14f5823472ae2add16a25a0a5
>> >> Author: Avi Kivity <avi@redhat.com>
>> >> Date:   Thu Mar 8 16:16:34 2012 +0200
>> >>
>> >>     memory: make phys_page_find() return an unadjusted section
>> >>
>> >>     We'd like to store the section index in the iotlb, so we can't
>> >>     adjust it before returning.  Return an unadjusted section and
>> >>     instead introduce section_addr(), which does the adjustment later.
>> >>
>> >>     Signed-off-by: Avi Kivity <avi@redhat.com>
>> >>
>> >>
>> >> The symptom is that qemu-system-sparc64 segfaults immediately on
>> >> startup (note this is with an OpenBIOS image built from SVN r1048).
>> >> I've included a couple of backtraces below:
>> >>
>> >
>> > Please try the attached patch.
>>
>> I tried this approach instead, seems to work
>
> IMO, my patch is better.  tlb_set_page() should not deal with offsets
> within a page.

It looks like all targets except Sparc32/64 mask the addresses before
passing to tlb_set_page(), so I agree.

> If you prefer your approach, I suggest masking the address up front in
> the beginning of tlb_set_page() instead.
>
>> (except Sparc32, Sparc64
>> and PPC displays are still not refreshed correctly).
>
> Details about this please.

Screen is not updated correctly, there are lines from previous
screenful. Pressing ctrl-alt-1 refreshes the display. Perhaps dirty
tracking is broken? VGA in x86 works.

>
> --
> error compiling committee.c: too many arguments to function
>

Re: [Qemu-devel] SPARC64: immediate segfault on startup with git mastervery

[Mark Cave-Ayland]

On 18/03/12 10:51, Blue Swirl wrote:

>>> (except Sparc32, Sparc64
>>> and PPC displays are still not refreshed correctly).
>>
>> Details about this please.
>
> Screen is not updated correctly, there are lines from previous
> screenful. Pressing ctrl-alt-1 refreshes the display. Perhaps dirty
> tracking is broken? VGA in x86 works.

Is that using SDL? Do you see the same issue with VNC too?


ATB,

Mark.

Re: [Qemu-devel] SPARC64: immediate segfault on startup with git mastervery

[Blue Swirl]

On Sun, Mar 18, 2012 at 11:03, Mark Cave-Ayland
<mark.cave-ayland@ilande.co.uk> wrote:
> On 18/03/12 10:51, Blue Swirl wrote:
>
>>>> (except Sparc32, Sparc64
>>>> and PPC displays are still not refreshed correctly).
>>>
>>>
>>> Details about this please.
>>
>>
>> Screen is not updated correctly, there are lines from previous
>> screenful. Pressing ctrl-alt-1 refreshes the display. Perhaps dirty
>> tracking is broken? VGA in x86 works.
>
>
> Is that using SDL? Do you see the same issue with VNC too?

Yes to both.

>
>
> ATB,
>
> Mark.

Re: [Qemu-devel] SPARC64: immediate segfault on startup with git mastervery

[Avi Kivity]

On 03/18/2012 12:51 PM, Blue Swirl wrote:
> >
> > IMO, my patch is better.  tlb_set_page() should not deal with offsets
> > within a page.
>
> It looks like all targets except Sparc32/64 mask the addresses before
> passing to tlb_set_page(), so I agree.

Ok.  Commit my patch then?

> > If you prefer your approach, I suggest masking the address up front in
> > the beginning of tlb_set_page() instead.
> >
> >> (except Sparc32, Sparc64
> >> and PPC displays are still not refreshed correctly).
> >
> > Details about this please.
>
> Screen is not updated correctly, there are lines from previous
> screenful. Pressing ctrl-alt-1 refreshes the display. Perhaps dirty
> tracking is broken? VGA in x86 works.

Ok, I see it.  Will investigate.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] SPARC64: immediate segfault on startup with git mastervery

[Blue Swirl]

On Sun, Mar 18, 2012 at 12:08, Avi Kivity <avi@redhat.com> wrote:
> On 03/18/2012 12:51 PM, Blue Swirl wrote:
>> >
>> > IMO, my patch is better.  tlb_set_page() should not deal with offsets
>> > within a page.
>>
>> It looks like all targets except Sparc32/64 mask the addresses before
>> passing to tlb_set_page(), so I agree.
>
> Ok.  Commit my patch then?

I sent a different patch which masks incoming address earlier and
removes unnecessary masking in other places.

>> > If you prefer your approach, I suggest masking the address up front in
>> > the beginning of tlb_set_page() instead.
>> >
>> >> (except Sparc32, Sparc64
>> >> and PPC displays are still not refreshed correctly).
>> >
>> > Details about this please.
>>
>> Screen is not updated correctly, there are lines from previous
>> screenful. Pressing ctrl-alt-1 refreshes the display. Perhaps dirty
>> tracking is broken? VGA in x86 works.
>
> Ok, I see it.  Will investigate.
>
> --
> error compiling committee.c: too many arguments to function
>

Re: [Qemu-devel] SPARC64: immediate segfault on startup with git mastervery

[Avi Kivity]

On 03/18/2012 02:10 PM, Blue Swirl wrote:
> On Sun, Mar 18, 2012 at 12:08, Avi Kivity <avi@redhat.com> wrote:
> > On 03/18/2012 12:51 PM, Blue Swirl wrote:
> >> >
> >> > IMO, my patch is better.  tlb_set_page() should not deal with offsets
> >> > within a page.
> >>
> >> It looks like all targets except Sparc32/64 mask the addresses before
> >> passing to tlb_set_page(), so I agree.
> >
> > Ok.  Commit my patch then?
>
> I sent a different patch which masks incoming address earlier and
> removes unnecessary masking in other places.

My patch missed the "boot mode" thing.  Does your patch fix it?

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] SPARC64: immediate segfault on startup with git mastervery

[Blue Swirl]

On Sun, Mar 18, 2012 at 12:13, Avi Kivity <avi@redhat.com> wrote:
> On 03/18/2012 02:10 PM, Blue Swirl wrote:
>> On Sun, Mar 18, 2012 at 12:08, Avi Kivity <avi@redhat.com> wrote:
>> > On 03/18/2012 12:51 PM, Blue Swirl wrote:
>> >> >
>> >> > IMO, my patch is better.  tlb_set_page() should not deal with offsets
>> >> > within a page.
>> >>
>> >> It looks like all targets except Sparc32/64 mask the addresses before
>> >> passing to tlb_set_page(), so I agree.
>> >
>> > Ok.  Commit my patch then?
>>
>> I sent a different patch which masks incoming address earlier and
>> removes unnecessary masking in other places.
>
> My patch missed the "boot mode" thing.  Does your patch fix it?

Yes. I also fixed both Sparc32 (which didn't have problems) and Sparc64.

>
> --
> error compiling committee.c: too many arguments to function
>

Re: [Qemu-devel] SPARC64: immediate segfault on startup with git mastervery

[Avi Kivity]

[-- Attachment #1: Type: text/plain, Size: 523 bytes --]

On 03/18/2012 02:08 PM, Avi Kivity wrote:
> >
> > Screen is not updated correctly, there are lines from previous
> > screenful. Pressing ctrl-alt-1 refreshes the display. Perhaps dirty
> > tracking is broken? VGA in x86 works.
>
> Ok, I see it.  Will investigate.
>

Turns out it's a latent bug in qemu exposed by the memory patches.  I
already had a fix in my tree (though of course I had no memory of this
when debugging).

Please try the attached patch.

-- 
error compiling committee.c: too many arguments to function


[-- Attachment #2: 0001-exec-fix-write-tlb-entry-misused-as-iotlb.patch --]
[-- Type: text/x-patch, Size: 2073 bytes --]

>From bb363db2608dfc9b49b53994dc20d68169e66774 Mon Sep 17 00:00:00 2001
From: Avi Kivity <avi@redhat.com>
Date: Wed, 14 Mar 2012 16:19:39 +0200
Subject: [PATCH] exec: fix write tlb entry misused as iotlb

A couple of code paths check the lower bits of CPUTLBEntry::addr_write
against io_mem_ram as a way of looking for a dirty RAM page.  This works
by accident since the value is zero, which matches all clear bits for
TLB_INVALID, TLB_MMIO, and TLB_NOTDIRTY (indicating dirty RAM).

Make it work by design by checking for the proper bits.

Signed-off-by: Avi Kivity <avi@redhat.com>
---
 exec.c |   11 ++++++++---
 1 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/exec.c b/exec.c
index 8fd50a1..d8b089e 100644
--- a/exec.c
+++ b/exec.c
@@ -2031,14 +2031,19 @@ static void tlb_unprotect_code_phys(CPUArchState *env, ram_addr_t ram_addr,
     cpu_physical_memory_set_dirty_flags(ram_addr, CODE_DIRTY_FLAG);
 }
 
+static bool tlb_is_dirty_ram(CPUTLBEntry *tlbe)
+{
+    return (tlbe->addr_write & (TLB_INVALID_MASK|TLB_MMIO|TLB_NOTDIRTY)) == 0;
+}
+
 static inline void tlb_reset_dirty_range(CPUTLBEntry *tlb_entry,
                                          unsigned long start, unsigned long length)
 {
     unsigned long addr;
-    if ((tlb_entry->addr_write & ~TARGET_PAGE_MASK) == io_mem_ram.ram_addr) {
+    if (tlb_is_dirty_ram(tlb_entry)) {
         addr = (tlb_entry->addr_write & TARGET_PAGE_MASK) + tlb_entry->addend;
         if ((addr - start) < length) {
-            tlb_entry->addr_write = (tlb_entry->addr_write & TARGET_PAGE_MASK) | TLB_NOTDIRTY;
+            tlb_entry->addr_write |= TLB_NOTDIRTY;
         }
     }
 }
@@ -2091,7 +2096,7 @@ static inline void tlb_update_dirty(CPUTLBEntry *tlb_entry)
     ram_addr_t ram_addr;
     void *p;
 
-    if ((tlb_entry->addr_write & ~TARGET_PAGE_MASK) == io_mem_ram.ram_addr) {
+    if (tlb_is_dirty_ram(tlb_entry)) {
         p = (void *)(unsigned long)((tlb_entry->addr_write & TARGET_PAGE_MASK)
             + tlb_entry->addend);
         ram_addr = qemu_ram_addr_from_host_nofail(p);
-- 
1.7.9