On Thu, 2008-01-31 at 16:36 -0600, 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:
>>> 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
>>
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
>> appropriat
> > 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 wa
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 -kernel and large memory anyway :-)
>>
>
> Won't that cause all of the memory in the hole to be wasted?
>
> You could munmap() it, but it
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, ram_
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 d
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.
> [...]
>
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-bi
> >> +#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
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
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 appropr
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.
Index: qemu/cpu-all.h
===
13 matches
Mail list logo
