Avi Kivity wrote:
> Izik Eidus wrote:
>> On Thu, 2007-10-18 at 12:18 +0200, Gerd Hoffmann wrote:
>> 
>>>>> I don't see how I can pass a pointer to
>>>>> kvm_create_userspace_memory() via kvm_create() without
>>>>> breaking the libkvm interface.  There is no flags field or
>>>>> similar which could be used to signal "vm_mem is a valid 
>>>>> pointer, please use that instead of mmap()'ing anonymous
>>>>> memory".
>>>>> 
>>>> There is no need to keep binary compat to libkvm as long as it
>>>> is linked statically.

>> anyone who use kvmctl, should not call kvm_create_userspace_memory 
>> directly, instead should call kvm_create()...

I'm talking about the kvm_create() interface, dammit.  Sure I can modify
kvm_create_userspace_memory() without breaking anyone as this isn't part
of the public (kvmctl.h) interface.  That doesn't buy us much though.
I'd have to pass the pointer to kvm_create() somehow so it can be passed
down to kvm_create_userspace_memory().  I can't without breaking the
public library interface though.

> Why not have an API for creating memory slots?  It allows much more 
> flexibility and is more in line with what qemu wants.

This *is* what the patch does.  It adds a function to add a
userspace-memory-backed memory slot: kvm_register_userspace_phys_mem().

That alone doesn't cut it though as there are some more constrains:

 * kvm_create() builds a standard memory layout, which I want be able
   to skip.
 * kvm_create() fails to create a vcpu in case no memory is available,
   which makes simple approach to just ask kvm_create() for 0 bytes
   physical memory for the guest unusable.

Thats why I went the route to additionally split the job kvm_create()
does into multiple, individually callable pieces.  So I can first create
the vm, then create my custom memory slots (instead of the standard
setup built by kvm_create_userspace_memory()), then create the vcpu.

cheers,
  Gerd

ps: patch attached again for reference.