[PATCH] fix -kernel option

[PATCH] fix -kernel option

[Glauber de Oliveira Costa]

Currently, the -kernel option is not working.

Reason is, because we're registering chunks for regions 0-0xa0000 and
0x100000-ram_size, the phys_ram_addr + PA is broken.
The real fix should be to rewrite all the load_linux() code to not rely
on this, but meanwhile, filling in the gap up to 0xc0000 - the beginning
of extended memory - makes it work again

Signed-off-by: Glauber de Oliveira Costa <gcosta-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
 qemu/hw/pc.c |   11 ++++++++---
 1 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/qemu/hw/pc.c b/qemu/hw/pc.c
index 6c71b09..e4a5f2d 100644
--- a/qemu/hw/pc.c
+++ b/qemu/hw/pc.c
@@ -725,13 +725,18 @@ static void pc_init1(ram_addr_t ram_size, int vga_ram_size, int boot_device,
 #ifdef USE_KVM
  #ifdef KVM_CAP_USER_MEMORY
     if (kvm_allowed && kvm_qemu_check_extension(KVM_CAP_USER_MEMORY)) {
+        ram_addr = qemu_ram_alloc(0xa0000);
+        cpu_register_physical_memory(0, 0xa0000, ram_addr);
+        kvm_cpu_register_physical_memory(0, 0xa0000, ram_addr);
+
+	/* move the pointer up to 0xc0000, which is the next
+           address we'll touch */
+        qemu_ram_alloc(0x20000);
+
         ram_addr = qemu_ram_alloc(ram_size - 0x100000);
         cpu_register_physical_memory(0x100000, ram_size - 0x100000, ram_addr);
         kvm_cpu_register_physical_memory(0x100000, ram_size - 0x100000,
                                          ram_addr);
-        ram_addr = qemu_ram_alloc(0xa0000);
-        cpu_register_physical_memory(0, 0xa0000, ram_addr);
-        kvm_cpu_register_physical_memory(0, 0xa0000, ram_addr);
     } else
  #endif
 #endif
-- 
1.5.0.6


-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

Re: [PATCH] fix -kernel option

[Anthony Liguori]

Glauber de Oliveira Costa wrote:
> Currently, the -kernel option is not working.
>
> Reason is, because we're registering chunks for regions 0-0xa0000 and
> 0x100000-ram_size, the phys_ram_addr + PA is broken.
>   

I think this patch is a reasonable work-around but the long term 
solution is probably going to have to be making sure that nothing makes 
the phys_ram_addr + PA assumption.  With > 4GB of memory, this 
assumption is broken because of the BIOS/PCI holes anyway.  I guess we 
could preserve this assumption though by burning some memory.

Thoughts?

Regards,

Anthony Liguori

> The real fix should be to rewrite all the load_linux() code to not rely
> on this, but meanwhile, filling in the gap up to 0xc0000 - the beginning
> of extended memory - makes it work again
>
> Signed-off-by: Glauber de Oliveira Costa <gcosta-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> ---
>  qemu/hw/pc.c |   11 ++++++++---
>  1 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/qemu/hw/pc.c b/qemu/hw/pc.c
> index 6c71b09..e4a5f2d 100644
> --- a/qemu/hw/pc.c
> +++ b/qemu/hw/pc.c
> @@ -725,13 +725,18 @@ static void pc_init1(ram_addr_t ram_size, int vga_ram_size, int boot_device,
>  #ifdef USE_KVM
>   #ifdef KVM_CAP_USER_MEMORY
>      if (kvm_allowed && kvm_qemu_check_extension(KVM_CAP_USER_MEMORY)) {
> +        ram_addr = qemu_ram_alloc(0xa0000);
> +        cpu_register_physical_memory(0, 0xa0000, ram_addr);
> +        kvm_cpu_register_physical_memory(0, 0xa0000, ram_addr);
> +
> +	/* move the pointer up to 0xc0000, which is the next
> +           address we'll touch */
> +        qemu_ram_alloc(0x20000);
> +
>          ram_addr = qemu_ram_alloc(ram_size - 0x100000);
>          cpu_register_physical_memory(0x100000, ram_size - 0x100000, ram_addr);
>          kvm_cpu_register_physical_memory(0x100000, ram_size - 0x100000,
>                                           ram_addr);
> -        ram_addr = qemu_ram_alloc(0xa0000);
> -        cpu_register_physical_memory(0, 0xa0000, ram_addr);
> -        kvm_cpu_register_physical_memory(0, 0xa0000, ram_addr);
>      } else
>   #endif
>  #endif
>   


-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

Re: [PATCH] fix -kernel option

[Izik Eidus]

Anthony Liguori wrote:
> Glauber de Oliveira Costa wrote:
>   
>> Currently, the -kernel option is not working.
>>
>> Reason is, because we're registering chunks for regions 0-0xa0000 and
>> 0x100000-ram_size, the phys_ram_addr + PA is broken.
>>   
>>     
>
> I think this patch is a reasonable work-around but the long term 
> solution is probably going to have to be making sure that nothing makes 
> the phys_ram_addr + PA assumption.  With > 4GB of memory, this 
> assumption is broken because of the BIOS/PCI holes anyway. 
we can always allocate 300 mbs of junk :)
but i agree with you, and i guess it is important to the dirty bit 
tracking that no one will touch this
memory without the formal functions anyway (at least for qemu)
>  I guess we 
> could preserve this assumption though by burning some memory.
>
> Thoughts?
>
> Regards,
>
> Anthony Liguori
>
>   
>> The real fix should be to rewrite all the load_linux() code to not rely
>> on this, but meanwhile, filling in the gap up to 0xc0000 - the beginning
>> of extended memory - makes it work again
>>
>> Signed-off-by: Glauber de Oliveira Costa <gcosta-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>> ---
>>  qemu/hw/pc.c |   11 ++++++++---
>>  1 files changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/qemu/hw/pc.c b/qemu/hw/pc.c
>> index 6c71b09..e4a5f2d 100644
>> --- a/qemu/hw/pc.c
>> +++ b/qemu/hw/pc.c
>> @@ -725,13 +725,18 @@ static void pc_init1(ram_addr_t ram_size, int vga_ram_size, int boot_device,
>>  #ifdef USE_KVM
>>   #ifdef KVM_CAP_USER_MEMORY
>>      if (kvm_allowed && kvm_qemu_check_extension(KVM_CAP_USER_MEMORY)) {
>> +        ram_addr = qemu_ram_alloc(0xa0000);
>> +        cpu_register_physical_memory(0, 0xa0000, ram_addr);
>> +        kvm_cpu_register_physical_memory(0, 0xa0000, ram_addr);
>> +
>> +	/* move the pointer up to 0xc0000, which is the next
>> +           address we'll touch */
>> +        qemu_ram_alloc(0x20000);
>> +
>>          ram_addr = qemu_ram_alloc(ram_size - 0x100000);
>>          cpu_register_physical_memory(0x100000, ram_size - 0x100000, ram_addr);
>>          kvm_cpu_register_physical_memory(0x100000, ram_size - 0x100000,
>>                                           ram_addr);
>> -        ram_addr = qemu_ram_alloc(0xa0000);
>> -        cpu_register_physical_memory(0, 0xa0000, ram_addr);
>> -        kvm_cpu_register_physical_memory(0, 0xa0000, ram_addr);
>>      } else
>>   #endif
>>  #endif
>>   
>>     
>
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> kvm-devel mailing list
> kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/kvm-devel
>   


-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

Re: [PATCH] fix -kernel option

[Anthony Liguori]

Izik Eidus wrote:
> Anthony Liguori wrote:
>> Glauber de Oliveira Costa wrote:
>>  
>>> Currently, the -kernel option is not working.
>>>
>>> Reason is, because we're registering chunks for regions 0-0xa0000 and
>>> 0x100000-ram_size, the phys_ram_addr + PA is broken.
>>>       
>>
>> I think this patch is a reasonable work-around but the long term 
>> solution is probably going to have to be making sure that nothing 
>> makes the phys_ram_addr + PA assumption.  With > 4GB of memory, this 
>> assumption is broken because of the BIOS/PCI holes anyway. 
> we can always allocate 300 mbs of junk :)

Well, it may not be so bad.  We can certainly malloc() those 300mbs.  
They'll never be touched by anyone so it doesn't actually increase the 
resident size.

> but i agree with you, and i guess it is important to the dirty bit 
> tracking that no one will touch this
> memory without the formal functions anyway (at least for qemu)

Yes, the only concern I have is that I really want to be able maintain 
that physically contiguous memory is virtually contiguous in QEMU.  This 
is an important assumption in virtio.  It's less important if 
phys_ram_base + PA works or not as long as that property is preserved.

Regards,

Anthony Liguori

>>  I guess we could preserve this assumption though by burning some 
>> memory.
>>
>> Thoughts?
>>
>> Regards,
>>
>> Anthony Liguori
>>
>>  
>>> The real fix should be to rewrite all the load_linux() code to not rely
>>> on this, but meanwhile, filling in the gap up to 0xc0000 - the 
>>> beginning
>>> of extended memory - makes it work again
>>>
>>> Signed-off-by: Glauber de Oliveira Costa <gcosta-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>>> ---
>>>  qemu/hw/pc.c |   11 ++++++++---
>>>  1 files changed, 8 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/qemu/hw/pc.c b/qemu/hw/pc.c
>>> index 6c71b09..e4a5f2d 100644
>>> --- a/qemu/hw/pc.c
>>> +++ b/qemu/hw/pc.c
>>> @@ -725,13 +725,18 @@ static void pc_init1(ram_addr_t ram_size, int 
>>> vga_ram_size, int boot_device,
>>>  #ifdef USE_KVM
>>>   #ifdef KVM_CAP_USER_MEMORY
>>>      if (kvm_allowed && 
>>> kvm_qemu_check_extension(KVM_CAP_USER_MEMORY)) {
>>> +        ram_addr = qemu_ram_alloc(0xa0000);
>>> +        cpu_register_physical_memory(0, 0xa0000, ram_addr);
>>> +        kvm_cpu_register_physical_memory(0, 0xa0000, ram_addr);
>>> +
>>> +    /* move the pointer up to 0xc0000, which is the next
>>> +           address we'll touch */
>>> +        qemu_ram_alloc(0x20000);
>>> +
>>>          ram_addr = qemu_ram_alloc(ram_size - 0x100000);
>>>          cpu_register_physical_memory(0x100000, ram_size - 0x100000, 
>>> ram_addr);
>>>          kvm_cpu_register_physical_memory(0x100000, ram_size - 
>>> 0x100000,
>>>                                           ram_addr);
>>> -        ram_addr = qemu_ram_alloc(0xa0000);
>>> -        cpu_register_physical_memory(0, 0xa0000, ram_addr);
>>> -        kvm_cpu_register_physical_memory(0, 0xa0000, ram_addr);
>>>      } else
>>>   #endif
>>>  #endif
>>>       
>>
>>
>> ------------------------------------------------------------------------- 
>>
>> SF.Net email is sponsored by:
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services for
>> just about anything Open Source.
>> http://sourceforge.net/services/buy/index.php
>> _______________________________________________
>> kvm-devel mailing list
>> kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>> https://lists.sourceforge.net/lists/listinfo/kvm-devel
>>   
>
>


-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

Re: [PATCH] fix -kernel option

[Izik Eidus]

Anthony Liguori wrote:
> Izik Eidus wrote:
>> Anthony Liguori wrote:
>>> Glauber de Oliveira Costa wrote:
>>>  
>>>> Currently, the -kernel option is not working.
>>>>
>>>> Reason is, because we're registering chunks for regions 0-0xa0000 and
>>>> 0x100000-ram_size, the phys_ram_addr + PA is broken.
>>>>       
>>>
>>> I think this patch is a reasonable work-around but the long term 
>>> solution is probably going to have to be making sure that nothing 
>>> makes the phys_ram_addr + PA assumption.  With > 4GB of memory, this 
>>> assumption is broken because of the BIOS/PCI holes anyway. 
>> we can always allocate 300 mbs of junk :)
>
> Well, it may not be so bad.  We can certainly malloc() those 300mbs.  
> They'll never be touched by anyone so it doesn't actually increase the 
> resident size.
>
>> but i agree with you, and i guess it is important to the dirty bit 
>> tracking that no one will touch this
>> memory without the formal functions anyway (at least for qemu)
>
> Yes, the only concern I have is that I really want to be able maintain 
> that physically contiguous memory is virtually contiguous in QEMU.  
> This is an important assumption in virtio.  It's less important if 
> phys_ram_base + PA works or not as long as that property is preserved.
well it already should be like that, any 
cpu_physical_memory_write/cpu_physical_memory_read, should go to vaild 
addresses
we had issue with older kvm userspace (below 52) that had such problem, 
and the dma in the rtl8139 card made the whole qemu to crush
when you ran it with above 4 giga,
now it look like everything is working fine, but if you see something 
please report :)
>
> Regards,
>
> Anthony Liguori
>
>>>  I guess we could preserve this assumption though by burning some 
>>> memory.
>>>
>>> Thoughts?
>>>
>>> Regards,
>>>
>>> Anthony Liguori
>>>
>>>  
>>>> The real fix should be to rewrite all the load_linux() code to not 
>>>> rely
>>>> on this, but meanwhile, filling in the gap up to 0xc0000 - the 
>>>> beginning
>>>> of extended memory - makes it work again
>>>>
>>>> Signed-off-by: Glauber de Oliveira Costa <gcosta-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>>>> ---
>>>>  qemu/hw/pc.c |   11 ++++++++---
>>>>  1 files changed, 8 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/qemu/hw/pc.c b/qemu/hw/pc.c
>>>> index 6c71b09..e4a5f2d 100644
>>>> --- a/qemu/hw/pc.c
>>>> +++ b/qemu/hw/pc.c
>>>> @@ -725,13 +725,18 @@ static void pc_init1(ram_addr_t ram_size, int 
>>>> vga_ram_size, int boot_device,
>>>>  #ifdef USE_KVM
>>>>   #ifdef KVM_CAP_USER_MEMORY
>>>>      if (kvm_allowed && 
>>>> kvm_qemu_check_extension(KVM_CAP_USER_MEMORY)) {
>>>> +        ram_addr = qemu_ram_alloc(0xa0000);
>>>> +        cpu_register_physical_memory(0, 0xa0000, ram_addr);
>>>> +        kvm_cpu_register_physical_memory(0, 0xa0000, ram_addr);
>>>> +
>>>> +    /* move the pointer up to 0xc0000, which is the next
>>>> +           address we'll touch */
>>>> +        qemu_ram_alloc(0x20000);
>>>> +
>>>>          ram_addr = qemu_ram_alloc(ram_size - 0x100000);
>>>>          cpu_register_physical_memory(0x100000, ram_size - 
>>>> 0x100000, ram_addr);
>>>>          kvm_cpu_register_physical_memory(0x100000, ram_size - 
>>>> 0x100000,
>>>>                                           ram_addr);
>>>> -        ram_addr = qemu_ram_alloc(0xa0000);
>>>> -        cpu_register_physical_memory(0, 0xa0000, ram_addr);
>>>> -        kvm_cpu_register_physical_memory(0, 0xa0000, ram_addr);
>>>>      } else
>>>>   #endif
>>>>  #endif
>>>>       
>>>
>>>
>>> ------------------------------------------------------------------------- 
>>>
>>> SF.Net email is sponsored by:
>>> Check out the new SourceForge.net Marketplace.
>>> It's the best place to buy or sell services for
>>> just about anything Open Source.
>>> http://sourceforge.net/services/buy/index.php
>>> _______________________________________________
>>> kvm-devel mailing list
>>> kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>>> https://lists.sourceforge.net/lists/listinfo/kvm-devel
>>>   
>>
>>
>


-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

Re: [PATCH] fix -kernel option

[Luca Tettamanti]

On Dec 7, 2007 7:38 PM, Anthony Liguori <anthony-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org> wrote:
> Izik Eidus wrote:
> > Anthony Liguori wrote:
> >> Glauber de Oliveira Costa wrote:
> >>
> >>> Currently, the -kernel option is not working.
> >>>
> >>> Reason is, because we're registering chunks for regions 0-0xa0000 and
> >>> 0x100000-ram_size, the phys_ram_addr + PA is broken.
> >>
> >> I think this patch is a reasonable work-around but the long term
> >> solution is probably going to have to be making sure that nothing
> >> makes the phys_ram_addr + PA assumption.  With > 4GB of memory, this
> >> assumption is broken because of the BIOS/PCI holes anyway.
> > we can always allocate 300 mbs of junk :)
>
> Well, it may not be so bad.  We can certainly malloc() those 300mbs.
> They'll never be touched by anyone so it doesn't actually increase the
> resident size.

