Hollis Blanchard wrote: > On Thu, 2007-10-25 at 17:48 +0200, Izik Eidus wrote: > >> On Thu, 2007-10-25 at 17:48 +0200, Carsten Otte wrote: >> >>> This patch splits kvm_vm_ioctl into archtecture independent parts, and >>> x86 specific parts which go to kvm_arch_vcpu_ioctl in x86.c. >>> >>> Common ioctls for all architectures are: >>> KVM_CREATE_VCPU, KVM_GET_DIRTY_LOG, KVM_SET_USER_MEMORY_REGION >>> >>> KVM_SET_USER_MEMORY_REGION is actually implemented in x86.c now, because >>> the code behind looks arch specific to me. >>> > > Reviewed-by: Hollis Blanchard <[EMAIL PROTECTED]> > > >> i think it is much better just to split the parts that allocate the >> rmap, and the part that set the number of shadow pages mmu, >> beside this parts it seems to me that it isnt arch specific. >> > > Carsten omitted the explanation about memslots he had in his original > patch. To quote that here: > >> We've got a total different >> address layout on s390: we cannot support multiple slots, and a user >> memory range always equals the guest physical memory [guest_phys + vm >> specific offset = host user address]. We don't have nor need dedicated >> vmas for the guest memory, we just use what the memory managment has >> in stock. This is true, because we reuse the page table for user and >> guest mode. >> > > Given that explanation, and that kvm_vm_ioctl_set_memory_region() is > entirely about memslots, I'm inclined to agree with this code movement. > > 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? ------------------------------------------------------------------------- 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
