Jan, Thanks for taking a look at that for me. It still looks like it leaks to me. Could you point me to the actual free? In kvm_arch_destroy_vm, it calls put_page on apic_access_page and ept_identity_pagetable, but that doesn't actually free the memory. It unpins it from the kernel, but doesn't free them. There's also the tss_addr pages which are not referenced at all in kvm_arch_destroy_vm. I also wrote a simple program to demonstrate the leak. This program creates and destroys VMs with a single CPU and a TSS addr. On Intel platforms this program consumes memory without bound (albeit slowly). Would you mind taking a look? thanks, Andy #include <asm/kvm.h> #include <fcntl.h> #include <linux/kvm.h> #include <sys/ioctl.h> int main() { int kvm_fd = open("/dev/kvm", O_RDWR); if (kvm_fd < 0) printf("Error opening /dev/kvm\n"); int count = 0; while (1) { int vm_fd = ioctl(kvm_fd, KVM_CREATE_VM, 0); if (vm_fd < 0) printf("Error creating vm\n"); int vcpu_id = ioctl(vm_fd, KVM_CREATE_VCPU, 1); if (vcpu_id < 0) printf("Error creating vcpu\n"); ioctl(vm_fd, KVM_SET_TSS_ADDR, 0xffc00000); close(vcpu_id); close(vm_fd); printf("Iteration %d\n", ++count); } } On Sat, Dec 8, 2012 at 12:31 AM, Jan Kiszka <jan.kiszka@xxxxxx> wrote: > On 2012-12-07 20:51, Andrew Honig wrote: >> I've noticed a memory leak that occurs in vmx.c. >> >> In alloc_apic_access_page, it calls __kvm_set_memory_region(kvm, >> &kvm_userspace_mem, 0). __kvm_set_memory_region calls >> kvm_arch_prepare_memory_region, which because the user_alloc parameter >> is 0 will allocate memory for the page with vm_mmap. >> >> This memory never gets freed. In kvm_arch_destroy_vm it calls >> put_page(kvm->arch.apic_access_page), but that only unpins the memory >> (necessary due to an earlier call to gfn_to_page), it never actually >> frees the memory. The memory is allocated in the current process >> context so it's cleaned up when the process exits, but if a process >> creates and destroys multiple VMs then this leak starts to become a >> problem. >> >> Similar leaks occur in alloc_identity_pagetable and vmx_set_tss_addr >> for a total of 5 pages of memory leak for a VM. The vmx_set_tss_addr >> actually leaks each time vmx_set_tss_addr is called so this could also >> become a problem if a program had occasion to set the tss addr several >> times. > > Both pages are per-vm. Therefore they are freed in kvm_arch_destroy_vm. > But I have to admit that I dug a while as well to find this out. > > Jan > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html