Re: [PATCH] fix -kernel option

[Izik Eidus <izike-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

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