diff mbox

[2/3] KVM: use separate generations for each address space

Message ID 20170215220048.3423-3-pbonzini@redhat.com (mailing list archive)
State New, archived
Headers show

Commit Message

Paolo Bonzini Feb. 15, 2017, 10 p.m. UTC
This will make it easier to support multiple address spaces in
kvm_gfn_to_hva_cache_init.  Instead of having to check the address
space id, we can keep on checking just the generation number.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
 virt/kvm/kvm_main.c | 24 ++++++++++++++++--------
 1 file changed, 16 insertions(+), 8 deletions(-)

Comments

Radim Krčmář Feb. 16, 2017, 5:04 p.m. UTC | #1
2017-02-15 23:00+0100, Paolo Bonzini:
> This will make it easier to support multiple address spaces in
> kvm_gfn_to_hva_cache_init.  Instead of having to check the address
> space id, we can keep on checking just the generation number.
> 
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---

Reviewed-by: Radim Krčmař <rkrcmar@redhat.com>

>  virt/kvm/kvm_main.c | 24 ++++++++++++++++--------
>  1 file changed, 16 insertions(+), 8 deletions(-)
> 
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index e21bac7ed5d3..a83c186cefc1 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -506,11 +506,6 @@ static struct kvm_memslots *kvm_alloc_memslots(void)
>  	if (!slots)
>  		return NULL;
>  
> -	/*
> -	 * Init kvm generation close to the maximum to easily test the
> -	 * code of handling generation number wrap-around.
> -	 */
> -	slots->generation = -150;
>  	for (i = 0; i < KVM_MEM_SLOTS_NUM; i++)
>  		slots->id_to_index[i] = slots->memslots[i].id = i;
>  
> @@ -641,9 +636,16 @@ static struct kvm *kvm_create_vm(unsigned long type)
>  
>  	r = -ENOMEM;
>  	for (i = 0; i < KVM_ADDRESS_SPACE_NUM; i++) {
> -		kvm->memslots[i] = kvm_alloc_memslots();
> -		if (!kvm->memslots[i])
> +		struct kvm_memslots *slots = kvm_alloc_memslots();
> +		if (!slots)
>  			goto out_err_no_srcu;
> +		/*
> +		 * Generations must be different for each address space.
> +		 * Init kvm generation close to the maximum to easily test the
> +		 * code of handling generation number wrap-around.
> +		 */
> +		slots->generation = i * 2 - 150;
> +		rcu_assign_pointer(kvm->memslots[i], slots);
>  	}
>  
>  	if (init_srcu_struct(&kvm->srcu))
> @@ -870,8 +872,14 @@ static struct kvm_memslots *install_new_memslots(struct kvm *kvm,
>  	 * Increment the new memslot generation a second time. This prevents
>  	 * vm exits that race with memslot updates from caching a memslot
>  	 * generation that will (potentially) be valid forever.
> +	 *
> +	 * Generations must be unique even across address spaces.  We do not need
> +	 * a global counter for that, instead the generation space is evenly split
> +	 * across address spaces.  For example, with two address spaces, address
> +	 * space 0 will use generations 0, 4, 8, ... while * address space 1 will
> +	 * use generations 2, 6, 10, 14, ...
>  	 */
> -	slots->generation++;
> +	slots->generation += KVM_ADDRESS_SPACE_NUM * 2 - 1;
>  
>  	kvm_arch_memslots_updated(kvm, slots);
>  
> -- 
> 1.8.3.1
> 
>
Bandan Das Feb. 17, 2017, 12:29 a.m. UTC | #2
Paolo Bonzini <pbonzini@redhat.com> writes:

> This will make it easier to support multiple address spaces in
> kvm_gfn_to_hva_cache_init.  Instead of having to check the address
> space id, we can keep on checking just the generation number.
>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
>  virt/kvm/kvm_main.c | 24 ++++++++++++++++--------
>  1 file changed, 16 insertions(+), 8 deletions(-)
>
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index e21bac7ed5d3..a83c186cefc1 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -506,11 +506,6 @@ static struct kvm_memslots *kvm_alloc_memslots(void)
>  	if (!slots)
>  		return NULL;
>  
> -	/*
> -	 * Init kvm generation close to the maximum to easily test the
> -	 * code of handling generation number wrap-around.
> -	 */
> -	slots->generation = -150;
>  	for (i = 0; i < KVM_MEM_SLOTS_NUM; i++)
>  		slots->id_to_index[i] = slots->memslots[i].id = i;
>  
> @@ -641,9 +636,16 @@ static struct kvm *kvm_create_vm(unsigned long type)
>  
>  	r = -ENOMEM;
>  	for (i = 0; i < KVM_ADDRESS_SPACE_NUM; i++) {
> -		kvm->memslots[i] = kvm_alloc_memslots();
> -		if (!kvm->memslots[i])
> +		struct kvm_memslots *slots = kvm_alloc_memslots();
> +		if (!slots)
>  			goto out_err_no_srcu;
> +		/*
> +		 * Generations must be different for each address space.
> +		 * Init kvm generation close to the maximum to easily test the
> +		 * code of handling generation number wrap-around.
> +		 */
> +		slots->generation = i * 2 - 150;
> +		rcu_assign_pointer(kvm->memslots[i], slots);
>  	}

I can't seem to understand why rcu_assign_pointer wasn't used before.
kvm->memslots[i] was a rcu protected pointer even before this change,
right ?

>  	if (init_srcu_struct(&kvm->srcu))
> @@ -870,8 +872,14 @@ static struct kvm_memslots *install_new_memslots(struct kvm *kvm,
>  	 * Increment the new memslot generation a second time. This prevents
>  	 * vm exits that race with memslot updates from caching a memslot
>  	 * generation that will (potentially) be valid forever.
> +	 *
> +	 * Generations must be unique even across address spaces.  We do not need
> +	 * a global counter for that, instead the generation space is evenly split
> +	 * across address spaces.  For example, with two address spaces, address
> +	 * space 0 will use generations 0, 4, 8, ... while * address space 1 will
> +	 * use generations 2, 6, 10, 14, ...
>  	 */
> -	slots->generation++;
> +	slots->generation += KVM_ADDRESS_SPACE_NUM * 2 - 1;
>  
>  	kvm_arch_memslots_updated(kvm, slots);
Paolo Bonzini Feb. 17, 2017, 8:28 a.m. UTC | #3
> > +		/*
> > +		 * Generations must be different for each address space.
> > +		 * Init kvm generation close to the maximum to easily test the
> > +		 * code of handling generation number wrap-around.
> > +		 */
> > +		slots->generation = i * 2 - 150;
> > +		rcu_assign_pointer(kvm->memslots[i], slots);
> >  	}
> 
> I can't seem to understand why rcu_assign_pointer wasn't used before.
> kvm->memslots[i] was a rcu protected pointer even before this change,
> right ?

Actually, a better match is RCU_INIT_POINTER.  Here there is no concurrent
reader because we're just initializing the struct kvm.  There is something
else providing synchronization between this writer and the "first" RCU
read-side.  It could be signaling a condition variable, creating a thread,
or releasing a mutex; all three of them have release semantics, which
means they imply a smp_wmb just like rcu_assign_pointer does.

Paolo


> >  	if (init_srcu_struct(&kvm->srcu))
> > @@ -870,8 +872,14 @@ static struct kvm_memslots
> > *install_new_memslots(struct kvm *kvm,
> >  	 * Increment the new memslot generation a second time. This prevents
> >  	 * vm exits that race with memslot updates from caching a memslot
> >  	 * generation that will (potentially) be valid forever.
> > +	 *
> > +	 * Generations must be unique even across address spaces.  We do not need
> > +	 * a global counter for that, instead the generation space is evenly
> > split
> > +	 * across address spaces.  For example, with two address spaces, address
> > +	 * space 0 will use generations 0, 4, 8, ... while * address space 1 will
> > +	 * use generations 2, 6, 10, 14, ...
> >  	 */
> > -	slots->generation++;
> > +	slots->generation += KVM_ADDRESS_SPACE_NUM * 2 - 1;
> >  
> >  	kvm_arch_memslots_updated(kvm, slots);
>
diff mbox

Patch

diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index e21bac7ed5d3..a83c186cefc1 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -506,11 +506,6 @@  static struct kvm_memslots *kvm_alloc_memslots(void)
 	if (!slots)
 		return NULL;
 
-	/*
-	 * Init kvm generation close to the maximum to easily test the
-	 * code of handling generation number wrap-around.
-	 */
-	slots->generation = -150;
 	for (i = 0; i < KVM_MEM_SLOTS_NUM; i++)
 		slots->id_to_index[i] = slots->memslots[i].id = i;
 
@@ -641,9 +636,16 @@  static struct kvm *kvm_create_vm(unsigned long type)
 
 	r = -ENOMEM;
 	for (i = 0; i < KVM_ADDRESS_SPACE_NUM; i++) {
-		kvm->memslots[i] = kvm_alloc_memslots();
-		if (!kvm->memslots[i])
+		struct kvm_memslots *slots = kvm_alloc_memslots();
+		if (!slots)
 			goto out_err_no_srcu;
+		/*
+		 * Generations must be different for each address space.
+		 * Init kvm generation close to the maximum to easily test the
+		 * code of handling generation number wrap-around.
+		 */
+		slots->generation = i * 2 - 150;
+		rcu_assign_pointer(kvm->memslots[i], slots);
 	}
 
 	if (init_srcu_struct(&kvm->srcu))
@@ -870,8 +872,14 @@  static struct kvm_memslots *install_new_memslots(struct kvm *kvm,
 	 * Increment the new memslot generation a second time. This prevents
 	 * vm exits that race with memslot updates from caching a memslot
 	 * generation that will (potentially) be valid forever.
+	 *
+	 * Generations must be unique even across address spaces.  We do not need
+	 * a global counter for that, instead the generation space is evenly split
+	 * across address spaces.  For example, with two address spaces, address
+	 * space 0 will use generations 0, 4, 8, ... while * address space 1 will
+	 * use generations 2, 6, 10, 14, ...
 	 */
-	slots->generation++;
+	slots->generation += KVM_ADDRESS_SPACE_NUM * 2 - 1;
 
 	kvm_arch_memslots_updated(kvm, slots);