[Qemu-devel] "Bad ram offset"?

[Qemu-devel] "Bad ram offset"?

[Artyom Tarasenko]

In today's git master:

$ ./qemu-system-sparc64 -M sun4u -m 2048
Bad ram offset ffffffff80000000
Aborted

$ ./qemu-system-sparc -M SS-20 -m 2048
Bad ram offset ffffffff80100000
Aborted

Is there a way to give guest 2GiB+ RAM? The host seems to have enough:

$ free
             total       used       free     shared    buffers     cached
Mem:       6117668    4508320    1609348          0       7876    3286208
-/+ buffers/cache:    1214236    4903432
Swap:       6553440          0     6553440

$ uname -a
Linux host 2.6.32.21-166.fc12.x86_64 #1 SMP Fri Aug 27 06:07:37 UTC
2010 x86_64 x86_64 x86_64 GNU/Linux

The configure script seems to realize that the host is 64 bit:
...
QEMU_CFLAGS       -Werror -m64 -Wtype-limits -Wold-style-definition
-Wold-style-declaration -Wignored-qualifiers -Winit-self -Wformat-y2k
-Wformat-security -Wnested-externs -Wempty-body -fstack-protector-all
-I. -I$(SRC_PATH) -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes
-Wredundant-decls -Wall -Wundef -Wendif-labels -Wwrite-strings
-Wmissing-prototypes -fno-strict-aliasing
LDFLAGS           -Wl,--warn-common -m64 -g
make              make
install           install
host CPU          x86_64
host big endian   no
target list       sparc-softmmu sparc64-softmmu
...
$  gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap
--enable-shared --enable-threads=posix --enable-checking=release
--with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada
--enable-java-awt=gtk --disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic
--with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.4.4 20100630 (Red Hat 4.4.4-10) (GCC)

-- 
Regards,
Artyom Tarasenko

solaris/sparc under qemu blog: http://tyom.blogspot.com/

[Qemu-devel] Re: "Bad ram offset"?

[Blue Swirl]

On Mon, Sep 27, 2010 at 9:19 PM, Artyom Tarasenko
<atar4qemu@googlemail.com> wrote:
> In today's git master:
>
> $ ./qemu-system-sparc64 -M sun4u -m 2048
> Bad ram offset ffffffff80000000

Smells like unwanted sign extension somewhere.

[Qemu-devel] Re: "Bad ram offset"?

[Artyom Tarasenko]

2010/9/28 Blue Swirl <blauwirbel@gmail.com>:
> On Mon, Sep 27, 2010 at 9:19 PM, Artyom Tarasenko
> <atar4qemu@googlemail.com> wrote:
>> In today's git master:
>>
>> $ ./qemu-system-sparc64 -M sun4u -m 2048
>> Bad ram offset ffffffff80000000
>
> Smells like unwanted sign extension somewhere.

fwiw, tested -m 2048 with i386 and x86-64 and they both are fine with
it. So it must be something platform-specific.


-- 
Regards,
Artyom Tarasenko

solaris/sparc under qemu blog: http://tyom.blogspot.com/

[Qemu-devel] Re: "Bad ram offset"?

[Blue Swirl]

On Tue, Sep 28, 2010 at 7:31 PM, Artyom Tarasenko
<atar4qemu@googlemail.com> wrote:
> 2010/9/28 Blue Swirl <blauwirbel@gmail.com>:
>> On Mon, Sep 27, 2010 at 9:19 PM, Artyom Tarasenko
>> <atar4qemu@googlemail.com> wrote:
>>> In today's git master:
>>>
>>> $ ./qemu-system-sparc64 -M sun4u -m 2048
>>> Bad ram offset ffffffff80000000
>>
>> Smells like unwanted sign extension somewhere.
>
> fwiw, tested -m 2048 with i386 and x86-64 and they both are fine with
> it. So it must be something platform-specific.

In a way, on SS-20 the problem is with cpu_physical_memory_write_rom
for idreg, which is at 0xef0000000. The sign extension happens in
qemu_get_ram_ptr() or just before that.

Here's my 'work in progress' patch:

diff --git a/exec.c b/exec.c
index 9b5464f..892aa06 100644
--- a/exec.c
+++ b/exec.c
@@ -154,7 +154,7 @@ typedef struct PageDesc {

 /* Size of the L2 (and L3, etc) page tables.  */
 #define L2_BITS 10
-#define L2_SIZE (1 << L2_BITS)
+#define L2_SIZE (1ULL << L2_BITS)

 /* The bits remaining after N lower levels of page tables.  */
 #define P_L1_BITS_REM \
@@ -432,7 +432,8 @@ static PhysPageDesc
*phys_page_find_alloc(target_phys_addr_t index, int alloc)

         for (i = 0; i < L2_SIZE; i++) {
             pd[i].phys_offset = IO_MEM_UNASSIGNED;
-            pd[i].region_offset = (index + i) << TARGET_PAGE_BITS;
+            pd[i].region_offset = (index + (target_phys_addr_t)i)
+                << TARGET_PAGE_BITS;
         }
     }

