Re: [kvm-ppc-devel] RFC/patch portability: split kvm_vm_ioctl v2

[Izik Eidus <izike-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

Izik Eidus wrote:
> Hollis Blanchard wrote:
>> On Fri, 2007-10-26 at 00:12 +0200, 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,
>>>     
>>
>> With that approach, how would you create a sparse (guest physical)
>> memory map in userspace? I guess you would need to use repeated
>> mmap(MAP_FIXED), and that's starting to look very brittle.
>>
>>  
btw, if you look at kvmctl, we already do it,
so it is good question if it better to leave this work to userspace 
(like it do now)
or do the mapping to userspace from the kernel to userspace (using the 
mmap syscall)

(i like the secoend option beacuse it would be easier to work with qemu 
like this)
> i would just allocate one single block of memory to kvm,
> and then i will use ioctls to tell kvm how to map it.
>
> after this the kernel will map back to the userspace the memory by the 
> mmap system call,
> this would be infact the same mechanisem that would be used by 
> gfn_to_page
> (infact the mmap syscall will call gfn_to_page)
>
> so accessing memory from the userspace would skip "holes"....
>


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