From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH] fix -kernel option Date: Fri, 07 Dec 2007 12:38:11 -0600 Message-ID: <47599313.3060708@codemonkey.ws> References: <11970469043041-git-send-email-gcosta@redhat.com> <47597F62.6060600@codemonkey.ws> <475986AD.90506@qumranet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org, Glauber de Oliveira Costa To: Izik Eidus Return-path: In-Reply-To: <475986AD.90506-atKUWr5tajBWk0Htik3J/w@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.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 >>> --- >>> 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