public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org>
To: Izik Eidus <izike-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
	avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org,
	Glauber de Oliveira Costa
	<gcosta-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Subject: Re: [PATCH] fix -kernel option
Date: Fri, 07 Dec 2007 12:38:11 -0600	[thread overview]
Message-ID: <47599313.3060708@codemonkey.ws> (raw)
In-Reply-To: <475986AD.90506-atKUWr5tajBWk0Htik3J/w@public.gmane.org>

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

  parent reply	other threads:[~2007-12-07 18:38 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-07 17:01 [PATCH] fix -kernel option Glauber de Oliveira Costa
     [not found] ` <11970469043041-git-send-email-gcosta-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2007-12-07 17:14   ` Anthony Liguori
     [not found]     ` <47597F62.6060600-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org>
2007-12-07 17:45       ` Izik Eidus
     [not found]         ` <475986AD.90506-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2007-12-07 18:38           ` Anthony Liguori [this message]
     [not found]             ` <47599313.3060708-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org>
2007-12-07 18:45               ` Izik Eidus
2007-12-07 20:04               ` Luca Tettamanti
2007-12-09  8:54       ` Avi Kivity
2007-12-07 17:49   ` Izik Eidus
2007-12-09 14:00   ` Dor Laor
     [not found]     ` <475BF50F.5020001-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2007-12-09 13:59       ` Izik Eidus
2007-12-10 16:17       ` Glauber de Oliveira Costa
     [not found]         ` <475D6686.4070202-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2007-12-10 17:56           ` Dor Laor
2007-12-09 14:04   ` Uri Lublin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47599313.3060708@codemonkey.ws \
    --to=anthony-rdkfgonbjusknkdkm+me6a@public.gmane.org \
    --cc=avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org \
    --cc=gcosta-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=izike-atKUWr5tajBWk0Htik3J/w@public.gmane.org \
    --cc=kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox