From: Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
To: Carlo Marcelo Arenas Belon
<carenas-kLeDWSohozoJb6fo7hG9ng@public.gmane.org>
Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [RFC] "large" memory support for guests
Date: Mon, 12 Nov 2007 11:48:09 +0200 [thread overview]
Message-ID: <47382159.6010200@qumranet.com> (raw)
In-Reply-To: <20071111063026.GA23923@tapir>
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/
prev parent reply other threads:[~2007-11-12 9:48 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-11 6:30 [RFC] "large" memory support for guests Carlo Marcelo Arenas Belon
2007-11-12 9:48 ` Avi Kivity [this message]
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=47382159.6010200@qumranet.com \
--to=avi-atkuwr5tajbwk0htik3j/w@public.gmane.org \
--cc=carenas-kLeDWSohozoJb6fo7hG9ng@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.