Iff the host kernel is configured to overcommit memory.

Luca

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

Re: [PATCH] fix -kernel option

[Avi Kivity]

Anthony Liguori wrote:
> Glauber de Oliveira Costa wrote:
>   
>> Currently, the -kernel option is not working.
>>
>> Reason is, because we're registering chunks for regions 0-0xa0000 and
>> 0x100000-ram_size, the phys_ram_addr + PA is broken.
>>   
>>     
>
> I think this patch is a reasonable work-around but the long term 
> solution is probably going to have to be making sure that nothing makes 
> the phys_ram_addr + PA assumption.  With > 4GB of memory, this 
> assumption is broken because of the BIOS/PCI holes anyway.  I guess we 
> could preserve this assumption though by burning some memory.
>
>   

We don't need to burn the memory, you can munmap() the unneeded part
after allocating it.

Just make sure you don't touch it afterwards. We used this method in
previous versions, then moved to the current approach which is more
aligned with how qemu does things.


-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.


-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

Re: [PATCH] fix -kernel option

[Izik Eidus]

Glauber de Oliveira Costa wrote:
> Currently, the -kernel option is not working.
>
> Reason is, because we're registering chunks for regions 0-0xa0000 and
> 0x100000-ram_size, the phys_ram_addr + PA is broken.
> The real fix should be to rewrite all the load_linux() code to not rely
> on this, but meanwhile, filling in the gap up to 0xc0000 - the beginning
> of extended memory - makes it work again
>
> Signed-off-by: Glauber de Oliveira Costa <gcosta-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> ---
>  qemu/hw/pc.c |   11 ++++++++---
>  1 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/qemu/hw/pc.c b/qemu/hw/pc.c
> index 6c71b09..e4a5f2d 100644
> --- a/qemu/hw/pc.c
> +++ b/qemu/hw/pc.c
> @@ -725,13 +725,18 @@ static void pc_init1(ram_addr_t ram_size, int vga_ram_size, int boot_device,
>  #ifdef USE_KVM
>   #ifdef KVM_CAP_USER_MEMORY
>      if (kvm_allowed && kvm_qemu_check_extension(KVM_CAP_USER_MEMORY)) {
> +        ram_addr = qemu_ram_alloc(0xa0000);
> +        cpu_register_physical_memory(0, 0xa0000, ram_addr);
> +        kvm_cpu_register_physical_memory(0, 0xa0000, ram_addr);
> +
> +	/* move the pointer up to 0xc0000, which is the next
> +           address we'll touch */
> +        qemu_ram_alloc(0x20000);
>   
good catch!
> +
>          ram_addr = qemu_ram_alloc(ram_size - 0x100000);
>          cpu_register_physical_memory(0x100000, ram_size - 0x100000, ram_addr);
>          kvm_cpu_register_physical_memory(0x100000, ram_size - 0x100000,
>                                           ram_addr);
> -        ram_addr = qemu_ram_alloc(0xa0000);
> -        cpu_register_physical_memory(0, 0xa0000, ram_addr);
> -        kvm_cpu_register_physical_memory(0, 0xa0000, ram_addr);
>      } else
>   #endif
>  #endif
>   


-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

Re: [PATCH] fix -kernel option

[Dor Laor]

[-- Attachment #1.1: Type: text/plain, Size: 2508 bytes --]

Glauber de Oliveira Costa wrote:
>
> Currently, the -kernel option is not working.
>
> Reason is, because we're registering chunks for regions 0-0xa0000 and
> 0x100000-ram_size, the phys_ram_addr + PA is broken.
> The real fix should be to rewrite all the load_linux() code to not rely
> on this, but meanwhile, filling in the gap up to 0xc0000 - the beginning
> of extended memory - makes it work again
>
> Signed-off-by: Glauber de Oliveira Costa <gcosta-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> ---
>  qemu/hw/pc.c |   11 ++++++++---
>  1 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/qemu/hw/pc.c b/qemu/hw/pc.c
> index 6c71b09..e4a5f2d 100644
> --- a/qemu/hw/pc.c
> +++ b/qemu/hw/pc.c
> @@ -725,13 +725,18 @@ static void pc_init1(ram_addr_t ram_size, int 
> vga_ram_size, int boot_device,
>  #ifdef USE_KVM
>   #ifdef KVM_CAP_USER_MEMORY
>      if (kvm_allowed && kvm_qemu_check_extension(KVM_CAP_USER_MEMORY)) {
> +        ram_addr = qemu_ram_alloc(0xa0000);
> +        cpu_register_physical_memory(0, 0xa0000, ram_addr);
> +        kvm_cpu_register_physical_memory(0, 0xa0000, ram_addr);
> +
> +       /* move the pointer up to 0xc0000, which is the next
> +           address we'll touch */
> +        qemu_ram_alloc(0x20000);
>
It should be 0x60000 instead of 0x20000 since the code below should 
start at offset of
0x100000.
This finally solved my problem with running virtio using kvm, before it 
only worked for -no-kvm.
In general this fixes phys_mem_base + PA.

Regards,
Dor.
>
> +
>          ram_addr = qemu_ram_alloc(ram_size - 0x100000);
>          cpu_register_physical_memory(0x100000, ram_size - 0x100000, 
> ram_addr);
>          kvm_cpu_register_physical_memory(0x100000, ram_size - 0x100000,
>                                           ram_addr);
> -        ram_addr = qemu_ram_alloc(0xa0000);
> -        cpu_register_physical_memory(0, 0xa0000, ram_addr);
> -        kvm_cpu_register_physical_memory(0, 0xa0000, ram_addr);
>      } else
>   #endif
>  #endif
> --
> 1.5.0.6
>
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> kvm-devel mailing list
> kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/kvm-devel
>


[-- Attachment #1.2: Type: text/html, Size: 4556 bytes --]

[-- Attachment #2: Type: text/plain, Size: 277 bytes --]

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

[-- Attachment #3: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [PATCH] fix -kernel option

[Izik Eidus]

Dor Laor wrote:
> Glauber de Oliveira Costa wrote:
>>
>> Currently, the -kernel option is not working.
>>
>> Reason is, because we're registering chunks for regions 0-0xa0000 and
>> 0x100000-ram_size, the phys_ram_addr + PA is broken.
>> The real fix should be to rewrite all the load_linux() code to not rely
>> on this, but meanwhile, filling in the gap up to 0xc0000 - the beginning
>> of extended memory - makes it work again
>>
>> Signed-off-by: Glauber de Oliveira Costa <gcosta-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>> ---
>>  qemu/hw/pc.c |   11 ++++++++---
>>  1 files changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/qemu/hw/pc.c b/qemu/hw/pc.c
>> index 6c71b09..e4a5f2d 100644
>> --- a/qemu/hw/pc.c
>> +++ b/qemu/hw/pc.c
>> @@ -725,13 +725,18 @@ static void pc_init1(ram_addr_t ram_size, int 
>> vga_ram_size, int boot_device,
>>  #ifdef USE_KVM
>>   #ifdef KVM_CAP_USER_MEMORY
>>      if (kvm_allowed && kvm_qemu_check_extension(KVM_CAP_USER_MEMORY)) {
>> +        ram_addr = qemu_ram_alloc(0xa0000);
>> +        cpu_register_physical_memory(0, 0xa0000, ram_addr);
>> +        kvm_cpu_register_physical_memory(0, 0xa0000, ram_addr);
>> +
>> +       /* move the pointer up to 0xc0000, which is the next
>> +           address we'll touch */
>> +        qemu_ram_alloc(0x20000);
>>
> It should be 0x60000 instead of 0x20000 since the code below should 
> start at offset of
> 0x100000.
> This finally solved my problem with running virtio using kvm, before 
> it only worked for -no-kvm.
> In general this fixes phys_mem_base + PA.
>
> Regards,
> Dor.
you will get problems using virtio with above 4 giga as well in this case,
why not just using cpu_memory_write/cpu_memory_read??? (as i understand 
from how that cpu_register_physical_memory built this is the qemu way)

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

Re: [PATCH] fix -kernel option

[Glauber de Oliveira Costa]

Dor Laor wrote:
> Glauber de Oliveira Costa wrote:
>>
>> Currently, the -kernel option is not working.
>>
>> Reason is, because we're registering chunks for regions 0-0xa0000 and
>> 0x100000-ram_size, the phys_ram_addr + PA is broken.
>> The real fix should be to rewrite all the load_linux() code to not rely
>> on this, but meanwhile, filling in the gap up to 0xc0000 - the beginning
>> of extended memory - makes it work again
>>
>> Signed-off-by: Glauber de Oliveira Costa <gcosta-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>> ---
>>  qemu/hw/pc.c |   11 ++++++++---
>>  1 files changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/qemu/hw/pc.c b/qemu/hw/pc.c
>> index 6c71b09..e4a5f2d 100644
>> --- a/qemu/hw/pc.c
>> +++ b/qemu/hw/pc.c
>> @@ -725,13 +725,18 @@ static void pc_init1(ram_addr_t ram_size, int 
>> vga_ram_size, int boot_device,
>>  #ifdef USE_KVM
>>   #ifdef KVM_CAP_USER_MEMORY
>>      if (kvm_allowed && kvm_qemu_check_extension(KVM_CAP_USER_MEMORY)) {
>> +        ram_addr = qemu_ram_alloc(0xa0000);
>> +        cpu_register_physical_memory(0, 0xa0000, ram_addr);
>> +        kvm_cpu_register_physical_memory(0, 0xa0000, ram_addr);
>> +
>> +       /* move the pointer up to 0xc0000, which is the next
>> +           address we'll touch */
>> +        qemu_ram_alloc(0x20000);
>>
> It should be 0x60000 instead of 0x20000 since the code below should 
> start at offset of
> 0x100000.
> This finally solved my problem with running virtio using kvm, before it 
> only worked for -no-kvm.
> In general this fixes phys_mem_base + PA.
> 
I disagree. We allocate the piece 0xc0000 onwards a little bit later. So 
we only need to fill the gap 0xa0000 -> 0xc0000

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

Re: [PATCH] fix -kernel option

[Dor Laor]

[-- Attachment #1.1: Type: text/plain, Size: 2152 bytes --]

Glauber de Oliveira Costa wrote:
>
> Dor Laor wrote:
> > Glauber de Oliveira Costa wrote:
> >>
> >> Currently, the -kernel option is not working.
> >>
> >> Reason is, because we're registering chunks for regions 0-0xa0000 and
> >> 0x100000-ram_size, the phys_ram_addr + PA is broken.
> >> The real fix should be to rewrite all the load_linux() code to not rely
> >> on this, but meanwhile, filling in the gap up to 0xc0000 - the 
> beginning
> >> of extended memory - makes it work again
> >>
> >> Signed-off-by: Glauber de Oliveira Costa <gcosta-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> >> ---
> >>  qemu/hw/pc.c |   11 ++++++++---
> >>  1 files changed, 8 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/qemu/hw/pc.c b/qemu/hw/pc.c
> >> index 6c71b09..e4a5f2d 100644
> >> --- a/qemu/hw/pc.c
> >> +++ b/qemu/hw/pc.c
> >> @@ -725,13 +725,18 @@ static void pc_init1(ram_addr_t ram_size, int
> >> vga_ram_size, int boot_device,
> >>  #ifdef USE_KVM
> >>   #ifdef KVM_CAP_USER_MEMORY
> >>      if (kvm_allowed && 
> kvm_qemu_check_extension(KVM_CAP_USER_MEMORY)) {
> >> +        ram_addr = qemu_ram_alloc(0xa0000);
> >> +        cpu_register_physical_memory(0, 0xa0000, ram_addr);
> >> +        kvm_cpu_register_physical_memory(0, 0xa0000, ram_addr);
> >> +
> >> +       /* move the pointer up to 0xc0000, which is the next
> >> +           address we'll touch */
> >> +        qemu_ram_alloc(0x20000);
> >>
> > It should be 0x60000 instead of 0x20000 since the code below should
> > start at offset of
> > 0x100000.
> > This finally solved my problem with running virtio using kvm, before it
> > only worked for -no-kvm.
> > In general this fixes phys_mem_base + PA.
> >
> I disagree. We allocate the piece 0xc0000 onwards a little bit later. So
> we only need to fill the gap 0xa0000 -> 0xc0000
>
First it fixed the phys_mem_base + pa for virtio.
As Izike mentioned we should use standard qemu_rw_memory and not to 
access it directly.
Second, right after the 0x20000 allocation there is a call to
ram_addr = qemu_ram_alloc(ram_size - 0x100000);
So either don't call qemu_ram_alloc(0x20000) at all or call it with the 
right value.

Regards,
Dor

[-- Attachment #1.2: Type: text/html, Size: 3477 bytes --]

[-- Attachment #2: Type: text/plain, Size: 277 bytes --]

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

[-- Attachment #3: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [PATCH] fix -kernel option

[Uri Lublin]

Glauber de Oliveira Costa wrote:
> Currently, the -kernel option is not working.
>
> Reason is, because we're registering chunks for regions 0-0xa0000 and
> 0x100000-ram_size, the phys_ram_addr + PA is broken.
> The real fix should be to rewrite all the load_linux() code to not rely
> on this, but meanwhile, filling in the gap up to 0xc0000 - the beginning
> of extended memory - makes it work again
>
> Signed-off-by: Glauber de Oliveira Costa <gcosta-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> ---
>  qemu/hw/pc.c |   11 ++++++++---
>  1 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/qemu/hw/pc.c b/qemu/hw/pc.c
> index 6c71b09..e4a5f2d 100644
> --- a/qemu/hw/pc.c
> +++ b/qemu/hw/pc.c
> @@ -725,13 +725,18 @@ static void pc_init1(ram_addr_t ram_size, int vga_ram_size, int boot_device,
>  #ifdef USE_KVM
>   #ifdef KVM_CAP_USER_MEMORY
>      if (kvm_allowed && kvm_qemu_check_extension(KVM_CAP_USER_MEMORY)) {
> +        ram_addr = qemu_ram_alloc(0xa0000);
> +        cpu_register_physical_memory(0, 0xa0000, ram_addr);
> +        kvm_cpu_register_physical_memory(0, 0xa0000, ram_addr);
> +
> +	/* move the pointer up to 0xc0000, which is the next
> +           address we'll touch */
> +        qemu_ram_alloc(0x20000);
> +
>   
Actually the next address we'll touch (see the following lines) is 0x100000.
So maybe replace the last line above with "qemu_ram_alloc (0x100000 - 
0xa0000);"
>          ram_addr = qemu_ram_alloc(ram_size - 0x100000);
>          cpu_register_physical_memory(0x100000, ram_size - 0x100000, ram_addr);
>          kvm_cpu_register_physical_memory(0x100000, ram_size - 0x100000,
>                                           ram_addr);
> -        ram_addr = qemu_ram_alloc(0xa0000);
> -        cpu_register_physical_memory(0, 0xa0000, ram_addr);
> -        kvm_cpu_register_physical_memory(0, 0xa0000, ram_addr);
>      } else
>   #endif
>  #endif
>   

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php