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 <[EMAIL PROTECTED]>
>>> ---
>>> 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
>> [email protected]
>> 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
_______________________________________________
kvm-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/kvm-devel
