From mboxrd@z Thu Jan  1 00:00:00 1970
From: Avi Kivity <avi@redhat.com>
Subject: Re: [PATCH v4 04/10] ARM: KVM: Memory virtualization setup
Date: Tue, 09 Aug 2011 12:57:42 +0300
Message-ID: <4E410496.7030001@redhat.com>
References: <20110806103821.27198.41231.stgit@localhost6.localdomain6> <20110806103926.27198.11259.stgit@localhost6.localdomain6>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: kvm@vger.kernel.org, catalin.marinas@arm.com,
	tech@virtualopensystems.com, android-virt@lists.cs.columbia.edu
To: Christoffer Dall <cdall@cs.columbia.edu>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx1.redhat.com ([209.132.183.28]:16393 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751593Ab1HIJ6F (ORCPT <rfc822;kvm@vger.kernel.org>);
	Tue, 9 Aug 2011 05:58:05 -0400
In-Reply-To: <20110806103926.27198.11259.stgit@localhost6.localdomain6>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On 08/06/2011 01:39 PM, Christoffer Dall wrote:
> This commit introduces the framework for guest memory management
> through the use of 2nd stage translation. Each VM has a pointer
> to a level-1 tabled (the pgd field in struct kvm_arch) which is
> used for the 2nd stage translations. Entries are added when handling
> guest faults (later patch) and the table itself can be allocated and
> freed through the following functions implemented in
> arch/arm/kvm/arm_mmu.c:
>   - kvm_alloc_stage2_pgd(struct kvm *kvm);
>   - kvm_free_stage2_pgd(struct kvm *kvm);
>
> Further, each entry in TLBs and caches are tagged with a VMID
> identifier in addition to ASIDs. The VMIDs are managed using
> a bitmap and assigned when creating the VM in kvm_arch_init_vm()
> where the 2nd stage pgd is also allocated. The table is freed in
> kvm_arch_destroy_vm(). Both functions are called from the main
> KVM code.
>
>
> +/**
> + * kvm_arch_init_vm - initializes a VM data structure
> + * @kvm:	pointer to the KVM struct
> + */
>   int kvm_arch_init_vm(struct kvm *kvm)
>   {
> -	return 0;
> +	int ret = 0;
> +	phys_addr_t pgd_phys;
> +	unsigned long vmid;
> +	unsigned long start, end;
> +
> +
> +	mutex_lock(&kvm_vmids_mutex);
> +	vmid = find_first_zero_bit(kvm_vmids, VMID_SIZE);
> +	if (vmid>= VMID_SIZE) {
> +		mutex_unlock(&kvm_vmids_mutex);
> +		return -EBUSY;
> +	}
> +	__set_bit(vmid, kvm_vmids);

VMID_SIZE seems to be a bit low for comfort.  I guess it's fine for a 
start, but later on we'll have to recycle VMIDs, like we do for SVM ASIDs.

Is there not a risk of a user starting 255 tiny guests and denying other 
users the ability to use kvm?

> +	kvm->arch.vmid = vmid;
> +	mutex_unlock(&kvm_vmids_mutex);
> +
> +	ret = kvm_alloc_stage2_pgd(kvm);
> +	if (ret)
> +		goto out_fail_alloc;
> +
> +	pgd_phys = virt_to_phys(kvm->arch.pgd);
> +	kvm->arch.vttbr = pgd_phys&  ((1LLU<<  40) - 1)&  ~((2<<  VTTBR_X) - 1);
> +	kvm->arch.vttbr |= ((u64)vmid<<  48);
> +
> +	start = (unsigned long)kvm,
> +	end = start + sizeof(struct kvm);
> +	ret = create_hyp_mappings(kvm_hyp_pgd, start, end);
> +	if (ret)
> +		goto out_fail_hyp_mappings;
> +
> +	return ret;
> +out_fail_hyp_mappings:
> +	remove_hyp_mappings(kvm_hyp_pgd, start, end);
> +out_fail_alloc:
> +	clear_bit(vmid, kvm_vmids);
> +	return ret;
>   }
>

-- 
error compiling committee.c: too many arguments to function