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 <[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);
>>
> 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
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
