From mboxrd@z Thu Jan  1 00:00:00 1970
From: Izik Eidus <izike-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
Subject: Re: kvm-59 doesn't work
Date: Sun, 13 Jan 2008 23:43:22 +0200
Message-ID: <478A85FA.3000402@qumranet.com>
References: <20080113162751.GA20663@basil.nowhere.org>
	<478A3F87.6040509@qumranet.com> <478A47E4.8020109@codemonkey.ws>
	<478A473E.5090907@qumranet.com> <478A7382.5040406@codemonkey.ws>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
	Andi Kleen <andi-Vw/NltI1exuRpAAqCnN02g@public.gmane.org>, Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
To: Anthony Liguori <anthony-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org>
Return-path: <kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
In-Reply-To: <478A7382.5040406-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/kvm-devel>,
	<mailto:kvm-devel-request-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=kvm-devel>
List-Post: <mailto:kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
List-Help: <mailto:kvm-devel-request-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/kvm-devel>,
	<mailto:kvm-devel-request-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org?subject=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

Anthony Liguori wrote:
> Izik Eidus wrote:
>> Anthony Liguori wrote:
>>> Avi Kivity wrote:
>>>> Andi Kleen wrote:
>>>>  
>>>>> When I try my 64bit kernel with -kernel ... on kvm-59 I get before
>>>>> the kernel outputs anything:
>>>>>
>>>>>       
>>>>
>>>> Yes, I think -kernel is broken.
>>>>   
>>>
>>> If you are using a guest with more than 3.75GB or so.  The 
>>> load_kernel function uses phys_ram_base + addr and that assumption 
>>> is violated in KVM with guests > ~3.75GB of memory.  We either need 
>>> to allocate memory for the hole and never touch it or change 
>>> load_kernel to use cpu_physical_memory_rw.  I know we discussed this 
>>> before but I don't remember if we came to a consensus about what the 
>>> correct fix is?
>>>
>> we can do munmap on the pci hole memory area,
>> btw Anthony virtio will need this too right?
>
> Yup.  I don't think you want to munmap memory allocated by glibc.
i was thinking about allocate the memory with mmap instead of the qemu 
qemu_malloc...
>
> I think a better thing to do would be to madvise(MADV_DONTNEED) 
> although I don't think it's strictly needed.  If you never touch the 
> memory, then does it really matter? 
why to keep the virtual address size of a program 300mb larger than it 
really is?
>
> Regards,
>
> Anthony Liguori
>
>>> Regards,
>>>
>>> Anthony Liguori
>>>> Izik?
>>>>
>>>>   
>>>
>>
>


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace