All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Raghavendra Rao Ananta <rananta@google.com>
Cc: kvm@vger.kernel.org, Will Deacon <will@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Peter Shier <pshier@google.com>,
	linux-kernel@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
	kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH v2 03/11] KVM: Introduce kvm_vm_has_run_once
Date: Mon, 22 Nov 2021 16:31:37 +0000	[thread overview]
Message-ID: <87y25gcfti.wl-maz@kernel.org> (raw)
In-Reply-To: <20211113012234.1443009-4-rananta@google.com>

On Sat, 13 Nov 2021 01:22:26 +0000,
Raghavendra Rao Ananta <rananta@google.com> wrote:
> 
> The upcoming patches need a way to detect if the VM, as
> a whole, has started. Hence, unionize kvm_vcpu_has_run_once()
> of all the vcpus of the VM and build kvm_vm_has_run_once()
> to achieve the functionality.
> 
> No functional change intended.
> 
> Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> ---
>  include/linux/kvm_host.h |  2 ++
>  virt/kvm/kvm_main.c      | 17 +++++++++++++++++
>  2 files changed, 19 insertions(+)
> 
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index b373929c71eb..102e00c0e21c 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -1854,4 +1854,6 @@ static inline bool kvm_vcpu_has_run_once(struct kvm_vcpu *vcpu)
>  	return vcpu->has_run_once;
>  }
>  
> +bool kvm_vm_has_run_once(struct kvm *kvm);
> +
>  #endif
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 1ec8a8e959b2..3d8d96e8f61d 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -4339,6 +4339,23 @@ static int kvm_vm_ioctl_get_stats_fd(struct kvm *kvm)
>  	return fd;
>  }
>  
> +bool kvm_vm_has_run_once(struct kvm *kvm)
> +{
> +	int i, ret = false;
> +	struct kvm_vcpu *vcpu;
> +
> +	mutex_lock(&kvm->lock);
> +
> +	kvm_for_each_vcpu(i, vcpu, kvm) {
> +		ret = kvm_vcpu_has_run_once(vcpu);
> +		if (ret)
> +			break;
> +	}
> +
> +	mutex_unlock(&kvm->lock);
> +	return ret;
> +}

This is horribly racy. Nothing prevents a vcpu from running behind
your back. If you want any sort of guarantee, look at what we do in
kvm_vgic_create(). Alexandru has patches that extract it to make it
generally available (at least for arm64).

	M.

-- 
Without deviation from the norm, progress is not possible.
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Raghavendra Rao Ananta <rananta@google.com>
Cc: Andrew Jones <drjones@redhat.com>,
	James Morse <james.morse@arm.com>,
	Alexandru Elisei <alexandru.elisei@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>, Peter Shier <pshier@google.com>,
	Ricardo Koller <ricarkol@google.com>,
	Oliver Upton <oupton@google.com>,
	Reiji Watanabe <reijiw@google.com>,
	Jing Zhang <jingzhangos@google.com>,
	linux-arm-kernel@lists.infradead.org,
	kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org,
	kvm@vger.kernel.org
Subject: Re: [RFC PATCH v2 03/11] KVM: Introduce kvm_vm_has_run_once
Date: Mon, 22 Nov 2021 16:31:37 +0000	[thread overview]
Message-ID: <87y25gcfti.wl-maz@kernel.org> (raw)
In-Reply-To: <20211113012234.1443009-4-rananta@google.com>

On Sat, 13 Nov 2021 01:22:26 +0000,
Raghavendra Rao Ananta <rananta@google.com> wrote:
> 
> The upcoming patches need a way to detect if the VM, as
> a whole, has started. Hence, unionize kvm_vcpu_has_run_once()
> of all the vcpus of the VM and build kvm_vm_has_run_once()
> to achieve the functionality.
> 
> No functional change intended.
> 
> Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> ---
>  include/linux/kvm_host.h |  2 ++
>  virt/kvm/kvm_main.c      | 17 +++++++++++++++++
>  2 files changed, 19 insertions(+)
> 
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index b373929c71eb..102e00c0e21c 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -1854,4 +1854,6 @@ static inline bool kvm_vcpu_has_run_once(struct kvm_vcpu *vcpu)
>  	return vcpu->has_run_once;
>  }
>  
> +bool kvm_vm_has_run_once(struct kvm *kvm);
> +
>  #endif
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 1ec8a8e959b2..3d8d96e8f61d 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -4339,6 +4339,23 @@ static int kvm_vm_ioctl_get_stats_fd(struct kvm *kvm)
>  	return fd;
>  }
>  
> +bool kvm_vm_has_run_once(struct kvm *kvm)
> +{
> +	int i, ret = false;
> +	struct kvm_vcpu *vcpu;
> +
> +	mutex_lock(&kvm->lock);
> +
> +	kvm_for_each_vcpu(i, vcpu, kvm) {
> +		ret = kvm_vcpu_has_run_once(vcpu);
> +		if (ret)
> +			break;
> +	}
> +
> +	mutex_unlock(&kvm->lock);
> +	return ret;
> +}

