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@lists.sourceforge.net > 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/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
