Fabrice Bellard writes ([Qemu-devel] Re: [PATCH 1/6] Use correct types to
enable 2G support):
Paul Brook wrote: If we ever implement 2G ram on a 32-bit host this
may need some rethinking. We can deal with that if/when it
happens though. Requiring a 64-bit host for large quantities
Anthony Liguori wrote:
KVM supports more than 2GB of memory for x86_64 hosts. The following patch
fixes a number of type related issues where int's were being used when they
shouldn't have been. It also introduces CMOS support so the BIOS can build
the appropriate e820 tables.
[...]
+
Fabrice Bellard wrote:
Anthony Liguori wrote:
+/* above 4giga memory allocation */
+if (above_4g_mem_size 0) {
+ram_addr = qemu_ram_alloc(above_4g_mem_size);
+cpu_register_physical_memory(0x1, above_4g_mem_size,
ram_addr);
+}
+
Why do you need this ? All
I agree with the fact that ram_size should be 64 bit. Maybe each
machine could test the value and emit an error message if it is too
big. Maybe an uint64_t would be better though.
uint64_t is probably more reasonable. I wouldn't begin to know what the
appropriate amount of ram was for
In message: [EMAIL PROTECTED]
Robert William Fuller [EMAIL PROTECTED] writes:
: Avi Kivity wrote:
: Anthony Liguori wrote:
: Fabrice Bellard wrote:
: Anthony Liguori wrote:
: +/* above 4giga memory allocation */
: +if (above_4g_mem_size 0) {
: +ram_addr =
Avi Kivity wrote:
Anthony Liguori wrote:
Fabrice Bellard wrote:
Anthony Liguori wrote:
+/* above 4giga memory allocation */
+if (above_4g_mem_size 0) {
+ram_addr = qemu_ram_alloc(above_4g_mem_size);
+cpu_register_physical_memory(0x1,
above_4g_mem_size,
Paul Brook wrote:
I agree with the fact that ram_size should be 64 bit. Maybe each
machine could test the value and emit an error message if it is too
big. Maybe an uint64_t would be better though.
uint64_t is probably more reasonable. I wouldn't begin to know what the
appropriate amount of
On 1 Feb 2008, at 16:09, M. Warner Losh wrote:
In message: [EMAIL PROTECTED]
Robert William Fuller [EMAIL PROTECTED] writes:
: Avi Kivity wrote:
: Anthony Liguori wrote:
: I think I'll change this too into a single qemu_ram_alloc.
That will
: fix the bug with KVM when using
Ian Jackson wrote:
Anthony Liguori writes ([Qemu-devel] Re: [kvm-devel] [PATCH 1/6] Use correct types to
enable 2G support):
The alternative is to change all the places that assume phys_ram_base +
PA which I don't like very much.
We would ideally like to do this for Xen, at least in
On Fri, Feb 01, 2008 at 11:53:02AM -0600, Anthony Liguori wrote:
Ian Jackson wrote:
Anthony Liguori writes ([Qemu-devel] Re: [kvm-devel] [PATCH 1/6] Use
correct types to enable 2G support):
The alternative is to change all the places that assume phys_ram_base +
PA which I don't
Daniel P. Berrange wrote:
On Fri, Feb 01, 2008 at 11:53:02AM -0600, Anthony Liguori wrote:
Ian Jackson wrote:
Anthony Liguori writes ([Qemu-devel] Re: [kvm-devel] [PATCH 1/6] Use correct types to
enable 2G support):
The alternative is to change all the places that assume
virtio could still be made to work with map cache. You would just have
to change it to be able to map more than one page contiguously. As I
mentioned though, it just starts getting ugly.
That's why you should be using the cpu_physical_memory_rw routines :-)
Anything that assume large linear
On Thursday 31 January 2008, Anthony Liguori wrote:
KVM supports more than 2GB of memory for x86_64 hosts. The following patch
fixes a number of type related issues where int's were being used when they
shouldn't have been. It also introduces CMOS support so the BIOS can build
the
Paul Brook wrote:
On Thursday 31 January 2008, Anthony Liguori wrote:
KVM supports more than 2GB of memory for x86_64 hosts. The following patch
fixes a number of type related issues where int's were being used when they
shouldn't have been. It also introduces CMOS support so the BIOS can
+#define PHYS_RAM_MAX_SIZE (2047 * 1024 * 1024 * 1024ULL)
This seems fairly arbitrary. Why? Any limit is certainly target specific.
On a 32-bit host, a 2GB limit is pretty reasonable since you're limited
in virtual address space. On a 64-bit host, there isn't this
fundamental limit. If
Paul Brook wrote:
+#define PHYS_RAM_MAX_SIZE (2047 * 1024 * 1024 * 1024ULL)
This seems fairly arbitrary. Why? Any limit is certainly target specific.
On a 32-bit host, a 2GB limit is pretty reasonable since you're limited
in virtual address space. On a 64-bit host, there isn't
16 matches
Mail list logo