This is horribly racy. Nothing prevents a vcpu from running behind
your back. If you want any sort of guarantee, look at what we do in
kvm_vgic_create(). Alexandru has patches that extract it to make it
generally available (at least for arm64).

	M.

-- 
Without deviation from the norm, progress is not possible.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Raghavendra Rao Ananta <rananta@google.com>
Cc: Andrew Jones <drjones@redhat.com>,
	James Morse <james.morse@arm.com>,
	Alexandru Elisei <alexandru.elisei@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>, Peter Shier <pshier@google.com>,
	Ricardo Koller <ricarkol@google.com>,
	Oliver Upton <oupton@google.com>,
	Reiji Watanabe <reijiw@google.com>,
	Jing Zhang <jingzhangos@google.com>,
	linux-arm-kernel@lists.infradead.org,
	kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org,
	kvm@vger.kernel.org
Subject: Re: [RFC PATCH v2 03/11] KVM: Introduce kvm_vm_has_run_once
Date: Mon, 22 Nov 2021 16:31:37 +0000	[thread overview]
Message-ID: <87y25gcfti.wl-maz@kernel.org> (raw)
In-Reply-To: <20211113012234.1443009-4-rananta@google.com>

On Sat, 13 Nov 2021 01:22:26 +0000,
Raghavendra Rao Ananta <rananta@google.com> wrote:
> 
> The upcoming patches need a way to detect if the VM, as
> a whole, has started. Hence, unionize kvm_vcpu_has_run_once()
> of all the vcpus of the VM and build kvm_vm_has_run_once()
> to achieve the functionality.
> 
> No functional change intended.
> 
> Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> ---
>  include/linux/kvm_host.h |  2 ++
>  virt/kvm/kvm_main.c      | 17 +++++++++++++++++
>  2 files changed, 19 insertions(+)
> 
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index b373929c71eb..102e00c0e21c 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -1854,4 +1854,6 @@ static inline bool kvm_vcpu_has_run_once(struct kvm_vcpu *vcpu)
>  	return vcpu->has_run_once;
>  }
>  
> +bool kvm_vm_has_run_once(struct kvm *kvm);
> +
>  #endif
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 1ec8a8e959b2..3d8d96e8f61d 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -4339,6 +4339,23 @@ static int kvm_vm_ioctl_get_stats_fd(struct kvm *kvm)
>  	return fd;
>  }
>  
> +bool kvm_vm_has_run_once(struct kvm *kvm)
> +{
> +	int i, ret = false;
> +	struct kvm_vcpu *vcpu;
> +
> +	mutex_lock(&kvm->lock);
> +
> +	kvm_for_each_vcpu(i, vcpu, kvm) {
> +		ret = kvm_vcpu_has_run_once(vcpu);
> +		if (ret)
> +			break;
> +	}
> +
> +	mutex_unlock(&kvm->lock);
> +	return ret;
> +}

This is horribly racy. Nothing prevents a vcpu from running behind
your back. If you want any sort of guarantee, look at what we do in
kvm_vgic_create(). Alexandru has patches that extract it to make it
generally available (at least for arm64).

	M.

-- 
Without deviation from the norm, progress is not possible.

  reply	other threads:[~2021-11-22 16:31 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-13  1:22 [RFC PATCH v2 00/11] KVM: arm64: Add support for hypercall services selection Raghavendra Rao Ananta
2021-11-13  1:22 ` Raghavendra Rao Ananta
2021-11-13  1:22 ` Raghavendra Rao Ananta
2021-11-13  1:22 ` [RFC PATCH v2 01/11] KVM: arm64: Factor out firmware register handling from psci.c Raghavendra Rao Ananta
2021-11-13  1:22   ` Raghavendra Rao Ananta
2021-11-13  1:22   ` Raghavendra Rao Ananta
2021-11-27 13:16   ` Andrew Jones
2021-11-27 13:16     ` Andrew Jones
2021-11-27 13:16     ` Andrew Jones
2021-11-30  0:57     ` Raghavendra Rao Ananta
2021-11-30  0:57       ` Raghavendra Rao Ananta
2021-11-30  0:57       ` Raghavendra Rao Ananta
2021-11-13  1:22 ` [RFC PATCH v2 02/11] KVM: Introduce kvm_vcpu_has_run_once Raghavendra Rao Ananta
2021-11-13  1:22   ` Raghavendra Rao Ananta
2021-11-13  1:22   ` Raghavendra Rao Ananta
2021-11-22 16:27   ` Marc Zyngier
2021-11-22 16:27     ` Marc Zyngier
2021-11-22 16:27     ` Marc Zyngier
2021-11-23 18:31     ` Raghavendra Rao Ananta
2021-11-23 18:31       ` Raghavendra Rao Ananta
2021-11-23 18:31       ` Raghavendra Rao Ananta
2021-11-13  1:22 ` [RFC PATCH v2 03/11] KVM: Introduce kvm_vm_has_run_once Raghavendra Rao Ananta
2021-11-13  1:22   ` Raghavendra Rao Ananta
2021-11-13  1:22   ` Raghavendra Rao Ananta
2021-11-22 16:31   ` Marc Zyngier [this message]
2021-11-22 16:31     ` Marc Zyngier
2021-11-22 16:31     ` Marc Zyngier
2021-11-23 18:48     ` Raghavendra Rao Ananta
2021-11-23 18:48       ` Raghavendra Rao Ananta
2021-11-23 18:48       ` Raghavendra Rao Ananta
2021-11-13  1:22 ` [RFC PATCH v2 04/11] KVM: arm64: Setup a framework for hypercall bitmap firmware registers Raghavendra Rao Ananta
2021-11-13  1:22   ` Raghavendra Rao Ananta
2021-11-13  1:22   ` Raghavendra Rao Ananta
2021-11-22 17:23   ` Marc Zyngier
2021-11-22 17:23     ` Marc Zyngier
2021-11-22 17:23     ` Marc Zyngier
2021-11-23 18:34     ` Raghavendra Rao Ananta
2021-11-23 18:34       ` Raghavendra Rao Ananta
2021-11-23 18:34       ` Raghavendra Rao Ananta
2021-11-27 17:27       ` Andrew Jones
2021-11-27 17:27         ` Andrew Jones
2021-11-27 17:27         ` Andrew Jones
2021-11-30  0:56         ` Raghavendra Rao Ananta
2021-11-30  0:56           ` Raghavendra Rao Ananta
2021-11-30  0:56           ` Raghavendra Rao Ananta
2021-11-30 10:19           ` Andrew Jones
2021-11-30 10:19             ` Andrew Jones
2021-11-30 10:19             ` Andrew Jones
2021-11-13  1:22 ` [RFC PATCH v2 05/11] KVM: arm64: Add standard hypervisor firmware register Raghavendra Rao Ananta
2021-11-13  1:22   ` Raghavendra Rao Ananta
2021-11-13  1:22   ` Raghavendra Rao Ananta
2021-11-13  1:22 ` [RFC PATCH v2 06/11] KVM: arm64: Add vendor " Raghavendra Rao Ananta
2021-11-13  1:22   ` Raghavendra Rao Ananta
2021-11-13  1:22   ` Raghavendra Rao Ananta
2021-11-13  1:22 ` [RFC PATCH v2 07/11] Docs: KVM: Add doc for the bitmap firmware registers Raghavendra Rao Ananta
2021-11-13  1:22   ` Raghavendra Rao Ananta
2021-11-13  1:22   ` Raghavendra Rao Ananta
2021-11-13  1:22 ` [RFC PATCH v2 08/11] Docs: KVM: Rename psci.rst to hypercalls.rst Raghavendra Rao Ananta
2021-11-13  1:22   ` Raghavendra Rao Ananta
2021-11-13  1:22   ` Raghavendra Rao Ananta
2021-11-13  1:22 ` [RFC PATCH v2 09/11] tools: Import ARM SMCCC definitions Raghavendra Rao Ananta
2021-11-13  1:22   ` Raghavendra Rao Ananta
2021-11-13  1:22   ` Raghavendra Rao Ananta
2021-11-13  1:22 ` [RFC PATCH v2 10/11] selftests: KVM: aarch64: Introduce hypercall ABI test Raghavendra Rao Ananta
2021-11-13  1:22   ` Raghavendra Rao Ananta
2021-11-13  1:22   ` Raghavendra Rao Ananta
2021-11-13  1:22 ` [RFC PATCH v2 11/11] selftests: KVM: aarch64: Add the bitmap firmware registers to get-reg-list Raghavendra Rao Ananta
2021-11-13  1:22   ` Raghavendra Rao Ananta
2021-11-13  1:22   ` Raghavendra Rao Ananta

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87y25gcfti.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=pshier@google.com \
    --cc=rananta@google.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.