Izik Eidus wrote: > ok i was thinking, > maybe we can rewrite the way kvm hold memory so more code would be shared, > lets say we throw away all the slots and arch depended stuff, and we let kvm > just hold the userspace allocated memory address, > > then we will will have to each arch "arch specific" functions that will > map the memory as it will need. > for example for x86 we will make gfn_to_page map on the fly how the > memory should look. > i think i will write patch to example this, but it might take me some time, > > anyway what do you think about this idea? I do strongly vote for it. This way, we'd have memory handling common over all architectures. For a sane end result of a real portably hypervisor, this is very preferable over "have every arch to its own thing". After reading your suggestion, I think memory allocation needs more engineering work to be done until we find a proper arch split then just move it to x86.c. Therefore, I'll modify the patch to leave memory handling in common for now. This way, the rest of the patch can be picked up for the time being.
so long, Carsten ------------------------------------------------------------------------- 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
