From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [RFC] "large" memory support for guests Date: Mon, 12 Nov 2007 11:48:09 +0200 Message-ID: <47382159.6010200@qumranet.com> References: <20071111063026.GA23923@tapir> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Carlo Marcelo Arenas Belon Return-path: In-Reply-To: <20071111063026.GA23923@tapir> 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 Carlo Marcelo Arenas Belon wrote: > The following patch applies to kvm-51 and correct all compilation warnings > because of mismatching types for ram related variables and that were left > behind after the changes to add support for more than 2GB of memory for 32bit > guests. > Please use correct subject lines. > a more complete patchset will be needed for doing the same changes to trunk > (most of them are already identified in my ramaddr branch) but since there are > 3 different types (ram_addr_t, target_ulong, uint32_t) currently in use in the > code to identify memory and 2 different macro definitions (HOST_LONG_BITS, > TARGET_LOG_BITS) wanted first to raise a RFC as there is most likely space to > simplify the logic and make the code more consistent once the base design > issues are layout. > > this has been tested with 32/64bit hosts and 32/64bit guests with more than > 4GB of memory (except for 32bit host with 32bit guest where the limitation is > 3GB because of process vmsize) > > Carlo > -- > diff --git a/qemu/cpu-defs.h b/qemu/cpu-defs.h > index 9158776..7385ef1 100644 > --- a/qemu/cpu-defs.h > +++ b/qemu/cpu-defs.h > @@ -73,7 +73,7 @@ typedef uint64_t target_phys_addr_t; > #endif > > /* address in the RAM (different from a physical address) */ > -typedef unsigned long ram_addr_t; > +typedef target_ulong ram_addr_t; > This is wrong. For i386 on x86_64, we can have >4GB RAM, whereas target_ulong is 32-bit. > > #define HOST_LONG_SIZE (HOST_LONG_BITS / 8) > > diff --git a/qemu/exec.c b/qemu/exec.c > index 788a913..c1bf8d5 100644 > --- a/qemu/exec.c > +++ b/qemu/exec.c > @@ -1986,7 +1986,7 @@ static inline void tlb_set_dirty(CPUState *env, > > static int subpage_register (subpage_t *mmio, uint32_t start, uint32_t end, > int memory); > -static void *subpage_init (target_phys_addr_t base, uint32_t *phys, > +static void *subpage_init (target_phys_addr_t base, ram_addr_t *phys, > int orig_memory); > target_phys_addr_t is more correct here, I believe. Please copy qemu-devel on these types of core qemu changes. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/