adding support for above 2giga to kvm (include patchs)

adding support for above 2giga to kvm (include patchs)

[Izik Eidus]

[-- Attachment #1.1: Type: text/plain, Size: 986 bytes --]

this is a request for comment for patchs that allow kvm to run with more than 2 giga.
there are 4 patchs.
the first patch(biospatch): is for the bios:now the bios know how to map memory about the 0xf0000000-0xffffffff hole.

the second  patch(qemu_change_types_patch):is for qemu ram_size types:it change the variables that hold the ram_size to unsigned long,
and it is based on patch from the qemu-devel list that targeted sparc.

the third patch(kvm_userspace_memmap):is for kvm and add to it another memory slot that hold the new memory region.

the last patch(kvm_new_slot_patch):is for kvmctl, and make it use the new memory region and map memory above 4giga to it.

i added compiled bios for to make it easy to run it.

(kvm was tested with 14giga of ram and had no problem to drive win3k and fedora 6 + x ,please note that i tryed in the patch to add support to the qemu emulator to run with above 4 giga as well,
it work without svga, need some work to do there)

[-- Attachment #1.2: Type: text/html, Size: 1444 bytes --]

[-- Attachment #2: bios.bin --]
[-- Type: application/octet-stream, Size: 131072 bytes --]

[-- Attachment #3: qemu_change_types_patch --]
[-- Type: application/octet-stream, Size: 8577 bytes --]

diff --git a/qemu/cpu-all.h b/qemu/cpu-all.h
index a325e05..90e4351 100644
--- a/qemu/cpu-all.h
+++ b/qemu/cpu-all.h
@@ -822,7 +822,7 @@ int cpu_inl(CPUState *env, int addr);
 
 /* memory API */
 
-extern int phys_ram_size;
+extern unsigned long phys_ram_size;
 extern int phys_ram_fd;
 extern uint8_t *phys_ram_base;
 extern uint8_t *phys_ram_dirty;
diff --git a/qemu/exec.c b/qemu/exec.c
index 2b050d1..f5cce06 100644
--- a/qemu/exec.c
+++ b/qemu/exec.c
@@ -85,7 +85,7 @@ spinlock_t tb_lock = SPIN_LOCK_UNLOCKED;
 uint8_t code_gen_buffer[CODE_GEN_BUFFER_SIZE] __attribute__((aligned (32)));
 uint8_t *code_gen_ptr;
 
-int phys_ram_size;
+unsigned long phys_ram_size;
 int phys_ram_fd;
 uint8_t *phys_ram_base;
 uint8_t *phys_ram_dirty;
@@ -111,7 +111,7 @@ typedef struct PageDesc {
 
 typedef struct PhysPageDesc {
     /* offset in host memory of the page + io_index in the low 12 bits */
-    uint32_t phys_offset;
+    unsigned long phys_offset;
 } PhysPageDesc;
 
 #define L2_BITS 10
diff --git a/qemu/hw/i8524patch b/qemu/hw/i8524patch
deleted file mode 100644
index 5cc1a9b..0000000
--- a/qemu/hw/i8524patch
+++ /dev/null
@@ -1,37 +0,0 @@
---- oldi8254.c	2007-08-11 12:14:15.000000000 +0300
-+++ i8254.c	2007-08-11 12:10:02.000000000 +0300
-@@ -357,9 +357,6 @@
-     return ret;
- }
- 
--/* global counters for time-drift fix */
--int64_t timer_acks=0, timer_interrupts=0, timer_ints_to_push=0;
--
- static void pit_irq_timer_update(PITChannelState *s, int64_t current_time)
- {
-     int64_t expire_time;
-@@ -370,24 +367,6 @@
-     expire_time = pit_get_next_transition_time(s, current_time);
-     irq_level = pit_get_out1(s, current_time);
-     pic_set_irq(s->irq, irq_level);
--    if (time_drift_fix && irq_level==1) {
--        /* FIXME: fine tune timer_max_fix (max fix per tick). 
--         *        Should it be 1 (double time), 2 , 4, 10 ? 
--         *        Currently setting it to 5% of PIT-ticks-per-second (per PIT-tick)
--         */
--        const long pit_ticks_per_sec = (s->count>0) ? (PIT_FREQ/s->count) : 0;
--        const long timer_max_fix = pit_ticks_per_sec/20;
--        const long delta = timer_interrupts - timer_acks;
--        const long max_delta = pit_ticks_per_sec * 60; /* one minute */
--        if ((delta >  max_delta) && (pit_ticks_per_sec > 0)) {
--            printf("time drift is too long, %ld seconds were lost\n", delta/pit_ticks_per_sec);
--            timer_acks = timer_interrupts;
--            timer_ints_to_push = 0;
--        } else if (delta > 0) {
--            timer_ints_to_push = MIN(delta, timer_max_fix);
--        }
--        timer_interrupts++;
--    }
- #ifdef DEBUG_PIT
-     printf("irq_level=%d next_delay=%f\n",
-            irq_level, 
diff --git a/qemu/hw/i8529patch b/qemu/hw/i8529patch
deleted file mode 100644
index e295094..0000000
--- a/qemu/hw/i8529patch
+++ /dev/null
@@ -1,55 +0,0 @@
---- oldi8259.c	2007-08-11 12:14:05.000000000 +0300
-+++ i8259.c	2007-08-11 12:10:02.000000000 +0300
-@@ -67,6 +67,8 @@
- static uint64_t irq_count[16];
- #endif
- 
-+unsigned int lost_ticks;
-+
- /* set irq level. If an edge is detected, then the IRR is set to 1 */
- static inline void pic_set_irq1(PicState *s, int irq, int level)
- {
-@@ -137,6 +139,14 @@
- {
-     int irq2, irq;
- 
-+    if(lost_ticks > 0) {
-+        pic_set_irq1(&s->pics[0], 0, 0);
-+        pic_set_irq1(&s->pics[0], 0, 1);
-+        s->irq_request(s->irq_request_opaque, 1);
-+        lost_ticks--;
-+        return;
-+    }
-+
-     /* first look at slave pic */
-     irq2 = pic_get_irq(&s->pics[1]);
-     if (irq2 >= 0) {
-@@ -178,6 +188,11 @@
- {
-     PicState2 *s = opaque;
- 
-+    if (irq == 0 && (s->pics[0].irr & 1) == 1 && ~s->pics[0].imr & 1 == 1) {
-+        lost_ticks++;
-+        return;
-+    }
-+
- #if defined(DEBUG_PIC) || defined(DEBUG_IRQ_COUNT)
-     if (level != irq_level[irq]) {
- #if defined(DEBUG_PIC)
-@@ -220,16 +235,6 @@
-     /* We don't clear a level sensitive interrupt here */
-     if (!(s->elcr & (1 << irq)))
-         s->irr &= ~(1 << irq);
--
--    if (time_drift_fix && irq == 0) {
--        extern int64_t timer_acks, timer_ints_to_push;
--        timer_acks++;
--        if (timer_ints_to_push > 0) {
--            timer_ints_to_push--;
--            pic_set_irq(0, 0); /* set it low (edge irq)*/
--            pic_set_irq(0, 1); /* interrupt again */
--        }
--    }
- }
- 
- int pic_read_irq(PicState2 *s)
diff --git a/qemu/hw/pc.c b/qemu/hw/pc.c
index ae92173..7bec234 100644
--- a/qemu/hw/pc.c
+++ b/qemu/hw/pc.c
@@ -163,7 +163,7 @@ static void cmos_init_hd(int type_ofs, int info_ofs, BlockDriverState *hd)
 }
 
 /* hd_table must contain 4 block drivers */
-static void cmos_init(int ram_size, int boot_device, BlockDriverState **hd_table)
+static void cmos_init(unsigned long ram_size, int boot_device, BlockDriverState **hd_table)
 {
     RTCState *s = rtc_state;
     int val;
@@ -457,7 +457,7 @@ extern int kvm_allowed;
 #endif
 
 /* PC hardware initialisation */
-static void pc_init1(int ram_size, int vga_ram_size, int boot_device,
+static void pc_init1(unsigned long ram_size, int vga_ram_size, int boot_device,
                      DisplayState *ds, const char **fd_filename, int snapshot,
                      const char *kernel_filename, const char *kernel_cmdline,
                      const char *initrd_filename,
@@ -794,7 +794,7 @@ static void pc_init1(int ram_size, int vga_ram_size, int boot_device,
 #endif
 }
 
-static void pc_init_pci(int ram_size, int vga_ram_size, int boot_device,
+static void pc_init_pci(unsigned long ram_size, int vga_ram_size, int boot_device,
                         DisplayState *ds, const char **fd_filename, 
                         int snapshot, 
                         const char *kernel_filename, 
@@ -807,7 +807,7 @@ static void pc_init_pci(int ram_size, int vga_ram_size, int boot_device,
              initrd_filename, 1);
 }
 
-static void pc_init_isa(int ram_size, int vga_ram_size, int boot_device,
+static void pc_init_isa(unsigned long ram_size, int vga_ram_size, int boot_device,
                         DisplayState *ds, const char **fd_filename, 
                         int snapshot, 
                         const char *kernel_filename, 
diff --git a/qemu/hw/vga.c b/qemu/hw/vga.c
index fcb19b0..c1edd88 100644
--- a/qemu/hw/vga.c
+++ b/qemu/hw/vga.c
@@ -1399,10 +1399,11 @@ extern int kvm_allowed;
 static void vga_draw_graphic(VGAState *s, int full_update)
 {
     int y1, y, update, page_min, page_max, linesize, y_start, double_scan, mask;
-    int width, height, shift_control, line_offset, page0, page1, bwidth;
+    int width, height, shift_control, line_offset, bwidth;
     int disp_width, multi_scan, multi_run;
     uint8_t *d;
     uint32_t v, addr1, addr;
+    unsigned long page0, page1;
     vga_draw_line_func *vga_draw_line;
     
 #ifdef USE_KVM
diff --git a/qemu/vl.c b/qemu/vl.c
index b14233c..5dd6eec 100644
--- a/qemu/vl.c
+++ b/qemu/vl.c
@@ -101,8 +101,11 @@
 
 //#define DEBUG_UNUSED_IOPORT
 //#define DEBUG_IOPORT
-
+#if HOST_LONG_BITS < 64
 #define PHYS_RAM_MAX_SIZE (2047 * 1024 * 1024)
+#else
+#define PHYS_RAM_MAX_SIZE (2047 * 1024 * 1024 * 1024ULL)
+#endif
 
 #ifdef TARGET_PPC
 #define DEFAULT_RAM_SIZE 144
@@ -135,7 +138,7 @@ int nographic;
 const char* keyboard_layout = NULL;
 int64_t ticks_per_sec;
 int boot_device = 'c';
-int ram_size;
+unsigned long ram_size;
 int pit_min_timer_count = 0;
 int nb_nics;
 NICInfo nd_table[MAX_NICS];
@@ -7182,7 +7185,7 @@ int main(int argc, char **argv)
                 help();
                 break;
             case QEMU_OPTION_m:
-                ram_size = atoi(optarg) * 1024 * 1024;
+                ram_size = (unsigned long)atoi(optarg) * 1024 * 1024;
                 if (ram_size <= 0)
                     help();
                 if (ram_size > PHYS_RAM_MAX_SIZE) {
diff --git a/qemu/vl.h b/qemu/vl.h
index 43f56bd..d35b47f 100644
--- a/qemu/vl.h
+++ b/qemu/vl.h
@@ -153,7 +153,7 @@ void qemu_system_powerdown(void);
 
 void main_loop_wait(int timeout);
 
-extern int ram_size;
+extern unsigned long ram_size;
 extern int bios_size;
 extern int rtc_utc;
 extern int cirrus_vga_enabled;
@@ -716,7 +716,7 @@ void path_combine(char *dest, int dest_size,
 
 #ifndef QEMU_TOOL
 
-typedef void QEMUMachineInitFunc(int ram_size, int vga_ram_size, 
+typedef void QEMUMachineInitFunc(unsigned long ram_size, int vga_ram_size, 
                                  int boot_device,
              DisplayState *ds, const char **fd_filename, int snapshot,
              const char *kernel_filename, const char *kernel_cmdline,

[-- Attachment #4: kvm_new_slot_patch --]
[-- Type: application/octet-stream, Size: 796 bytes --]

diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index fc27c2f..ac3fa1c 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -39,7 +39,7 @@
 
 #define KVM_MAX_VCPUS 4
 #define KVM_ALIAS_SLOTS 4
-#define KVM_MEMORY_SLOTS 4
+#define KVM_MEMORY_SLOTS 5
 #define KVM_NUM_MMU_PAGES 1024
 #define KVM_MIN_FREE_MMU_PAGES 5
 #define KVM_REFILL_PAGES 25
diff --git a/drivers/kvm/vmx.c b/drivers/kvm/vmx.c
index dac2f93..1613f23 100644
--- a/drivers/kvm/vmx.c
+++ b/drivers/kvm/vmx.c
@@ -905,7 +905,7 @@ static void enter_pmode(struct kvm_vcpu *vcpu)
 	vmcs_write32(GUEST_CS_AR_BYTES, 0x9b);
 }
 
-static int rmode_tss_base(struct kvm* kvm)
+static gva_t rmode_tss_base(struct kvm* kvm)
 {
 	gfn_t base_gfn = kvm->memslots[0].base_gfn + kvm->memslots[0].npages - 3;
 	return base_gfn << PAGE_SHIFT;

[-- Attachment #5: biospatch --]
[-- Type: application/octet-stream, Size: 6922 bytes --]

--- rombios.c	2007-08-01 20:09:51.000000000 +0300
+++ newbios.c	2007-08-08 15:26:59.000000000 +0300
@@ -4077,24 +4077,32 @@
 }
 #endif
 
+struct MemoryMap {
+    Bit32u start;
+    Bit16u extra_start;
+    Bit32u end;
+    Bit8u extra_end;
+};
+
+typedef struct MemoryMap *MemoryMap_t;
 
-void set_e820_range(ES, DI, start, end, type)
+void set_e820_range(ES, DI, MemMap, type)
      Bit16u ES;
      Bit16u DI;
-     Bit32u start;
-     Bit32u end;
+     MemoryMap_t MemMap;
      Bit16u type;
 {
-    write_word(ES, DI, start);
-    write_word(ES, DI+2, start >> 16);
-    write_word(ES, DI+4, 0x00);
-    write_word(ES, DI+6, 0x00);
-
-    end -= start;
-    write_word(ES, DI+8, end);
-    write_word(ES, DI+10, end >> 16);
-    write_word(ES, DI+12, 0x0000);
-    write_word(ES, DI+14, 0x0000);
+    write_word(ES, DI, MemMap->start);
+    write_word(ES, DI+2, MemMap->start >> 16);
+    write_word(ES, DI+4, MemMap->extra_start);
+    write_word(ES, DI+6, 0x0);
+
+    MemMap->end -= MemMap->start;
+    MemMap->extra_end -= MemMap->extra_start;
+    write_word(ES, DI+8, MemMap->end);
+    write_word(ES, DI+10, MemMap->end >> 16);
+    write_word(ES, DI+12, MemMap->extra_end);
+    write_word(ES, DI+14, 0x0);
 
     write_word(ES, DI+16, type);
     write_word(ES, DI+18, 0x0);
@@ -4105,8 +4113,12 @@
   pushad_regs_t regs; // REGS pushed via pushad
   Bit16u ES, DS, FLAGS;
 {
+  struct MemoryMap MemMap;
+	char x1,x2;
   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 +4191,21 @@
                     extended_memory_size *= 1024;
                 }
 
-                switch(regs.u.r16.bx)
+                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,
-                                       0x0000000L, 0x0009fc00L, 1);
+                        MemMap.start = 0x0000000L;
+                        MemMap.extra_start = 0;
+                        MemMap.end = 0x0009fc00L;
+                        MemMap.extra_end = 0;
+                        set_e820_range(ES, regs.u.r16.di, &MemMap, 1);
                         regs.u.r32.ebx = 1;
                         regs.u.r32.eax = 0x534D4150;
                         regs.u.r32.ecx = 0x14;
@@ -4191,8 +4213,11 @@
                         return;
                         break;
                     case 1:
-                        set_e820_range(ES, regs.u.r16.di,
-                                       0x0009fc00L, 0x000a0000L, 2);
+                        MemMap.start = 0x0009fc00L;
+                        MemMap.extra_start = 0;
+                        MemMap.end = 0x000a0000L;
+                        MemMap.extra_end = 0;
+                        set_e820_range(ES, regs.u.r16.di, &MemMap, 2);
                         regs.u.r32.ebx = 2;
                         regs.u.r32.eax = 0x534D4150;
                         regs.u.r32.ecx = 0x14;
@@ -4200,8 +4225,11 @@
                         return;
                         break;
                     case 2:
-                        set_e820_range(ES, regs.u.r16.di,
-                                       0x000e8000L, 0x00100000L, 2);
+                        MemMap.start = 0x000e8000L;
+                        MemMap.extra_start = 0;
+                        MemMap.end = 0x00100000L;
+                        MemMap.extra_end = 0;
+                        set_e820_range(ES, regs.u.r16.di, &MemMap, 2);
                         regs.u.r32.ebx = 3;
                         regs.u.r32.eax = 0x534D4150;
                         regs.u.r32.ecx = 0x14;
@@ -4209,9 +4237,12 @@
                         return;
                         break;
                     case 3:
+                        MemMap.start = 0x00100000L;
+                        MemMap.extra_start = 0;
+                        MemMap.end = extended_memory_size - ACPI_DATA_SIZE;
+                        MemMap.extra_end = 0;
                         set_e820_range(ES, regs.u.r16.di,
-                                       0x00100000L,
-                                       extended_memory_size - ACPI_DATA_SIZE, 1);
+                                       &MemMap, 1);
                         regs.u.r32.ebx = 4;
                         regs.u.r32.eax = 0x534D4150;
                         regs.u.r32.ecx = 0x14;
@@ -4219,9 +4250,12 @@
                         return;
                         break;
                     case 4:
+                        MemMap.start = extended_memory_size - ACPI_DATA_SIZE;
+                        MemMap.extra_start = 0;
+                        MemMap.end = extended_memory_size;
+                        MemMap.extra_end = 0;
                         set_e820_range(ES, regs.u.r16.di,
-                                       extended_memory_size - ACPI_DATA_SIZE,
-                                       extended_memory_size, 3); // ACPI RAM
+                                       &MemMap, 3); // ACPI RAM
                         regs.u.r32.ebx = 5;
                         regs.u.r32.eax = 0x534D4150;
                         regs.u.r32.ecx = 0x14;
@@ -4230,8 +4264,26 @@
                         break;
                     case 5:
                         /* 256KB BIOS area at the end of 4 GB */
-                        set_e820_range(ES, regs.u.r16.di,
-                                       0xfffc0000L, 0x00000000L, 2);
+			MemMap.start = 0xfffc0000L;
+                        MemMap.extra_start = 0;
+                        MemMap.end = 0x00000000L;
+                        MemMap.extra_end = 0;
+                        set_e820_range(ES, regs.u.r16.di, &MemMap, 2);
+			if (extra_highbits_memory_size || extra_lowbits_memory_size)
+                        	regs.u.r32.ebx = 6;
+			else 
+				regs.u.r32.ebx = 0;
+                        regs.u.r32.eax = 0x534D4150;
+                        regs.u.r32.ecx = 0x14;
+                        CLEAR_CF();
+                        return;
+                    case 6:
+                        /* Maping of memory above 4 GB */
+                        MemMap.start = 0x0;
+                        MemMap.extra_start = 0x1;
+                        MemMap.end = extra_lowbits_memory_size + MemMap.start;
+                        MemMap.extra_end = extra_highbits_memory_size + MemMap.extra_start;
+			set_e820_range(ES, regs.u.r16.di, &MemMap, 1);
                         regs.u.r32.ebx = 0;
                         regs.u.r32.eax = 0x534D4150;
                         regs.u.r32.ecx = 0x14;

[-- Attachment #6: kvm_userspace_memmap --]
[-- Type: application/octet-stream, Size: 12518 bytes --]

diff --git a/qemu/exec.c b/qemu/exec.c
index f5cce06..e54711e 100644
--- a/qemu/exec.c
+++ b/qemu/exec.c
@@ -69,7 +69,7 @@
 #define TARGET_PHYS_ADDR_SPACE_BITS 42
 #else
 /* Note: for compatibility with kqemu, we use 32 bits for x86_64 */
-#define TARGET_PHYS_ADDR_SPACE_BITS 32
+#define TARGET_PHYS_ADDR_SPACE_BITS 42
 #endif
 
 #ifdef USE_KVM
diff --git a/qemu/hw/pc.c b/qemu/hw/pc.c
index 7bec234..f938fd0 100644
--- a/qemu/hw/pc.c
+++ b/qemu/hw/pc.c
@@ -163,16 +163,18 @@ static void cmos_init_hd(int type_ofs, int info_ofs, BlockDriverState *hd)
 }
 
 /* hd_table must contain 4 block drivers */
-static void cmos_init(unsigned long ram_size, int boot_device, BlockDriverState **hd_table)
+static void cmos_init(unsigned long ram_size, unsigned long above_bios_ram_size, int boot_device, BlockDriverState **hd_table)
 {
     RTCState *s = rtc_state;
     int val;
     int fd0, fd1, nb;
     int i;
+    unsigned long above_bios_mem_bits;
 
     /* various important CMOS locations needed by PC/Bochs bios */
 
     /* memory size */
+    if (ram_size > 0xf0000000)
     val = 640; /* base memory in K */
     rtc_set_memory(s, 0x15, val);
     rtc_set_memory(s, 0x16, val >> 8);
@@ -184,7 +186,12 @@ static void cmos_init(unsigned long ram_size, int boot_device, BlockDriverState
     rtc_set_memory(s, 0x18, val >> 8);
     rtc_set_memory(s, 0x30, val);
     rtc_set_memory(s, 0x31, val >> 8);
-
+    
+    val = (unsigned int)above_bios_ram_size / 65536;
+    rtc_set_memory(s, 0x5b, val);
+    rtc_set_memory(s, 0x5c, val >> 8);
+    rtc_set_memory(s, 0x5d, above_bios_ram_size/0x100000000);
+    
     if (ram_size > (16 * 1024 * 1024))
         val = (ram_size / 65536) - ((16 * 1024 * 1024) / 65536);
     else
@@ -465,14 +472,17 @@ static void pc_init1(unsigned long ram_size, int vga_ram_size, int boot_device,
 {
     char buf[1024];
     int ret, linux_boot, initrd_size, i;
-    unsigned long bios_offset, vga_bios_offset, option_rom_offset;
+    unsigned long bios_offset, vga_bios_offset, option_rom_offset, above_bios_mem_size = 0;
     ram_addr_t initrd_offset;
     int bios_size, isa_bios_size;
     PCIBus *pci_bus;
     int piix3_devfn = -1;
     CPUState *env;
     NICInfo *nd;
-
+    if (ram_size + (phys_ram_size - ram_size) >= 0xf0000000 ) {
+        above_bios_mem_size = ram_size - 0xf0000000;;
+       	ram_size = 0xf0000000 - (phys_ram_size - ram_size);
+    }
     linux_boot = (kernel_filename != NULL);
 
     /* init CPUs */
@@ -492,7 +502,9 @@ static void pc_init1(unsigned long ram_size, int vga_ram_size, int boot_device,
     }
 
     /* allocate RAM */
-    cpu_register_physical_memory(0, ram_size, 0);
+    cpu_register_physical_memory(0, ram_size , 0);
+    if (above_bios_mem_size > 0)
+        cpu_register_physical_memory(0x100000000, above_bios_mem_size , 0x0);
 
     /* BIOS load */
     bios_offset = ram_size + vga_ram_size;
@@ -668,11 +680,10 @@ static void pc_init1(unsigned long ram_size, int vga_ram_size, int boot_device,
     register_ioport_write(0x80, 1, 1, ioport80_write, NULL);
 
     register_ioport_write(0xf0, 1, 1, ioportF0_write, NULL);
-
     if (cirrus_vga_enabled) {
         if (pci_enabled) {
             pci_cirrus_vga_init(pci_bus, 
-                                ds, phys_ram_base + ram_size, ram_size, 
+                                ds, phys_ram_base + ram_size , ram_size, 
                                 vga_ram_size);
         } else {
             isa_cirrus_vga_init(ds, phys_ram_base + ram_size, ram_size, 
@@ -687,7 +698,6 @@ static void pc_init1(unsigned long ram_size, int vga_ram_size, int boot_device,
                          vga_ram_size);
         }
     }
-
     rtc_state = rtc_init(0x70, 8);
 
     register_ioport_read(0x92, 1, 1, ioport92_read, NULL);
@@ -756,7 +766,7 @@ static void pc_init1(unsigned long ram_size, int vga_ram_size, int boot_device,
 
     floppy_controller = fdctrl_init(6, 2, 0, 0x3f0, fd_table);
 
-    cmos_init(ram_size, boot_device, bs_table);
+    cmos_init(ram_size , above_bios_mem_size, boot_device, bs_table);
 
     if (pci_enabled && usb_enabled) {
         usb_uhci_init(pci_bus, piix3_devfn + 2);
@@ -0,0 +1,178 @@
+diff --git a/qemu/exec.c b/qemu/exec.c
+index f5cce06..e54711e 100644
+--- a/qemu/exec.c
++++ b/qemu/exec.c
+@@ -69,7 +69,7 @@
+ #define TARGET_PHYS_ADDR_SPACE_BITS 42
+ #else
+ /* Note: for compatibility with kqemu, we use 32 bits for x86_64 */
+-#define TARGET_PHYS_ADDR_SPACE_BITS 32
++#define TARGET_PHYS_ADDR_SPACE_BITS 42
+ #endif
+ 
+ #ifdef USE_KVM
+diff --git a/qemu/hw/pc.c b/qemu/hw/pc.c
+index 7bec234..f938fd0 100644
+--- a/qemu/hw/pc.c
++++ b/qemu/hw/pc.c
+@@ -163,16 +163,18 @@ static void cmos_init_hd(int type_ofs, int info_ofs, BlockDriverState *hd)
+ }
+ 
+ /* hd_table must contain 4 block drivers */
+-static void cmos_init(unsigned long ram_size, int boot_device, BlockDriverState **hd_table)
++static void cmos_init(unsigned long ram_size, unsigned long above_bios_ram_size, int boot_device, BlockDriverState **hd_table)
+ {
+     RTCState *s = rtc_state;
+     int val;
+     int fd0, fd1, nb;
+     int i;
++    unsigned long above_bios_mem_bits;
+ 
+     /* various important CMOS locations needed by PC/Bochs bios */
+ 
+     /* memory size */
++    if (ram_size > 0xf0000000)
+     val = 640; /* base memory in K */
+     rtc_set_memory(s, 0x15, val);
+     rtc_set_memory(s, 0x16, val >> 8);
+@@ -184,7 +186,12 @@ static void cmos_init(unsigned long ram_size, int boot_device, BlockDriverState
+     rtc_set_memory(s, 0x18, val >> 8);
+     rtc_set_memory(s, 0x30, val);
+     rtc_set_memory(s, 0x31, val >> 8);
+-
++    
++    val = (unsigned int)above_bios_ram_size / 65536;
++    rtc_set_memory(s, 0x5b, val);
++    rtc_set_memory(s, 0x5c, val >> 8);
++    rtc_set_memory(s, 0x5d, above_bios_ram_size/0x100000000);
++    
+     if (ram_size > (16 * 1024 * 1024))
+         val = (ram_size / 65536) - ((16 * 1024 * 1024) / 65536);
+     else
+@@ -465,14 +472,17 @@ static void pc_init1(unsigned long ram_size, int vga_ram_size, int boot_device,
+ {
+     char buf[1024];
+     int ret, linux_boot, initrd_size, i;
+-    unsigned long bios_offset, vga_bios_offset, option_rom_offset;
++    unsigned long bios_offset, vga_bios_offset, option_rom_offset, above_bios_mem_size = 0;
+     ram_addr_t initrd_offset;
+     int bios_size, isa_bios_size;
+     PCIBus *pci_bus;
+     int piix3_devfn = -1;
+     CPUState *env;
+     NICInfo *nd;
+-
++    if (ram_size + (phys_ram_size - ram_size) >= 0xf0000000 ) {
++        above_bios_mem_size = ram_size - 0xf0000000;;
++       	ram_size = 0xf0000000 - (phys_ram_size - ram_size);
++    }
+     linux_boot = (kernel_filename != NULL);
+ 
+     /* init CPUs */
+@@ -492,7 +502,9 @@ static void pc_init1(unsigned long ram_size, int vga_ram_size, int boot_device,
+     }
+ 
+     /* allocate RAM */
+-    cpu_register_physical_memory(0, ram_size, 0);
++    cpu_register_physical_memory(0, ram_size , 0);
++    if (above_bios_mem_size > 0)
++        cpu_register_physical_memory(0x100000000, above_bios_mem_size , 0x0);
+ 
+     /* BIOS load */
+     bios_offset = ram_size + vga_ram_size;
+@@ -668,11 +680,10 @@ static void pc_init1(unsigned long ram_size, int vga_ram_size, int boot_device,
+     register_ioport_write(0x80, 1, 1, ioport80_write, NULL);
+ 
+     register_ioport_write(0xf0, 1, 1, ioportF0_write, NULL);
+-
+     if (cirrus_vga_enabled) {
+         if (pci_enabled) {
+             pci_cirrus_vga_init(pci_bus, 
+-                                ds, phys_ram_base + ram_size, ram_size, 
++                                ds, phys_ram_base + ram_size , ram_size, 
+                                 vga_ram_size);
+         } else {
+             isa_cirrus_vga_init(ds, phys_ram_base + ram_size, ram_size, 
+@@ -687,7 +698,6 @@ static void pc_init1(unsigned long ram_size, int vga_ram_size, int boot_device,
+                          vga_ram_size);
+         }
+     }
+-
+     rtc_state = rtc_init(0x70, 8);
+ 
+     register_ioport_read(0x92, 1, 1, ioport92_read, NULL);
+@@ -756,7 +766,7 @@ static void pc_init1(unsigned long ram_size, int vga_ram_size, int boot_device,
+ 
+     floppy_controller = fdctrl_init(6, 2, 0, 0x3f0, fd_table);
+ 
+-    cmos_init(ram_size, boot_device, bs_table);
++    cmos_init(ram_size , above_bios_mem_size, boot_device, bs_table);
+ 
+     if (pci_enabled && usb_enabled) {
+         usb_uhci_init(pci_bus, piix3_devfn + 2);
+diff --git a/qemu/vl.c b/qemu/vl.c
+index 5dd6eec..b7d4c9f 100644
+--- a/qemu/vl.c
++++ b/qemu/vl.c
+@@ -7546,6 +7546,7 @@ int main(int argc, char **argv)
+ 		    exit(1);
+ 	    }
+     } else {
++		phys_ram_size += KVM_EXTRA_PAGES * 4096;
+ 	    phys_ram_base = qemu_vmalloc(phys_ram_size);
+ 	    if (!phys_ram_base) {
+ 		    fprintf(stderr, "Could not allocate physical memory\n");
+diff --git a/user/kvmctl.c b/user/kvmctl.c
+index 43b374d..b07f8a8 100644
+--- a/user/kvmctl.c
++++ b/user/kvmctl.c
+@@ -43,7 +43,7 @@ static int kvm_abi = EXPECTED_KVM_API_VERSION;
+ 
+ /* FIXME: share this number with kvm */
+ /* FIXME: or dynamically alloc/realloc regions */
+-#define KVM_MAX_NUM_MEM_REGIONS 4u
++#define KVM_MAX_NUM_MEM_REGIONS 5u
+ #define MAX_VCPUS 4
+ 
+ /**
+@@ -236,6 +236,7 @@ int kvm_create(kvm_context_t kvm, unsigned long memory, void **vm_mem)
+ {
+ 	unsigned long dosmem = 0xa0000;
+ 	unsigned long exmem = 0xc0000;
++	unsigned long pcimem = 0xf0000000;
+ 	int fd = kvm->fd;
+ 	int zfd;
+ 	int r;
+@@ -249,6 +250,14 @@ int kvm_create(kvm_context_t kvm, unsigned long memory, void **vm_mem)
+ 		.memory_size = memory < exmem ? 0 : memory - exmem,
+ 		.guest_phys_addr = exmem,
+ 	};
++	struct kvm_memory_region above_bios_memory = {
++		.slot = 4,
++		.memory_size = memory < pcimem ? 0 : memory - pcimem,
++		.guest_phys_addr = 0x100000000,
++	};
++
++	if (extended_memory.memory_size > pcimem)
++		extended_memory.memory_size = pcimem - exmem;
+ 
+ 	kvm->vcpu_fd[0] = -1;
+ 
+@@ -273,8 +282,17 @@ int kvm_create(kvm_context_t kvm, unsigned long memory, void **vm_mem)
+ 		}
+ 	}
+ 
++	if (above_bios_memory.memory_size) {
++		r = ioctl(fd, KVM_SET_MEMORY_REGION, &above_bios_memory);
++		if (r == -1) {
++			fprintf(stderr, "kvm_create_memory_region: %m\n");
++			return -1;
++		}
++	}
++
+ 	kvm_memory_region_save_params(kvm, &low_memory);
+ 	kvm_memory_region_save_params(kvm, &extended_memory);
++	kvm_memory_region_save_params(kvm, &above_bios_memory);
+ 
+ 	*vm_mem = mmap(NULL, memory, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
+ 	if (*vm_mem == MAP_FAILED) {
diff --git a/qemu/vl.c b/qemu/vl.c
index 5dd6eec..b7d4c9f 100644
--- a/qemu/vl.c
+++ b/qemu/vl.c
@@ -7546,6 +7546,7 @@ int main(int argc, char **argv)
 		    exit(1);
 	    }
     } else {
+		phys_ram_size += KVM_EXTRA_PAGES * 4096;
 	    phys_ram_base = qemu_vmalloc(phys_ram_size);
 	    if (!phys_ram_base) {
 		    fprintf(stderr, "Could not allocate physical memory\n");
diff --git a/user/kvmctl.c b/user/kvmctl.c
index 43b374d..b07f8a8 100644
--- a/user/kvmctl.c
+++ b/user/kvmctl.c
@@ -43,7 +43,7 @@ static int kvm_abi = EXPECTED_KVM_API_VERSION;
 
 /* FIXME: share this number with kvm */
 /* FIXME: or dynamically alloc/realloc regions */
-#define KVM_MAX_NUM_MEM_REGIONS 4u
+#define KVM_MAX_NUM_MEM_REGIONS 5u
 #define MAX_VCPUS 4
 
 /**
@@ -236,6 +236,7 @@ int kvm_create(kvm_context_t kvm, unsigned long memory, void **vm_mem)
 {
 	unsigned long dosmem = 0xa0000;
 	unsigned long exmem = 0xc0000;
+	unsigned long pcimem = 0xf0000000;
 	int fd = kvm->fd;
 	int zfd;
 	int r;
@@ -249,6 +250,14 @@ int kvm_create(kvm_context_t kvm, unsigned long memory, void **vm_mem)
 		.memory_size = memory < exmem ? 0 : memory - exmem,
 		.guest_phys_addr = exmem,
 	};
+	struct kvm_memory_region above_bios_memory = {
+		.slot = 4,
+		.memory_size = memory < pcimem ? 0 : memory - pcimem,
+		.guest_phys_addr = 0x100000000,
+	};
+
+	if (extended_memory.memory_size > pcimem)
+		extended_memory.memory_size = pcimem - exmem;
 
 	kvm->vcpu_fd[0] = -1;
 
@@ -273,8 +282,17 @@ int kvm_create(kvm_context_t kvm, unsigned long memory, void **vm_mem)
 		}
 	}
 
+	if (above_bios_memory.memory_size) {
+		r = ioctl(fd, KVM_SET_MEMORY_REGION, &above_bios_memory);
+		if (r == -1) {
+			fprintf(stderr, "kvm_create_memory_region: %m\n");
+			return -1;
+		}
+	}
+
 	kvm_memory_region_save_params(kvm, &low_memory);
 	kvm_memory_region_save_params(kvm, &extended_memory);
+	kvm_memory_region_save_params(kvm, &above_bios_memory);
 
 	*vm_mem = mmap(NULL, memory, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
 	if (*vm_mem == MAP_FAILED) {

[-- Attachment #7: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
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/

[-- Attachment #8: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: adding support for above 2giga to kvm (include patchs)

[Luca Tettamanti]

Il Sun, Aug 12, 2007 at 12:26:15PM -0700, Izik Eidus ha scritto: 
> this is a request for comment for patchs that allow kvm to run with more than 2 giga.
> there are 4 patchs.
> the first patch(biospatch): is for the bios:now the bios know how to map memory about the 0xf0000000-0xffffffff hole.
> 
> the second  patch(qemu_change_types_patch):is for qemu ram_size types:it change the variables that hold the ram_size to unsigned long,
> and it is based on patch from the qemu-devel list that targeted sparc.
> 
> the third patch(kvm_userspace_memmap):is for kvm and add to it another memory slot that hold the new memory region.

Hi,
can you use text/plain when attaching patches please (or better, put
them inline)?

I've a few minor comments:

> diff --git a/qemu/exec.c b/qemu/exec.c
> index f5cce06..e54711e 100644
> --- a/qemu/exec.c
> +++ b/qemu/exec.c
> @@ -69,7 +69,7 @@
>  #define TARGET_PHYS_ADDR_SPACE_BITS 42
>  #else
>  /* Note: for compatibility with kqemu, we use 32 bits for x86_64 */
> -#define TARGET_PHYS_ADDR_SPACE_BITS 32
> +#define TARGET_PHYS_ADDR_SPACE_BITS 42
>  #endif

Comment is no more correct.

>  #ifdef USE_KVM
> diff --git a/qemu/hw/pc.c b/qemu/hw/pc.c
> index 7bec234..f938fd0 100644
> --- a/qemu/hw/pc.c
> +++ b/qemu/hw/pc.c
> @@ -163,16 +163,18 @@ static void cmos_init_hd(int type_ofs, int info_ofs, BlockDriverState *hd)
>  }
>  
>  /* hd_table must contain 4 block drivers */
> -static void cmos_init(unsigned long ram_size, int boot_device, BlockDriverState **hd_table)
> +static void cmos_init(unsigned long ram_size, unsigned long above_bios_ram_size, int boot_device, BlockDriverState **hd_table)
>  {
>      RTCState *s = rtc_state;
>      int val;
>      int fd0, fd1, nb;
>      int i;
> +    unsigned long above_bios_mem_bits;
>  
>      /* various important CMOS locations needed by PC/Bochs bios */
>  
>      /* memory size */
> +    if (ram_size > 0xf0000000)
>      val = 640; /* base memory in K */

Missing indentation?

>      rtc_set_memory(s, 0x15, val);
>      rtc_set_memory(s, 0x16, val >> 8);
> @@ -184,7 +186,12 @@ static void cmos_init(unsigned long ram_size, int boot_device, BlockDriverState
>      rtc_set_memory(s, 0x18, val >> 8);
>      rtc_set_memory(s, 0x30, val);
>      rtc_set_memory(s, 0x31, val >> 8);
> -
> +    
> +    val = (unsigned int)above_bios_ram_size / 65536;
> +    rtc_set_memory(s, 0x5b, val);
> +    rtc_set_memory(s, 0x5c, val >> 8);
> +    rtc_set_memory(s, 0x5d, above_bios_ram_size/0x100000000);
> +    
>      if (ram_size > (16 * 1024 * 1024))
>          val = (ram_size / 65536) - ((16 * 1024 * 1024) / 65536);
>      else
> @@ -465,14 +472,17 @@ static void pc_init1(unsigned long ram_size, int vga_ram_size, int boot_device,
>  {
>      char buf[1024];
>      int ret, linux_boot, initrd_size, i;
> -    unsigned long bios_offset, vga_bios_offset, option_rom_offset;
> +    unsigned long bios_offset, vga_bios_offset, option_rom_offset, above_bios_mem_size = 0;
>      ram_addr_t initrd_offset;
>      int bios_size, isa_bios_size;
>      PCIBus *pci_bus;
>      int piix3_devfn = -1;
>      CPUState *env;
>      NICInfo *nd;
> -
> +    if (ram_size + (phys_ram_size - ram_size) >= 0xf0000000 ) {
> +        above_bios_mem_size = ram_size - 0xf0000000;;

Extra ; at the on the statement

> +       	ram_size = 0xf0000000 - (phys_ram_size - ram_size);
> +    }

You're mixing tab and spaces (style in QEMU seems to be 4 spaces for tab).
I've seen the same thing in biospatch btw.

>      linux_boot = (kernel_filename != NULL);
>  
>      /* init CPUs */
> @@ -492,7 +502,9 @@ static void pc_init1(unsigned long ram_size, int vga_ram_size, int boot_device,
>      }
>  
>      /* allocate RAM */
> -    cpu_register_physical_memory(0, ram_size, 0);
> +    cpu_register_physical_memory(0, ram_size , 0);

Spurious change.

> +    if (above_bios_mem_size > 0)
> +        cpu_register_physical_memory(0x100000000, above_bios_mem_size , 0x0);
                                                                        ^^
Style.

>      /* BIOS load */
>      bios_offset = ram_size + vga_ram_size;
> @@ -668,11 +680,10 @@ static void pc_init1(unsigned long ram_size, int vga_ram_size, int boot_device,
>      register_ioport_write(0x80, 1, 1, ioport80_write, NULL);
>  
>      register_ioport_write(0xf0, 1, 1, ioportF0_write, NULL);
> -
>      if (cirrus_vga_enabled) {
>          if (pci_enabled) {
>              pci_cirrus_vga_init(pci_bus, 
> -                                ds, phys_ram_base + ram_size, ram_size, 
> +                                ds, phys_ram_base + ram_size , ram_size, 
>                                  vga_ram_size);

style (space before comma)

>          } else {
>              isa_cirrus_vga_init(ds, phys_ram_base + ram_size, ram_size, 
> @@ -687,7 +698,6 @@ static void pc_init1(unsigned long ram_size, int vga_ram_size, int boot_device,
>                           vga_ram_size);
>          }
>      }
> -
>      rtc_state = rtc_init(0x70, 8);
>  
>      register_ioport_read(0x92, 1, 1, ioport92_read, NULL);
> @@ -756,7 +766,7 @@ static void pc_init1(unsigned long ram_size, int vga_ram_size, int boot_device,
>  
>      floppy_controller = fdctrl_init(6, 2, 0, 0x3f0, fd_table);
>  
> -    cmos_init(ram_size, boot_device, bs_table);
> +    cmos_init(ram_size , above_bios_mem_size, boot_device, bs_table);

ditto

>  
>      if (pci_enabled && usb_enabled) {
>          usb_uhci_init(pci_bus, piix3_devfn + 2);
> @@ -0,0 +1,178 @@
> +diff --git a/qemu/exec.c b/qemu/exec.c
> +index f5cce06..e54711e 100644
> +--- a/qemu/exec.c
> ++++ b/qemu/exec.c
> +@@ -69,7 +69,7 @@
> + #define TARGET_PHYS_ADDR_SPACE_BITS 42
> + #else
> + /* Note: for compatibility with kqemu, we use 32 bits for x86_64 */
> +-#define TARGET_PHYS_ADDR_SPACE_BITS 32
> ++#define TARGET_PHYS_ADDR_SPACE_BITS 42
> + #endif
> + 
> + #ifdef USE_KVM
> +diff --git a/qemu/hw/pc.c b/qemu/hw/pc.c
> +index 7bec234..f938fd0 100644
> +--- a/qemu/hw/pc.c
> ++++ b/qemu/hw/pc.c
[cut]

Hum, something went wrong with the patch here...

> diff --git a/qemu/vl.c b/qemu/vl.c
> index 5dd6eec..b7d4c9f 100644
> --- a/qemu/vl.c
> +++ b/qemu/vl.c
> @@ -7546,6 +7546,7 @@ int main(int argc, char **argv)
>  		    exit(1);
>  	    }
>      } else {
> +		phys_ram_size += KVM_EXTRA_PAGES * 4096;

Tabs instead of spaces

>  	    phys_ram_base = qemu_vmalloc(phys_ram_size);
>  	    if (!phys_ram_base) {
>  		    fprintf(stderr, "Could not allocate physical memory\n");
> diff --git a/user/kvmctl.c b/user/kvmctl.c
> index 43b374d..b07f8a8 100644
> --- a/user/kvmctl.c
> +++ b/user/kvmctl.c
> @@ -43,7 +43,7 @@ static int kvm_abi = EXPECTED_KVM_API_VERSION;
>  
>  /* FIXME: share this number with kvm */
>  /* FIXME: or dynamically alloc/realloc regions */
> -#define KVM_MAX_NUM_MEM_REGIONS 4u
> +#define KVM_MAX_NUM_MEM_REGIONS 5u
>  #define MAX_VCPUS 4
>  
>  /**
> @@ -236,6 +236,7 @@ int kvm_create(kvm_context_t kvm, unsigned long memory, void **vm_mem)
>  {
>  	unsigned long dosmem = 0xa0000;
>  	unsigned long exmem = 0xc0000;
> +	unsigned long pcimem = 0xf0000000;
>  	int fd = kvm->fd;
>  	int zfd;
>  	int r;
> @@ -249,6 +250,14 @@ int kvm_create(kvm_context_t kvm, unsigned long memory, void **vm_mem)
>  		.memory_size = memory < exmem ? 0 : memory - exmem,
>  		.guest_phys_addr = exmem,
>  	};
> +	struct kvm_memory_region above_bios_memory = {
> +		.slot = 4,
> +		.memory_size = memory < pcimem ? 0 : memory - pcimem,
> +		.guest_phys_addr = 0x100000000,
> +	};
> +
> +	if (extended_memory.memory_size > pcimem)
> +		extended_memory.memory_size = pcimem - exmem;
>  
>  	kvm->vcpu_fd[0] = -1;
>  
> @@ -273,8 +282,17 @@ int kvm_create(kvm_context_t kvm, unsigned long memory, void **vm_mem)
>  		}
>  	}
>  
> +	if (above_bios_memory.memory_size) {
> +		r = ioctl(fd, KVM_SET_MEMORY_REGION, &above_bios_memory);
> +		if (r == -1) {
> +			fprintf(stderr, "kvm_create_memory_region: %m\n");
> +			return -1;
> +		}
> +	}
> +
>  	kvm_memory_region_save_params(kvm, &low_memory);
>  	kvm_memory_region_save_params(kvm, &extended_memory);
> +	kvm_memory_region_save_params(kvm, &above_bios_memory);
>  
>  	*vm_mem = mmap(NULL, memory, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
>  	if (*vm_mem == MAP_FAILED) {

Luca
-- 
La differenza fra l'intelligenza e la stupidita`?
All'intelligenza c'e` un limite.

-------------------------------------------------------------------------
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/

Re: adding support for above 2giga to kvm (include patchs)

[Anthony Liguori]

Hi Izik,

Unfortunately, your mailer sent the patches out as binary attachments so
I can't reply easy inline so I'll just add comments here.

On Sun, 2007-08-12 at 12:26 -0700, Izik Eidus wrote:
> this is a request for comment for patchs that allow kvm to run with
> more than 2 giga.
> there are 4 patchs.
> the first patch(biospatch): is for the bios:now the bios know how to
> map memory about the 0xf0000000-0xffffffff hole.

You should definitely float this patch across the bochs list to see what
they think.  We had been working on a similar patch that behaved
slightly differently.  Ryan changed set_e820_range to take a value in
kilobytes and then adjusted the shifting accordingly.  I don't think
it's possible to have sub 1k regions in an e820 and this avoided having
to use a 64-bit type.  Using a structure is another option and probably
isn't a bad approach.  I think the one thing you may have to adjust is
the variable naming (MemMap => mem_map).

> the second  patch(qemu_change_types_patch):is for qemu ram_size
> types:it change the variables that hold the ram_size to unsigned
> long,
> and it is based on patch from the qemu-devel list that targeted sparc.

With the exception of the changes to i824patch (this looks like
something local to your repro), this looks fine (I don't think there are
any changes from BlueSwirl's original patch right?).

> the third patch(kvm_userspace_memmap):is for kvm and add to it another
> memory slot that hold the new memory region.

I think you should wrap the changing of TARGET_PHYS_ADDR_SPACE_BITS with
a USE_KQEMU so that we don't break kqemu support.  So:

 #define TARGET_PHYS_ADDR_SPACE_BITS 42
-#else
+#elif USE_KQEMU
 /* Note: for compatibility with kqemu, we use 32 bits for x86_64 */
 #define TARGET_PHYS_ADDR_SPACE_BITS 32
+#else
+#define TARGET_PHYS_ADDR_SPACE_BITS 42
 #endif

I'm a little curious why you chose a completely new location in CMOS for
the memory size.  Xen just used another byte in the same area as was
previously used.  There's a little whitespace damage in this patch too.

I'm a little confused too that this patch seems to be adding a patch
within it.

> the last patch(kvm_new_slot_patch):is for kvmctl, and make it use the
> new memory region and map memory above 4giga to it.

Very simple patch but obviously looks good :-)

> i added compiled bios for to make it easy to run it.
> 
> (kvm was tested with 14giga of ram and had no problem to drive win3k
> and fedora 6 + x ,please note that i tryed in the patch to add support
> to the qemu emulator to run with above 4 giga as well,
> it work without svga, need some work to do there)

Thanks for posting these patches!  We'll do some testing tomorrow on one
of our large memory boxes and let you know our results.

Regards,

Anthony Liguori


> -------------------------------------------------------------------------
> 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/
> _______________________________________________ kvm-devel mailing list kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org https://lists.sourceforge.net/lists/listinfo/kvm-devel


-------------------------------------------------------------------------
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/

Re: adding support for above 2giga to kvm (includepatchs)

[Izik Eidus]

[-- Attachment #1.1: Type: text/plain, Size: 9184 bytes --]

Hey Luca,
thanks for the quick response.
i agree with everything you wrote.
note that about the line:
> +    if (ram_size > 0xf0000000)
>      val = 640; /* base memory in K */
i don`t, how it entered to the code, this line is wrong and i will remove it, thanks!

anyway i will fix it all and send it again...

thanks.

-----הודעה מקורית-----
מאת: Luca Tettamanti [mailto:kronos.it-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
נשלח: א 12/08/2007 14:28
אל: Izik Eidus
עותק לידיעה: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
נושא: Re: [kvm-devel] adding support for above 2giga to kvm (includepatchs)
 
Il Sun, Aug 12, 2007 at 12:26:15PM -0700, Izik Eidus ha scritto: 
> this is a request for comment for patchs that allow kvm to run with more than 2 giga.
> there are 4 patchs.
> the first patch(biospatch): is for the bios:now the bios know how to map memory about the 0xf0000000-0xffffffff hole.
> 
> the second  patch(qemu_change_types_patch):is for qemu ram_size types:it change the variables that hold the ram_size to unsigned long,
> and it is based on patch from the qemu-devel list that targeted sparc.
> 
> the third patch(kvm_userspace_memmap):is for kvm and add to it another memory slot that hold the new memory region.

Hi,
can you use text/plain when attaching patches please (or better, put
them inline)?

I've a few minor comments:

> diff --git a/qemu/exec.c b/qemu/exec.c
> index f5cce06..e54711e 100644
> --- a/qemu/exec.c
> +++ b/qemu/exec.c
> @@ -69,7 +69,7 @@
>  #define TARGET_PHYS_ADDR_SPACE_BITS 42
>  #else
>  /* Note: for compatibility with kqemu, we use 32 bits for x86_64 */
> -#define TARGET_PHYS_ADDR_SPACE_BITS 32
> +#define TARGET_PHYS_ADDR_SPACE_BITS 42
>  #endif

Comment is no more correct.

>  #ifdef USE_KVM
> diff --git a/qemu/hw/pc.c b/qemu/hw/pc.c
> index 7bec234..f938fd0 100644
> --- a/qemu/hw/pc.c
> +++ b/qemu/hw/pc.c
> @@ -163,16 +163,18 @@ static void cmos_init_hd(int type_ofs, int info_ofs, BlockDriverState *hd)
>  }
>  
>  /* hd_table must contain 4 block drivers */
> -static void cmos_init(unsigned long ram_size, int boot_device, BlockDriverState **hd_table)
> +static void cmos_init(unsigned long ram_size, unsigned long above_bios_ram_size, int boot_device, BlockDriverState **hd_table)
>  {
>      RTCState *s = rtc_state;
>      int val;
>      int fd0, fd1, nb;
>      int i;
> +    unsigned long above_bios_mem_bits;
>  
>      /* various important CMOS locations needed by PC/Bochs bios */
>  
>      /* memory size */
> +    if (ram_size > 0xf0000000)
>      val = 640; /* base memory in K */

Missing indentation?

>      rtc_set_memory(s, 0x15, val);
>      rtc_set_memory(s, 0x16, val >> 8);
> @@ -184,7 +186,12 @@ static void cmos_init(unsigned long ram_size, int boot_device, BlockDriverState
>      rtc_set_memory(s, 0x18, val >> 8);
>      rtc_set_memory(s, 0x30, val);
>      rtc_set_memory(s, 0x31, val >> 8);
> -
> +    
> +    val = (unsigned int)above_bios_ram_size / 65536;
> +    rtc_set_memory(s, 0x5b, val);
> +    rtc_set_memory(s, 0x5c, val >> 8);
> +    rtc_set_memory(s, 0x5d, above_bios_ram_size/0x100000000);
> +    
>      if (ram_size > (16 * 1024 * 1024))
>          val = (ram_size / 65536) - ((16 * 1024 * 1024) / 65536);
>      else
> @@ -465,14 +472,17 @@ static void pc_init1(unsigned long ram_size, int vga_ram_size, int boot_device,
>  {
>      char buf[1024];
>      int ret, linux_boot, initrd_size, i;
> -    unsigned long bios_offset, vga_bios_offset, option_rom_offset;
> +    unsigned long bios_offset, vga_bios_offset, option_rom_offset, above_bios_mem_size = 0;
>      ram_addr_t initrd_offset;
>      int bios_size, isa_bios_size;
>      PCIBus *pci_bus;
>      int piix3_devfn = -1;
>      CPUState *env;
>      NICInfo *nd;
> -
> +    if (ram_size + (phys_ram_size - ram_size) >= 0xf0000000 ) {
> +        above_bios_mem_size = ram_size - 0xf0000000;;

Extra ; at the on the statement

> +       	ram_size = 0xf0000000 - (phys_ram_size - ram_size);
> +    }

You're mixing tab and spaces (style in QEMU seems to be 4 spaces for tab).
I've seen the same thing in biospatch btw.

>      linux_boot = (kernel_filename != NULL);
>  
>      /* init CPUs */
> @@ -492,7 +502,9 @@ static void pc_init1(unsigned long ram_size, int vga_ram_size, int boot_device,
>      }
>  
>      /* allocate RAM */
> -    cpu_register_physical_memory(0, ram_size, 0);
> +    cpu_register_physical_memory(0, ram_size , 0);

Spurious change.

> +    if (above_bios_mem_size > 0)
> +        cpu_register_physical_memory(0x100000000, above_bios_mem_size , 0x0);
                                                                        ^^
Style.

>      /* BIOS load */
>      bios_offset = ram_size + vga_ram_size;
> @@ -668,11 +680,10 @@ static void pc_init1(unsigned long ram_size, int vga_ram_size, int boot_device,
>      register_ioport_write(0x80, 1, 1, ioport80_write, NULL);
>  
>      register_ioport_write(0xf0, 1, 1, ioportF0_write, NULL);
> -
>      if (cirrus_vga_enabled) {
>          if (pci_enabled) {
>              pci_cirrus_vga_init(pci_bus, 
> -                                ds, phys_ram_base + ram_size, ram_size, 
> +                                ds, phys_ram_base + ram_size , ram_size, 
>                                  vga_ram_size);

style (space before comma)

>          } else {
>              isa_cirrus_vga_init(ds, phys_ram_base + ram_size, ram_size, 
> @@ -687,7 +698,6 @@ static void pc_init1(unsigned long ram_size, int vga_ram_size, int boot_device,
>                           vga_ram_size);
>          }
>      }
> -
>      rtc_state = rtc_init(0x70, 8);
>  
>      register_ioport_read(0x92, 1, 1, ioport92_read, NULL);
> @@ -756,7 +766,7 @@ static void pc_init1(unsigned long ram_size, int vga_ram_size, int boot_device,
>  
>      floppy_controller = fdctrl_init(6, 2, 0, 0x3f0, fd_table);
>  
> -    cmos_init(ram_size, boot_device, bs_table);
> +    cmos_init(ram_size , above_bios_mem_size, boot_device, bs_table);

ditto

>  
>      if (pci_enabled && usb_enabled) {
>          usb_uhci_init(pci_bus, piix3_devfn + 2);
> @@ -0,0 +1,178 @@
> +diff --git a/qemu/exec.c b/qemu/exec.c
> +index f5cce06..e54711e 100644
> +--- a/qemu/exec.c
> ++++ b/qemu/exec.c
> +@@ -69,7 +69,7 @@
> + #define TARGET_PHYS_ADDR_SPACE_BITS 42
> + #else
> + /* Note: for compatibility with kqemu, we use 32 bits for x86_64 */
> +-#define TARGET_PHYS_ADDR_SPACE_BITS 32
> ++#define TARGET_PHYS_ADDR_SPACE_BITS 42
> + #endif
> + 
> + #ifdef USE_KVM
> +diff --git a/qemu/hw/pc.c b/qemu/hw/pc.c
> +index 7bec234..f938fd0 100644
> +--- a/qemu/hw/pc.c
> ++++ b/qemu/hw/pc.c
[cut]

Hum, something went wrong with the patch here...

> diff --git a/qemu/vl.c b/qemu/vl.c
> index 5dd6eec..b7d4c9f 100644
> --- a/qemu/vl.c
> +++ b/qemu/vl.c
> @@ -7546,6 +7546,7 @@ int main(int argc, char **argv)
>  		    exit(1);
>  	    }
>      } else {
> +		phys_ram_size += KVM_EXTRA_PAGES * 4096;

Tabs instead of spaces

>  	    phys_ram_base = qemu_vmalloc(phys_ram_size);
>  	    if (!phys_ram_base) {
>  		    fprintf(stderr, "Could not allocate physical memory\n");
> diff --git a/user/kvmctl.c b/user/kvmctl.c
> index 43b374d..b07f8a8 100644
> --- a/user/kvmctl.c
> +++ b/user/kvmctl.c
> @@ -43,7 +43,7 @@ static int kvm_abi = EXPECTED_KVM_API_VERSION;
>  
>  /* FIXME: share this number with kvm */
>  /* FIXME: or dynamically alloc/realloc regions */
> -#define KVM_MAX_NUM_MEM_REGIONS 4u
> +#define KVM_MAX_NUM_MEM_REGIONS 5u
>  #define MAX_VCPUS 4
>  
>  /**
> @@ -236,6 +236,7 @@ int kvm_create(kvm_context_t kvm, unsigned long memory, void **vm_mem)
>  {
>  	unsigned long dosmem = 0xa0000;
>  	unsigned long exmem = 0xc0000;
> +	unsigned long pcimem = 0xf0000000;
>  	int fd = kvm->fd;
>  	int zfd;
>  	int r;
> @@ -249,6 +250,14 @@ int kvm_create(kvm_context_t kvm, unsigned long memory, void **vm_mem)
>  		.memory_size = memory < exmem ? 0 : memory - exmem,
>  		.guest_phys_addr = exmem,
>  	};
> +	struct kvm_memory_region above_bios_memory = {
> +		.slot = 4,
> +		.memory_size = memory < pcimem ? 0 : memory - pcimem,
> +		.guest_phys_addr = 0x100000000,
> +	};
> +
> +	if (extended_memory.memory_size > pcimem)
> +		extended_memory.memory_size = pcimem - exmem;
>  
>  	kvm->vcpu_fd[0] = -1;
>  
> @@ -273,8 +282,17 @@ int kvm_create(kvm_context_t kvm, unsigned long memory, void **vm_mem)
>  		}
>  	}
>  
> +	if (above_bios_memory.memory_size) {
> +		r = ioctl(fd, KVM_SET_MEMORY_REGION, &above_bios_memory);
> +		if (r == -1) {
> +			fprintf(stderr, "kvm_create_memory_region: %m\n");
> +			return -1;
> +		}
> +	}
> +
>  	kvm_memory_region_save_params(kvm, &low_memory);
>  	kvm_memory_region_save_params(kvm, &extended_memory);
> +	kvm_memory_region_save_params(kvm, &above_bios_memory);
>  
>  	*vm_mem = mmap(NULL, memory, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
>  	if (*vm_mem == MAP_FAILED) {

Luca
-- 
La differenza fra l'intelligenza e la stupidita`?
All'intelligenza c'e` un limite.


[-- Attachment #1.2: Type: text/html, Size: 16016 bytes --]

[-- Attachment #2: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
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/

[-- Attachment #3: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel

FW: adding support for above 2giga to kvm (includepatchs)

[Izik Eidus]

[-- Attachment #1.1: Type: text/plain, Size: 5160 bytes --]




-----הודעה מקורית-----
מאת: Izik Eidus
נשלח: א 12/08/2007 15:34
אל: Anthony Liguori
נושא: RE: [kvm-devel] adding support for above 2giga to kvm (includepatchs)
 
Hey Anthony , thanks for quick comment!.
i will fix the mail problem, and post it to bochs list.
you are right about the kqemu, this will be fix as well.

about the CMOS, i had alot of thinking about where to put the new memory information.
i had few options, and i selected this one just beacuse it was the easiest way to go,
(with understanding that better place should be found)
modern pc computers probbley take this kind of information from the chipset, so i didnt
had any standard place to hold this information.
anyway i agree that the selected position at the "future reserved" bytes is bad.

this would be great if you can test this patchs at your place.
i had successfully ran it with 14giga fedora 6 + X,
note that it isnt really recommended to run it with --no-kvm
i want to fix this issue ( i could get qemu to work in cases i didnt use the X ), but i think i will wait
untill kvm catch with the latest CVS from qemu, (looking there i saw they changed some things that are relevant).

(my guess is that it is found in the svga area, (kvm use diffrent code to allocate memory there and this probbley why it pass
it without fail).

any problem even the tiny that you face with it, please let me know, and i will response as fast as i can. 
thanks.
 
-----הודעה מקורית-----
מאת: Anthony Liguori [mailto:anthony-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org]
נשלח: א 12/08/2007 14:30
אל: Izik Eidus
עותק לידיעה: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org; Ryan Harper
נושא: Re: [kvm-devel] adding support for above 2giga to kvm (includepatchs)
 

Hi Izik,

Unfortunately, your mailer sent the patches out as binary attachments so
I can't reply easy inline so I'll just add comments here.

On Sun, 2007-08-12 at 12:26 -0700, Izik Eidus wrote:
> this is a request for comment for patchs that allow kvm to run with
> more than 2 giga.
> there are 4 patchs.
> the first patch(biospatch): is for the bios:now the bios know how to
> map memory about the 0xf0000000-0xffffffff hole.

You should definitely float this patch across the bochs list to see what
they think.  We had been working on a similar patch that behaved
slightly differently.  Ryan changed set_e820_range to take a value in
kilobytes and then adjusted the shifting accordingly.  I don't think
it's possible to have sub 1k regions in an e820 and this avoided having
to use a 64-bit type.  Using a structure is another option and probably
isn't a bad approach.  I think the one thing you may have to adjust is
the variable naming (MemMap => mem_map).

> the second  patch(qemu_change_types_patch):is for qemu ram_size
> types:it change the variables that hold the ram_size to unsigned
> long,
> and it is based on patch from the qemu-devel list that targeted sparc.

With the exception of the changes to i824patch (this looks like
something local to your repro), this looks fine (I don't think there are
any changes from BlueSwirl's original patch right?).

> the third patch(kvm_userspace_memmap):is for kvm and add to it another
> memory slot that hold the new memory region.

I think you should wrap the changing of TARGET_PHYS_ADDR_SPACE_BITS with
a USE_KQEMU so that we don't break kqemu support.  So:

 #define TARGET_PHYS_ADDR_SPACE_BITS 42
-#else
+#elif USE_KQEMU
 /* Note: for compatibility with kqemu, we use 32 bits for x86_64 */
 #define TARGET_PHYS_ADDR_SPACE_BITS 32
+#else
+#define TARGET_PHYS_ADDR_SPACE_BITS 42
 #endif

I'm a little curious why you chose a completely new location in CMOS for
the memory size.  Xen just used another byte in the same area as was
previously used.  There's a little whitespace damage in this patch too.

I'm a little confused too that this patch seems to be adding a patch
within it.

> the last patch(kvm_new_slot_patch):is for kvmctl, and make it use the
> new memory region and map memory above 4giga to it.

Very simple patch but obviously looks good :-)

> i added compiled bios for to make it easy to run it.
> 
> (kvm was tested with 14giga of ram and had no problem to drive win3k
> and fedora 6 + x ,please note that i tryed in the patch to add support
> to the qemu emulator to run with above 4 giga as well,
> it work without svga, need some work to do there)

Thanks for posting these patches!  We'll do some testing tomorrow on one
of our large memory boxes and let you know our results.

Regards,

Anthony Liguori


> -------------------------------------------------------------------------
> 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/
> _______________________________________________ kvm-devel mailing list kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org https://lists.sourceforge.net/lists/listinfo/kvm-devel




[-- Attachment #1.2: Type: text/html, Size: 6402 bytes --]

[-- Attachment #2: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
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/

[-- Attachment #3: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: adding support for above 2giga to kvm (include patchs)

[Ryan Harper]

* Izik Eidus <izik.eidus-atKUWr5tajBWk0Htik3J/w@public.gmane.org> [2007-08-12 14:27]:
> this is a request for comment for patchs that allow kvm to run with more than 2 giga.
> there are 4 patchs.
> the first patch(biospatch): is for the bios:now the bios know how to map memory about the 0xf0000000-0xffffffff hole.
> 
> the second  patch(qemu_change_types_patch):is for qemu ram_size types:it change the variables that hold the ram_size to unsigned long,
> and it is based on patch from the qemu-devel list that targeted sparc.
> 
> the third patch(kvm_userspace_memmap):is for kvm and add to it another memory slot that hold the new memory region.
> 
> the last patch(kvm_new_slot_patch):is for kvmctl, and make it use the new memory region and map memory above 4giga to it.
> 
> i added compiled bios for to make it easy to run it.
> 
> (kvm was tested with 14giga of ram and had no problem to drive win3k and fedora 6 + x ,please note that i tryed in the patch to add support to the qemu emulator to run with above 4 giga as well,
> it work without svga, need some work to do there)

I can confirm the patches working against kvm-33 with up to 14G guests,
tested 32-bit Feisty guest, and 64-bit feisty guest.  Both working
fine.  I'm trying to get on a box with more ram so I can test larger
guests.

--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253   T/L: 678-9253
ryanh-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org

-------------------------------------------------------------------------
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/

Re: adding support for above 2giga to kvm (include patchs)

[Ryan Harper]

* Ryan Harper <ryanh-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> [2007-08-13 15:29]:
> * Izik Eidus <izik.eidus-atKUWr5tajBWk0Htik3J/w@public.gmane.org> [2007-08-12 14:27]:
> > this is a request for comment for patchs that allow kvm to run with more than 2 giga.
> > there are 4 patchs.
> > the first patch(biospatch): is for the bios:now the bios know how to map memory about the 0xf0000000-0xffffffff hole.
> > 
> > the second  patch(qemu_change_types_patch):is for qemu ram_size types:it change the variables that hold the ram_size to unsigned long,
> > and it is based on patch from the qemu-devel list that targeted sparc.
> > 
> > the third patch(kvm_userspace_memmap):is for kvm and add to it another memory slot that hold the new memory region.
> > 
> > the last patch(kvm_new_slot_patch):is for kvmctl, and make it use the new memory region and map memory above 4giga to it.
> > 
> > i added compiled bios for to make it easy to run it.
> > 
> > (kvm was tested with 14giga of ram and had no problem to drive win3k and fedora 6 + x ,please note that i tryed in the patch to add support to the qemu emulator to run with above 4 giga as well,
> > it work without svga, need some work to do there)
> 
> I can confirm the patches working against kvm-33 with up to 14G guests,
> tested 32-bit Feisty guest, and 64-bit feisty guest.  Both working
> fine.  I'm trying to get on a box with more ram so I can test larger
> guests.

I can confirm 32G x86_64 feisty guest boots and reports 32G of ram.
Good work.


-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253   T/L: 678-9253
ryanh-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org

-------------------------------------------------------------------------
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/

FW: adding support for above 2giga to kvm (include patchs)

[Izik Eidus]

[-- Attachment #1.1: Type: text/plain, Size: 3005 bytes --]

Hey Ryan,
thanks for the testing, i hope you didnt have too much problems to get it working.
anyway as far as i can tell it wont have problem to drive up to 256 + 3.75 giga ram for guest.
if we want it to drive systems with even more ram we have two options ( both very easily applied ):
we can add another cmos byte to a "future reserved" byte, or we can use the 3 cmos bytes that i already added and say that
we store memory in the above bios memory at multiplier of 1 MB.  
it is important we decide now how we want to store the memory, that in the future when 256 + 3.75 giga of ram wont be enough
we wouldn't have to change bochs bios again.
i am working for fixes to the patch from comments that Anthony and Luca gave me, so i hope to send a better patch to the list soon.

thanks again,
have a nice day :)

-----Original Message-----
From: Ryan Harper [mailto:ryanh-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org]
Sent: Mon 8/13/2007 7:22 PM
To: Izik Eidus; kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [kvm-devel] adding support for above 2giga to kvm (include patchs)
 
* Ryan Harper <ryanh-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> [2007-08-13 15:29]:
> * Izik Eidus <izik.eidus-atKUWr5tajBWk0Htik3J/w@public.gmane.org> [2007-08-12 14:27]:
> > this is a request for comment for patchs that allow kvm to run with more than 2 giga.
> > there are 4 patchs.
> > the first patch(biospatch): is for the bios:now the bios know how to map memory about the 0xf0000000-0xffffffff hole.
> > 
> > the second  patch(qemu_change_types_patch):is for qemu ram_size types:it change the variables that hold the ram_size to unsigned long,
> > and it is based on patch from the qemu-devel list that targeted sparc.
> > 
> > the third patch(kvm_userspace_memmap):is for kvm and add to it another memory slot that hold the new memory region.
> > 
> > the last patch(kvm_new_slot_patch):is for kvmctl, and make it use the new memory region and map memory above 4giga to it.
> > 
> > i added compiled bios for to make it easy to run it.
> > 
> > (kvm was tested with 14giga of ram and had no problem to drive win3k and fedora 6 + x ,please note that i tryed in the patch to add support to the qemu emulator to run with above 4 giga as well,
> > it work without svga, need some work to do there)
> 
> I can confirm the patches working against kvm-33 with up to 14G guests,
> tested 32-bit Feisty guest, and 64-bit feisty guest.  Both working
> fine.  I'm trying to get on a box with more ram so I can test larger
> guests.



-----Original Message-----
From: Izik Eidus
Sent: Mon 8/13/2007 11:28 PM
To: Ryan Harper
Subject: RE: [kvm-devel] adding support for above 2giga to kvm (include patchs)
 
I can confirm 32G x86_64 feisty guest boots and reports 32G of ram.
Good work.


-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253   T/L: 678-9253
ryanh-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org



[-- Attachment #1.2: Type: text/html, Size: 3883 bytes --]

[-- Attachment #2: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
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/

[-- Attachment #3: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: adding support for above 2giga to kvm (include patchs)

[Izik Eidus]

On Tue, 2007-08-14 at 10:09 -0500, Ryan Harper wrote:
> * Izik Eidus <izik.eidus-atKUWr5tajBWk0Htik3J/w@public.gmane.org> [2007-08-14 01:29]:
> > Hey Ryan,
> > thanks for the testing, i hope you didnt have too much problems to get it working.
> 
> Sure, it wasn't too much trouble.  
> 
> > anyway as far as i can tell it wont have problem to drive up to 256 + 3.75 giga ram for guest.
> > if we want it to drive systems with even more ram we have two options ( both very easily applied ):
> > we can add another cmos byte to a "future reserved" byte, or we can use the 3 cmos bytes that i already added and say that
> > we store memory in the above bios memory at multiplier of 1 MB.  
> > it is important we decide now how we want to store the memory, that in the future when 256 + 3.75 giga of ram wont be enough
> > we wouldn't have to change bochs bios again.
> 
> Yeah, I think we want to settle on a single method which gets us the
> most memory as possible.  I think rather than doing the "future reserve"
> we should go head an move over to 1MB multiplier.
> 
well this sound like a smart idea,
but what we have to think about is:
first in this way we have just 64 gigabyte of ram (unless we work with
the extra cmos memory bytes)
plus if we change the way we use the "normal cmos bytes", we arent
breaking compatibility with really old stuff that check the cmos
directly without doing bios interrupt? (i mean by ports)

> > i am working for fixes to the patch from comments that Anthony and
> > Luca gave me, so i hope to send a better patch to the list soon.
> 
> Great!  Look forward to seeing the new patchset.
> 
> 

i already sent the list new patchs before i saw this mail, so the cmos
problem will be handled in the next time.

thanks


-------------------------------------------------------------------------
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/

Re: adding support for above 2giga to kvm (include patchs)

[Ryan Harper]

* Izik Eidus <izike-atKUWr5tajBWk0Htik3J/w@public.gmane.org> [2007-08-14 10:49]:
> On Tue, 2007-08-14 at 10:09 -0500, Ryan Harper wrote:
> > * Izik Eidus <izik.eidus-atKUWr5tajBWk0Htik3J/w@public.gmane.org> [2007-08-14 01:29]:
> > > Hey Ryan,
> > > thanks for the testing, i hope you didnt have too much problems to get it working.
> > 
> > Sure, it wasn't too much trouble.  
> > 
> > > anyway as far as i can tell it wont have problem to drive up to 256 + 3.75 giga ram for guest.
> > > if we want it to drive systems with even more ram we have two options ( both very easily applied ):
> > > we can add another cmos byte to a "future reserved" byte, or we can use the 3 cmos bytes that i already added and say that
> > > we store memory in the above bios memory at multiplier of 1 MB.  
> > > it is important we decide now how we want to store the memory, that in the future when 256 + 3.75 giga of ram wont be enough
> > > we wouldn't have to change bochs bios again.
> > 
> > Yeah, I think we want to settle on a single method which gets us the
> > most memory as possible.  I think rather than doing the "future reserve"
> > we should go head an move over to 1MB multiplier.
> > 
> well this sound like a smart idea,
> but what we have to think about is:
> first in this way we have just 64 gigabyte of ram (unless we work with
> the extra cmos memory bytes)
> plus if we change the way we use the "normal cmos bytes", we arent
> breaking compatibility with really old stuff that check the cmos
> directly without doing bios interrupt? (i mean by ports)

Hrm, yes.  This might be an issue already.  I just booted memtest-86
v3.3 with 6G, and memtest says we have 528G of RAM.  Hrm, even below 2G,
memtest still reports bogus memory values.

We might need to go look at a newer BIOS spec to see how this is done in
newer bioses.

-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253   T/L: 678-9253
ryanh-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org

-------------------------------------------------------------------------
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/

Re: adding support for above 2giga to kvm (include patchs)

[Izik Eidus]

On Tue, 2007-08-14 at 13:24 -0500, Ryan Harper wrote:
> * Izik Eidus <izike-atKUWr5tajBWk0Htik3J/w@public.gmane.org> [2007-08-14 10:49]:
> > On Tue, 2007-08-14 at 10:09 -0500, Ryan Harper wrote:
> > > * Izik Eidus <izik.eidus-atKUWr5tajBWk0Htik3J/w@public.gmane.org> [2007-08-14 01:29]:
> > > > Hey Ryan,
> > > > thanks for the testing, i hope you didnt have too much problems to get it working.
> > > 
> > > Sure, it wasn't too much trouble.  
> > > 
> > > > anyway as far as i can tell it wont have problem to drive up to 256 + 3.75 giga ram for guest.
> > > > if we want it to drive systems with even more ram we have two options ( both very easily applied ):
> > > > we can add another cmos byte to a "future reserved" byte, or we can use the 3 cmos bytes that i already added and say that
> > > > we store memory in the above bios memory at multiplier of 1 MB.  
> > > > it is important we decide now how we want to store the memory, that in the future when 256 + 3.75 giga of ram wont be enough
> > > > we wouldn't have to change bochs bios again.
> > > 
> > > Yeah, I think we want to settle on a single method which gets us the
> > > most memory as possible.  I think rather than doing the "future reserve"
> > > we should go head an move over to 1MB multiplier.
> > > 
> > well this sound like a smart idea,
> > but what we have to think about is:
> > first in this way we have just 64 gigabyte of ram (unless we work with
> > the extra cmos memory bytes)
> > plus if we change the way we use the "normal cmos bytes", we arent
> > breaking compatibility with really old stuff that check the cmos
> > directly without doing bios interrupt? (i mean by ports)
> 
> Hrm, yes.  This might be an issue already.  I just booted memtest-86
> v3.3 with 6G, and memtest says we have 528G of RAM.  Hrm, even below 2G,
> memtest still reports bogus memory values.

memtest-86, report false memory values when the system is below 2G ?, in
this case i guess it isnt our fault...
memtest-86 was derived originally from linux 1.x i dont know if it even
support above 4 giga of ram.

without the patch what result do you get from this memtest when runing
below 2giga?

(win2003 get good memory information on 14giga guest as well, so i guess
the e820 from the bios interrupt side, is right)

> We might need to go look at a newer BIOS spec to see how this is done in
> newer bioses.
> 


-------------------------------------------------------------------------
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/

Re: adding support for above 2giga to kvm (include patchs)

[Ryan Harper]

* Izik Eidus <izike-atKUWr5tajBWk0Htik3J/w@public.gmane.org> [2007-08-14 13:59]:
> On Tue, 2007-08-14 at 13:24 -0500, Ryan Harper wrote:
> > * Izik Eidus <izike-atKUWr5tajBWk0Htik3J/w@public.gmane.org> [2007-08-14 10:49]:
> > > On Tue, 2007-08-14 at 10:09 -0500, Ryan Harper wrote:
> > > > * Izik Eidus <izik.eidus-atKUWr5tajBWk0Htik3J/w@public.gmane.org> [2007-08-14 01:29]:
> > > > > Hey Ryan,
> > > > > thanks for the testing, i hope you didnt have too much problems to get it working.
> > > > 
> > > > Sure, it wasn't too much trouble.  
> > > > 
> > > > > anyway as far as i can tell it wont have problem to drive up to 256 + 3.75 giga ram for guest.
> > > > > if we want it to drive systems with even more ram we have two options ( both very easily applied ):
> > > > > we can add another cmos byte to a "future reserved" byte, or we can use the 3 cmos bytes that i already added and say that
> > > > > we store memory in the above bios memory at multiplier of 1 MB.  
> > > > > it is important we decide now how we want to store the memory, that in the future when 256 + 3.75 giga of ram wont be enough
> > > > > we wouldn't have to change bochs bios again.
> > > > 
> > > > Yeah, I think we want to settle on a single method which gets us the
> > > > most memory as possible.  I think rather than doing the "future reserve"
> > > > we should go head an move over to 1MB multiplier.
> > > > 
> > > well this sound like a smart idea,
> > > but what we have to think about is:
> > > first in this way we have just 64 gigabyte of ram (unless we work with
> > > the extra cmos memory bytes)
> > > plus if we change the way we use the "normal cmos bytes", we arent
> > > breaking compatibility with really old stuff that check the cmos
> > > directly without doing bios interrupt? (i mean by ports)
> > 
> > Hrm, yes.  This might be an issue already.  I just booted memtest-86
> > v3.3 with 6G, and memtest says we have 528G of RAM.  Hrm, even below 2G,
> > memtest still reports bogus memory values.
> 
> memtest-86, report false memory values when the system is below 2G ?, in
> this case i guess it isnt our fault...
> memtest-86 was derived originally from linux 1.x i dont know if it even
> support above 4 giga of ram.
> 
> without the patch what result do you get from this memtest when runing
> below 2giga?

It is accurate without the patch.  It can see up to 2039M guest with no
changes to QEMU.  Also, if you apply the qemu size patch (s/int/unsigned
long) you can get up to 3831M guest to run without changing the
BIOS.  The memtest isos I've tried have no problem seeing that.

> 
> (win2003 get good memory information on 14giga guest as well, so i guess
> the e820 from the bios interrupt side, is right)

Yes, I've looked at the e820 and that looks perfectly fine.  Not sure
what the issue here is.  I'll see if I can track it down though.

> > We might need to go look at a newer BIOS spec to see how this is done in
> > newer bioses.
> > 

-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253   T/L: 678-9253
ryanh-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org

-------------------------------------------------------------------------
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/

Re: adding support for above 2giga to kvm (include patchs)

[Izik Eidus]

i am very interested about the fact that it gave you false results when
you ran it with mem size below 0xf0000000,
beacuse in this case the bios patch have no effect, at least it
shouldnt.

can you try to drive memtest86 on a real physical host with more than
4giga ?

On Tue, 2007-08-14 at 14:26 -0500, Ryan Harper wrote:
> * Izik Eidus <izike-atKUWr5tajBWk0Htik3J/w@public.gmane.org> [2007-08-14 13:59]:
> > On Tue, 2007-08-14 at 13:24 -0500, Ryan Harper wrote:
> > > * Izik Eidus <izike-atKUWr5tajBWk0Htik3J/w@public.gmane.org> [2007-08-14 10:49]:
> > > > On Tue, 2007-08-14 at 10:09 -0500, Ryan Harper wrote:
> > > > > * Izik Eidus <izik.eidus-atKUWr5tajBWk0Htik3J/w@public.gmane.org> [2007-08-14 01:29]:
> > > > > > Hey Ryan,
> > > > > > thanks for the testing, i hope you didnt have too much problems to get it working.
> > > > > 
> > > > > Sure, it wasn't too much trouble.  
> > > > > 
> > > > > > anyway as far as i can tell it wont have problem to drive up to 256 + 3.75 giga ram for guest.
> > > > > > if we want it to drive systems with even more ram we have two options ( both very easily applied ):
> > > > > > we can add another cmos byte to a "future reserved" byte, or we can use the 3 cmos bytes that i already added and say that
> > > > > > we store memory in the above bios memory at multiplier of 1 MB.  
> > > > > > it is important we decide now how we want to store the memory, that in the future when 256 + 3.75 giga of ram wont be enough
> > > > > > we wouldn't have to change bochs bios again.
> > > > > 
> > > > > Yeah, I think we want to settle on a single method which gets us the
> > > > > most memory as possible.  I think rather than doing the "future reserve"
> > > > > we should go head an move over to 1MB multiplier.
> > > > > 
> > > > well this sound like a smart idea,
> > > > but what we have to think about is:
> > > > first in this way we have just 64 gigabyte of ram (unless we work with
> > > > the extra cmos memory bytes)
> > > > plus if we change the way we use the "normal cmos bytes", we arent
> > > > breaking compatibility with really old stuff that check the cmos
> > > > directly without doing bios interrupt? (i mean by ports)
> > > 
> > > Hrm, yes.  This might be an issue already.  I just booted memtest-86
> > > v3.3 with 6G, and memtest says we have 528G of RAM.  Hrm, even below 2G,
> > > memtest still reports bogus memory values.
> > 
> > memtest-86, report false memory values when the system is below 2G ?, in
> > this case i guess it isnt our fault...
> > memtest-86 was derived originally from linux 1.x i dont know if it even
> > support above 4 giga of ram.
> > 
> > without the patch what result do you get from this memtest when runing
> > below 2giga?
> 
> It is accurate without the patch.  It can see up to 2039M guest with no
> changes to QEMU.  Also, if you apply the qemu size patch (s/int/unsigned
> long) you can get up to 3831M guest to run without changing the
> BIOS.  The memtest isos I've tried have no problem seeing that.
> 
> > 
> > (win2003 get good memory information on 14giga guest as well, so i guess
> > the e820 from the bios interrupt side, is right)
> 
> Yes, I've looked at the e820 and that looks perfectly fine.  Not sure
> what the issue here is.  I'll see if I can track it down though.
> 
> > > We might need to go look at a newer BIOS spec to see how this is done in
> > > newer bioses.
> > > 
> 


-------------------------------------------------------------------------
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/

Re: adding support for above 2giga to kvm (include patchs)

[Ryan Harper]

* Izik Eidus <izike-atKUWr5tajBWk0Htik3J/w@public.gmane.org> [2007-08-14 14:41]:
> i am very interested about the fact that it gave you false results when
> you ran it with mem size below 0xf0000000,
> beacuse in this case the bios patch have no effect, at least it
> shouldnt.

Agreed =)  I'll let you know if I figure anything out here.  I'm
switching to your latest set of patches and starting to debug it.

> can you try to drive memtest86 on a real physical host with more than
> 4giga ?

Yeah.  


-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253   T/L: 678-9253
ryanh-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org

-------------------------------------------------------------------------
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/

Re: adding support for above 2giga to kvm (include patchs)

[Izik Eidus]

i am sorry, i wrote you message and it get messed.

anyway you remember in the old patch the:
+    if (ram_size > 0xf0000000)
>      val = 640; /* base memory in K */
i bet this is the problem :)

in the new patch it is removed.


On Tue, 2007-08-14 at 14:46 -0500, Ryan Harper wrote:
> * Izik Eidus <izike-atKUWr5tajBWk0Htik3J/w@public.gmane.org> [2007-08-14 14:41]:
> > i am very interested about the fact that it gave you false results when
> > you ran it with mem size below 0xf0000000,
> > beacuse in this case the bios patch have no effect, at least it
> > shouldnt.
> 
> Agreed =)  I'll let you know if I figure anything out here.  I'm
> switching to your latest set of patches and starting to debug it.
> 
> > can you try to drive memtest86 on a real physical host with more than
> > 4giga ?
> 
> Yeah.  
> 
> 


-------------------------------------------------------------------------
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/

Re: adding support for above 2giga to kvm (include patchs)

[Ryan Harper]

* Izik Eidus <izike-atKUWr5tajBWk0Htik3J/w@public.gmane.org> [2007-08-14 15:00]:
> i am sorry, i wrote you message and it get messed.
> 
> anyway you remember in the old patch the:
> +    if (ram_size > 0xf0000000)
> >      val = 640; /* base memory in K */
> i bet this is the problem :)

I removed that now and I didn't help =(


-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253   T/L: 678-9253
ryanh-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org

-------------------------------------------------------------------------
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/

Re: adding support for above 2giga to kvm (include patchs)

[Izik Eidus]

On Tue, 2007-08-14 at 15:44 -0500, Ryan Harper wrote:
> * Izik Eidus <izike-atKUWr5tajBWk0Htik3J/w@public.gmane.org> [2007-08-14 15:00]:
> > i am sorry, i wrote you message and it get messed.
> > 
> > anyway you remember in the old patch the:
> > +    if (ram_size > 0xf0000000)
> > >      val = 640; /* base memory in K */
> > i bet this is the problem :)
> 
> I removed that now and I didn't help =(
hmmm, memtest86 use e820 as far as i saw, so i am clueless to what could
it be.

but there is one option. when i compiled the bios i used the latest bios
from the bochscvs and all i did was remove from // the qemuuse #define,
and i didnt add the qemu bios patch, so maybe it is this?
(i guess no, if it return to us bad result when using it with mem size
below 2giga, i guess checking not patched qemu bios with this code can
tell us if it something i changed in qemu or in the bios)

anyway i will try now to run this memtest86 tests as well.
> 


-------------------------------------------------------------------------
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/

Re: adding support for above 2giga to kvm (include patchs)

[Ryan Harper]

* Ryan Harper <ryanh-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> [2007-08-14 15:44]:
> * Izik Eidus <izike-atKUWr5tajBWk0Htik3J/w@public.gmane.org> [2007-08-14 15:00]:
> > i am sorry, i wrote you message and it get messed.
> > 
> > anyway you remember in the old patch the:
> > +    if (ram_size > 0xf0000000)
> > >      val = 640; /* base memory in K */
> > i bet this is the problem :)
> 
> I removed that now and I didn't help =(
 
So, I don't think passing the structure as a pointer works.  The 16-bit
compiler bcc has a number of quirks.  I don't pretend to understand what
the issue is here, but, changing the signature of set_e820_range() to:

void set_e820_range(ES, DI, start, end, extra_start, extra_end, type)
     Bit16u ES;
     Bit16u DI;
     Bit32u start;
     Bit32u end;
     Bit16u extra_start;
     Bit8u  extra_end;
     Bit16u type;
{

and the callers accordingly, fixes the issue with memtest iso.  I can
still boot guests with more than 4G, and memtest sees the correct
amount, above and below 4G.

-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253   T/L: 678-9253
ryanh-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org

-------------------------------------------------------------------------
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/

Re: adding support for above 2giga to kvm (include patchs)

[Anthony Liguori]

On Tue, 2007-08-14 at 17:21 -0500, Ryan Harper wrote:
> * Ryan Harper <ryanh-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> [2007-08-14 15:44]:
> > * Izik Eidus <izike-atKUWr5tajBWk0Htik3J/w@public.gmane.org> [2007-08-14 15:00]:
> > > i am sorry, i wrote you message and it get messed.
> > > 
> > > anyway you remember in the old patch the:
> > > +    if (ram_size > 0xf0000000)
> > > >      val = 640; /* base memory in K */
> > > i bet this is the problem :)
> > 
> > I removed that now and I didn't help =(
>  
> So, I don't think passing the structure as a pointer works.  The 16-bit
> compiler bcc has a number of quirks.  I don't pretend to understand what
> the issue is here, but, changing the signature of set_e820_range() to:

A pointer on the stack is not the same as a normal pointer in 16-bit
mode (one is relative to the stack segment and the other is relative to
data segment).

It may be that when Linux and Windows make calls into e820, ds == ss but
when memtest86 does, ds != ss.  I suspect this is why the BOCHS bios
code goes out of it's way to pass everything by value (and why there are
so many functions with a huge number of arguments).

I've had this issue myself with the SCSI boot ROM.

Regards,

Anthony Liguori

> void set_e820_range(ES, DI, start, end, extra_start, extra_end, type)
>      Bit16u ES;
>      Bit16u DI;
>      Bit32u start;
>      Bit32u end;
>      Bit16u extra_start;
>      Bit8u  extra_end;
>      Bit16u type;
> {
> 
> and the callers accordingly, fixes the issue with memtest iso.  I can
> still boot guests with more than 4G, and memtest sees the correct
> amount, above and below 4G.
> 


-------------------------------------------------------------------------
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/

Re: adding support for above 2giga to kvm (include patchs)

[Izik Eidus]

On Tue, 2007-08-14 at 17:21 -0500, Ryan Harper wrote:
> So, I don't think passing the structure as a pointer works.  The 16-bit
> compiler bcc has a number of quirks.  I don't pretend to understand what
> the issue is here, but, changing the signature of set_e820_range() to:
> 
> void set_e820_range(ES, DI, start, end, extra_start, extra_end, type)
>      Bit16u ES;
>      Bit16u DI;
>      Bit32u start;
>      Bit32u end;
>      Bit16u extra_start;
>      Bit8u  extra_end;
>      Bit16u type;
> {
> 
> and the callers accordingly, fixes the issue with memtest iso.  I can
> still boot guests with more than 4G, and memtest sees the correct
> amount, above and below 4G.
> 

can you send the the diff and the compiled bios?
i am getting some sort of stack overflow if i try to pass many
arguments, and this was the reason i used pointer to struck from the
beginning.

thanks, and good work!
 


-------------------------------------------------------------------------
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/