Re: [Qemu-devel] Re: "Bad ram offset"?

[Andreas Färber]

Am 28.09.2010 um 21:31 schrieb Artyom Tarasenko:

> 2010/9/28 Blue Swirl <blauwirbel@gmail.com>:
>> On Mon, Sep 27, 2010 at 9:19 PM, Artyom Tarasenko
>> <atar4qemu@googlemail.com> wrote:
>>> In today's git master:
>>>
>>> $ ./qemu-system-sparc64 -M sun4u -m 2048
>>> Bad ram offset ffffffff80000000
>>
>> Smells like unwanted sign extension somewhere.
>
> fwiw, tested -m 2048 with i386 and x86-64 and they both are fine with
> it. So it must be something platform-specific.

Same behavior on ppc host fwiw.

Andreas

Re: [Qemu-devel] Re: "Bad ram offset"?

[Blue Swirl]

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

On Tue, Sep 28, 2010 at 8:02 PM, Andreas Färber <andreas.faerber@web.de> wrote:
> Am 28.09.2010 um 21:31 schrieb Artyom Tarasenko:
>
>> 2010/9/28 Blue Swirl <blauwirbel@gmail.com>:
>>>
>>> On Mon, Sep 27, 2010 at 9:19 PM, Artyom Tarasenko
>>> <atar4qemu@googlemail.com> wrote:
>>>>
>>>> In today's git master:
>>>>
>>>> $ ./qemu-system-sparc64 -M sun4u -m 2048
>>>> Bad ram offset ffffffff80000000
>>>
>>> Smells like unwanted sign extension somewhere.
>>
>> fwiw, tested -m 2048 with i386 and x86-64 and they both are fine with
>> it. So it must be something platform-specific.
>
> Same behavior on ppc host fwiw.

The attached patch should fix this.

