[Qemu-devel] [PATCH] Allocate translation buffer before guest RAM, in case guest RAM is too large on 64 bit hosts

[Qemu-devel] [PATCH] Allocate translation buffer before guest RAM, in case guest RAM is too large on 64 bit hosts

[Juergen Lock]

Hi!

 The following patch appears to fix -m >= 1024 on recent FreeBSD/amd64 hosts
(RELENG_7/HEAD) that no longer return high addresses for allocations by
default (which was the original reason for r5331.)  As this makes sense
in any case when you pass something like -m 4096 on hosts that allocate
from low addresses by default (there would be no room left for the
translation buffer in the low vm where it needs to be), I patched it like
this instead of conditionalizing the mmap hack from r5331 on the FreeBSD
version.

Index: qemu/vl.c
@@ -9850,15 +9850,15 @@
         phys_ram_size += ram_size;
     }
 
+    /* init the dynamic translator */
+    cpu_exec_init_all(tb_size * 1024 * 1024);
+
     phys_ram_base = qemu_vmalloc(phys_ram_size);
     if (!phys_ram_base) {
         fprintf(stderr, "Could not allocate physical memory\n");
         exit(1);
     }
 
-    /* init the dynamic translator */
-    cpu_exec_init_all(tb_size * 1024 * 1024);
-
     bdrv_init(emulate_aio);
 
     /* we always create the cdrom drive, even if no disk is there */

Signed-off-by: Juergen Lock <nox@jelal.kn-bremen.de>

Re: [Qemu-devel] [PATCH] Allocate translation buffer before guest RAM, in case guest RAM is too large on 64 bit hosts

[Anthony Liguori]

Juergen Lock wrote:
> Hi!
>
>  The following patch appears to fix -m >= 1024 on recent FreeBSD/amd64 hosts
> (RELENG_7/HEAD) that no longer return high addresses for allocations by
> default (which was the original reason for r5331.)  As this makes sense
> in any case when you pass something like -m 4096 on hosts that allocate
> from low addresses by default (there would be no room left for the
> translation buffer in the low vm where it needs to be), I patched it like
> this instead of conditionalizing the mmap hack from r5331 on the FreeBSD
> version.
>   

I fear there is too much magic here.  Does FreeBSD not have a flag to 
mmap from high memory?  What is the the original problem?

Regards,

Anthony Liguori

> Index: qemu/vl.c
> @@ -9850,15 +9850,15 @@
>          phys_ram_size += ram_size;
>      }
>  
> +    /* init the dynamic translator */
> +    cpu_exec_init_all(tb_size * 1024 * 1024);
> +
>      phys_ram_base = qemu_vmalloc(phys_ram_size);
>      if (!phys_ram_base) {
>          fprintf(stderr, "Could not allocate physical memory\n");
>          exit(1);
>      }
>  
> -    /* init the dynamic translator */
> -    cpu_exec_init_all(tb_size * 1024 * 1024);
> -
>      bdrv_init(emulate_aio);
>  
>      /* we always create the cdrom drive, even if no disk is there */
>
> Signed-off-by: Juergen Lock <nox@jelal.kn-bremen.de>
>
>
>   

Re: [Qemu-devel] [PATCH] Allocate translation buffer before guest RAM, in case guest RAM is too large on 64 bit hosts

[Juergen Lock]

In article <48FDE6BA.4070102@codemonkey.ws> you write:
>Juergen Lock wrote:
>> Hi!
>>
>>  The following patch appears to fix -m >= 1024 on recent FreeBSD/amd64 hosts
>> (RELENG_7/HEAD) that no longer return high addresses for allocations by
>> default (which was the original reason for r5331.)  As this makes sense
>> in any case when you pass something like -m 4096 on hosts that allocate
>> from low addresses by default (there would be no room left for the
>> translation buffer in the low vm where it needs to be), I patched it like
>> this instead of conditionalizing the mmap hack from r5331 on the FreeBSD
>> version.
>>   
>
>I fear there is too much magic here.

Heh.

>  Does FreeBSD not have a flag to 
>mmap from high memory?

 I don't think so.

>  What is the the original problem?
>
 code_gen_buffer needs to be in the lower 4G (because of branches with
32 bit offsets etc.)

>Regards,
>
>Anthony Liguori

 Thanx,
	Juergen

Re: [Qemu-devel] [PATCH] Allocate translation buffer before guest RAM, in case guest RAM is too large on 64 bit hosts

[Anthony Liguori]

Juergen Lock wrote:
> In article <48FDE6BA.4070102@codemonkey.ws> you write:
>   
>> Juergen Lock wrote:
>>     
>>> Hi!
>>>
>>>  The following patch appears to fix -m >= 1024 on recent FreeBSD/amd64 hosts
>>> (RELENG_7/HEAD) that no longer return high addresses for allocations by
>>> default (which was the original reason for r5331.)  As this makes sense
>>> in any case when you pass something like -m 4096 on hosts that allocate
>>> from low addresses by default (there would be no room left for the
>>> translation buffer in the low vm where it needs to be), I patched it like
>>> this instead of conditionalizing the mmap hack from r5331 on the FreeBSD
>>> version.
>>>   
>>>       
>> I fear there is too much magic here.
>>     
>
> Heh.
>
>   
>>  Does FreeBSD not have a flag to 
>> mmap from high memory?
>>     
>
>  I don't think so.
>
>   
>>  What is the the original problem?
>>
>>     
>  code_gen_buffer needs to be in the lower 4G (because of branches with
> 32 bit offsets etc.)
>   

Can you resubmit the patch with a big comment explaining why the 
allocation order is important?

Regards,

Anthony Liguori

>> Regards,
>>
>> Anthony Liguori
>>     
>
>  Thanx,
> 	Juergen
>