Gerd Hoffmann wrote: > >>> 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. > >
Break it. It has just one user, our qemu, which is included in the same package. We will freeze the lib kvm ABI once we have merged our changes into upstream qemu. But that won't happen unless we get a sane interface for that library (the current interface is not acceptable). >> 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() should not be creating memory. > * 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. > kvm_create() should not be creating vcpus. > 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. > That's exactly what's needed. The patch looks good, except that I wouldn't export kvm_create_default_phys_mem(). Let qemu do the hard work instead. Once qemu switches to the new interface, we can remove kvm_create(). -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- 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