[-- Attachment #2: 0001-sysbus-fix-address-truncation.patch --]
[-- Type: application/mbox, Size: 1759 bytes --]

Re: [Qemu-devel] Re: "Bad ram offset"?

[Andreas Färber]

Am 28.09.2010 um 22:24 schrieb Blue Swirl:

> On Tue, Sep 28, 2010 at 8:02 PM, Andreas Färber <andreas.faerber@web.de 
> > wrote:
>> Am 28.09.2010 um 21:31 schrieb Artyom Tarasenko:
>>
>>> 2010/9/28 Blue Swirl <blauwirbel@gmail.com>:
>>>>
>>>> On Mon, Sep 27, 2010 at 9:19 PM, Artyom Tarasenko
>>>> <atar4qemu@googlemail.com> wrote:
>>>>>
>>>>> In today's git master:
>>>>>
>>>>> $ ./qemu-system-sparc64 -M sun4u -m 2048
>>>>> Bad ram offset ffffffff80000000
>>>>
>>>> Smells like unwanted sign extension somewhere.
>>>
>>> fwiw, tested -m 2048 with i386 and x86-64 and they both are fine  
>>> with
>>> it. So it must be something platform-specific.
>>
>> Same behavior on ppc host fwiw.
>
> The attached patch should fix this.
> <0001-sysbus-fix-address-truncation.patch>


Tested-by: Andreas Färber <andreas.faerber@web.de>

Above test cases work fine on ppc64 now. Anything else to cross-check?

Andreas

Re: [Qemu-devel] Re: "Bad ram offset"?

[Blue Swirl]

On Tue, Sep 28, 2010 at 8:42 PM, Andreas Färber <andreas.faerber@web.de> wrote:
> Am 28.09.2010 um 22:24 schrieb Blue Swirl:
>
>> On Tue, Sep 28, 2010 at 8:02 PM, Andreas Färber <andreas.faerber@web.de>
>> wrote:
>>>
>>> Am 28.09.2010 um 21:31 schrieb Artyom Tarasenko:
>>>
>>>> 2010/9/28 Blue Swirl <blauwirbel@gmail.com>:
>>>>>
>>>>> On Mon, Sep 27, 2010 at 9:19 PM, Artyom Tarasenko
>>>>> <atar4qemu@googlemail.com> wrote:
>>>>>>
>>>>>> In today's git master:
>>>>>>
>>>>>> $ ./qemu-system-sparc64 -M sun4u -m 2048
>>>>>> Bad ram offset ffffffff80000000
>>>>>
>>>>> Smells like unwanted sign extension somewhere.
>>>>
>>>> fwiw, tested -m 2048 with i386 and x86-64 and they both are fine with
>>>> it. So it must be something platform-specific.
>>>
>>> Same behavior on ppc host fwiw.
>>
>> The attached patch should fix this.
>> <0001-sysbus-fix-address-truncation.patch>
>
>
> Tested-by: Andreas Färber <andreas.faerber@web.de>
>
> Above test cases work fine on ppc64 now. Anything else to cross-check?

32 bit host, like ppc32 or x86?

Re: [Qemu-devel] Re: "Bad ram offset"?

[Artyom Tarasenko]

On Wed, Sep 29, 2010 at 6:09 PM, Blue Swirl <blauwirbel@gmail.com> wrote:
> On Tue, Sep 28, 2010 at 8:42 PM, Andreas Färber <andreas.faerber@web.de> wrote:
>> Am 28.09.2010 um 22:24 schrieb Blue Swirl:
>>
>>> On Tue, Sep 28, 2010 at 8:02 PM, Andreas Färber <andreas.faerber@web.de>
>>> wrote:
>>>>
>>>> Am 28.09.2010 um 21:31 schrieb Artyom Tarasenko:
>>>>
>>>>> 2010/9/28 Blue Swirl <blauwirbel@gmail.com>:
>>>>>>
>>>>>> On Mon, Sep 27, 2010 at 9:19 PM, Artyom Tarasenko
>>>>>> <atar4qemu@googlemail.com> wrote:
>>>>>>>
>>>>>>> In today's git master:
>>>>>>>
>>>>>>> $ ./qemu-system-sparc64 -M sun4u -m 2048
>>>>>>> Bad ram offset ffffffff80000000
>>>>>>
>>>>>> Smells like unwanted sign extension somewhere.
>>>>>
>>>>> fwiw, tested -m 2048 with i386 and x86-64 and they both are fine with
>>>>> it. So it must be something platform-specific.
>>>>
>>>> Same behavior on ppc host fwiw.
>>>
>>> The attached patch should fix this.
>>> <0001-sysbus-fix-address-truncation.patch>
>>
>>
>> Tested-by: Andreas Färber <andreas.faerber@web.de>
>>
>> Above test cases work fine on ppc64 now. Anything else to cross-check?
>
> 32 bit host, like ppc32 or x86?

Grr. I have only a cygwin x86 host, and it looks like testing on it is
a bad idea:

$ sparc-softmmu/qemu-system-sparc -M SS-10 -m 2112
qemu: at most 2047 MB RAM can be simulated

$ sparc64-softmmu/qemu-system-sparc64.exe  -m 2112
qemu: at most 2047 MB RAM can be simulated

$  uname -s -r -v -m -p -o
CYGWIN_NT-5.1 1.7.5(0.225/5/3) 2010-04-12 19:07 i686 unknown Cygwin

-- 
Regards,
Artyom Tarasenko

solaris/sparc under qemu blog: http://tyom.blogspot.com/

Re: [Qemu-devel] Re: "Bad ram offset"?

[Blue Swirl]

On Thu, Sep 30, 2010 at 8:36 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote:
> On Wed, Sep 29, 2010 at 6:09 PM, Blue Swirl <blauwirbel@gmail.com> wrote:
>> On Tue, Sep 28, 2010 at 8:42 PM, Andreas Färber <andreas.faerber@web.de> wrote:
>>> Am 28.09.2010 um 22:24 schrieb Blue Swirl:
>>>
>>>> On Tue, Sep 28, 2010 at 8:02 PM, Andreas Färber <andreas.faerber@web.de>
>>>> wrote:
>>>>>
>>>>> Am 28.09.2010 um 21:31 schrieb Artyom Tarasenko:
>>>>>
>>>>>> 2010/9/28 Blue Swirl <blauwirbel@gmail.com>:
>>>>>>>
>>>>>>> On Mon, Sep 27, 2010 at 9:19 PM, Artyom Tarasenko
>>>>>>> <atar4qemu@googlemail.com> wrote:
>>>>>>>>
>>>>>>>> In today's git master:
>>>>>>>>
>>>>>>>> $ ./qemu-system-sparc64 -M sun4u -m 2048
>>>>>>>> Bad ram offset ffffffff80000000
>>>>>>>
>>>>>>> Smells like unwanted sign extension somewhere.
>>>>>>
>>>>>> fwiw, tested -m 2048 with i386 and x86-64 and they both are fine with
>>>>>> it. So it must be something platform-specific.
>>>>>
>>>>> Same behavior on ppc host fwiw.
>>>>
>>>> The attached patch should fix this.
>>>> <0001-sysbus-fix-address-truncation.patch>
>>>
>>>
>>> Tested-by: Andreas Färber <andreas.faerber@web.de>
>>>
>>> Above test cases work fine on ppc64 now. Anything else to cross-check?
>>
>> 32 bit host, like ppc32 or x86?
>
> Grr. I have only a cygwin x86 host, and it looks like testing on it is
> a bad idea:
>
> $ sparc-softmmu/qemu-system-sparc -M SS-10 -m 2112
> qemu: at most 2047 MB RAM can be simulated
>
> $ sparc64-softmmu/qemu-system-sparc64.exe  -m 2112
> qemu: at most 2047 MB RAM can be simulated

Right, actually this should be the expected result for any 32 bit
host. I pushed the patch, thanks for reporting and testing!