[Qemu-devel] Re: [kvm-devel] [PATCH 1/6] Use correct types to enable 2G support

2008-02-03 Thread Izik Eidus

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 appropriate e820 tables.
the CMOS addresses that we used to register the above 4 giga memory are
reserved and therefor the qemu bios does not know them
you have to patch the bios as well to make it work with above 4 giga

i once wrote this patch to qemu,

hope it still apply.

commit 21ea5f8286fd9cd7124dfa0865a213613b51add5
Author: Izik Eidus [EMAIL PROTECTED]
Date:   Mon Aug 20 17:46:04 2007 +0300

kvm: bios: add support to memory above the pci hole

the new memory region is mapped after address 0x1,
the bios take the size of the memory after the 0x1 from
three new cmos bytes.

diff --git a/bios/rombios.c b/bios/rombios.c
index 9ea2dbc..ac918ad 100644
--- a/bios/rombios.c
+++ b/bios/rombios.c
@@ -4078,22 +4078,25 @@ BX_DEBUG_INT15(case default:\n);
 #endif
 

-void set_e820_range(ES, DI, start, end, type)
+void set_e820_range(ES, DI, start, end, extra_start, extra_end, type)
  Bit16u ES;
  Bit16u DI;
  Bit32u start;
  Bit32u end;
+ Bit8u extra_start;
+ Bit8u extra_end;
  Bit16u type;
 {
 write_word(ES, DI, start);
 write_word(ES, DI+2, start  16);
-write_word(ES, DI+4, 0x00);
+write_word(ES, DI+4, extra_start);
 write_word(ES, DI+6, 0x00);
 
 end -= start;
+extra_end -= extra_start;
 write_word(ES, DI+8, end);
 write_word(ES, DI+10, end  16);
-write_word(ES, DI+12, 0x);
+write_word(ES, DI+12, extra_end);
 write_word(ES, DI+14, 0x);
 
 write_word(ES, DI+16, type);
@@ -4106,7 +4109,9 @@ int15_function32(regs, ES, DS, FLAGS)
   Bit16u ES, DS, FLAGS;
 {
   Bit32u  extended_memory_size=0; // 64bits long
+  Bit32u  extra_lowbits_memory_size=0;
   Bit16u  CX,DX;
+  Bit8u   extra_highbits_memory_size=0;
 
 BX_DEBUG_INT15(int15 AX=%04x\n,regs.u.r16.ax);
 
@@ -4179,11 +4184,18 @@ ASM_END
 extended_memory_size *= 1024;
 }
 
+extra_lowbits_memory_size = inb_cmos(0x5c);
+extra_lowbits_memory_size = 8;
+extra_lowbits_memory_size |= inb_cmos(0x5b);
+extra_lowbits_memory_size *= 64;
+extra_lowbits_memory_size *= 1024;
+extra_highbits_memory_size = inb_cmos(0x5d);
+
 switch(regs.u.r16.bx)
 {
 case 0:
 set_e820_range(ES, regs.u.r16.di,
-   0x000L, 0x0009fc00L, 1);
+   0x000L, 0x0009fc00L, 0, 0, 1);
 regs.u.r32.ebx = 1;
 regs.u.r32.eax = 0x534D4150;
 regs.u.r32.ecx = 0x14;
@@ -4192,7 +4204,7 @@ ASM_END
 break;
 case 1:
 set_e820_range(ES, regs.u.r16.di,
-   0x0009fc00L, 0x000aL, 2);
+   0x0009fc00L, 0x000aL, 0, 0, 2);
 regs.u.r32.ebx = 2;
 regs.u.r32.eax = 0x534D4150;
 regs.u.r32.ecx = 0x14;
@@ -4201,7 +4213,7 @@ ASM_END
 break;
 case 2:
 set_e820_range(ES, regs.u.r16.di,
-   0x000e8000L, 0x0010L, 2);
+   0x000e8000L, 0x0010L, 0, 0, 2);
 regs.u.r32.ebx = 3;
 regs.u.r32.eax = 0x534D4150;
 regs.u.r32.ecx = 0x14;
@@ -4211,7 +4223,7 @@ ASM_END
 case 3:
 set_e820_range(ES, regs.u.r16.di,
0x0010L,
-   extended_memory_size - ACPI_DATA_SIZE, 
1);
+   extended_memory_size - ACPI_DATA_SIZE 
,0, 0, 1);
 regs.u.r32.ebx = 4;
 regs.u.r32.eax = 0x534D4150;
 regs.u.r32.ecx = 0x14;
@@ -4221,7 +4233,7 @@ ASM_END
 case 4:
 set_e820_range(ES, regs.u.r16.di,
extended_memory_size - ACPI_DATA_SIZE,
-   extended_memory_size, 3); // ACPI RAM
+   extended_memory_size ,0, 0, 3); // ACPI 
RAM
 regs.u.r32.ebx = 5;
 regs.u.r32.eax = 0x534D4150;
 regs.u.r32.ecx = 0x14;
@@ -4231,7 +4243,20 @@ ASM_END
 case 5:
 /* 256KB BIOS area at the end of 4 GB */
   

[Qemu-devel] Re: [kvm-devel] [PATCH 1/6] Use correct types to enable 2G support

2008-02-01 Thread Anthony Liguori

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's hardly elegant.
  


It only gets wasted if it gets faulted in.  Any it won't get faulted in, 
so it won't increase the RSS size.  We could madvise(MADV_DONTNEED) just 
to ensure that it's not occupying swap space if you were really paranoid 
about it.  I don't think munmap()'ing malloc()'d memory is a very good 
idea.  glibc may freak out.


The alternative is to change all the places that assume phys_ram_base + 
PA which I don't like very much.


Regards,

Anthony Liguori





Re: [Qemu-devel] Re: [kvm-devel] [PATCH 1/6] Use correct types to enable 2G support

2008-02-01 Thread Ian Jackson
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 the places we
care about.  (Xen uses less of the qemu tree than KVM, I think.)

In Xen, the guest memory is not in general mapped into the host qemu's
address space.

Ian.




[Qemu-devel] Re: [kvm-devel] [PATCH 1/6] Use correct types to enable 2G support

2008-02-01 Thread Anthony Liguori

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 ram was for each machine though so I'll let the
appropriate people handle that :-)



I'd say ram_addr_t is an appropriate type.
Currently this is defined in cpu-defs.h. It should probably be moved elsewhere 
because in the current implementation it's really a host type.
  


Okay, it turns out that patch needed a lot of refactoring.  I agree that 
changing ram_addr_t to a host type is the right thing to do.


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 of ram seems an acceptable limitation (N.B. I'm only talking 
about ram size, not target physical address size).
  


My current limitation is  2GB if HOST_BITS==32 or defined(USE_KQEMU).  
USE_KQEMU restricts the size of the phys_map which limits the maximum 
physical address size.  I guess technically USE_KQEMU could allow up to 
around 3GB of ram but I preferred to simplify the logic.


Regards,

Anthony Liguori


Paul

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kvm-devel