All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Linton <jeremy.linton@arm.com>
To: Oliver Upton <oliver.upton@linux.dev>, Marc Zyngier <maz@kernel.org>
Cc: James Morse <james.morse@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	kvmarm@lists.linux.dev, Zenghui Yu <yuzenghui@huawei.com>,
	linux-arm-kernel@lists.infradead.org,
	Sean Christopherson <seanjc@google.com>
Subject: Re: [PATCH v2 0/4] KVM: arm64: Fix vcpu->mutex v. kvm->lock inversion
Date: Thu, 23 Mar 2023 17:48:29 -0500	[thread overview]
Message-ID: <b5afbc8d-e2cd-ce13-4089-e18339c14562@arm.com> (raw)
In-Reply-To: <20230316211412.2651555-1-oliver.upton@linux.dev>

Hi,

On 3/16/23 16:14, Oliver Upton wrote:
> As it so happens, lock ordering in KVM/arm64 is completely backwards.
> There's a significant amount of VM-wide state that needs to be accessed
> from the context of a vCPU. Until now, this was accomplished by
> acquiring the kvm->lock, but that cannot be nested within vcpu->mutex.
> 
> This series fixes the issue with some fine-grained locking for MP state
> and a new, dedicated mutex that can nest with both kvm->lock and
> vcpu->mutex.
> 
> Tested with kvmtool and QEMU scaled up to 64 vCPUs on a kernel w/
> lockdep enabled. Applies to kvmarm/next.

This set makes the reported lockdep error go away for me, it also 
appears to complete some basic kernel/kvm testing without error as well. So,

Tested-by: Jeremy Linton <jeremy.linton@arm.com>


Thanks,

> 
> v1: http://lore.kernel.org/kvmarm/20230308083947.3760066-1-oliver.upton@linux.dev
> 
> v1 -> v2:
>   - Add a dedicated lock for serializing writes to MP state
>   - Inform lockdep of acquisition order at time of VM/vCPU creation
>   - Plug a race with GIC creation (Sean)
>   - Use the config_lock in GIC ITS flows as well. There is now a single
>     (valid) use of kvm->lock when enabling MTE.
> 
> Oliver Upton (4):
>    KVM: arm64: Avoid vcpu->mutex v. kvm->lock inversion in CPU_ON
>    KVM: arm64: Avoid lock inversion when setting the VM register width
>    KVM: arm64: Use config_lock to protect data ordered against KVM_RUN
>    KVM: arm64: Use config_lock to protect vgic state
> 
>   arch/arm64/include/asm/kvm_host.h     |  4 ++
>   arch/arm64/kvm/arm.c                  | 45 +++++++++++++++++++----
>   arch/arm64/kvm/guest.c                |  2 +
>   arch/arm64/kvm/hypercalls.c           |  4 +-
>   arch/arm64/kvm/pmu-emul.c             | 23 +++---------
>   arch/arm64/kvm/psci.c                 | 19 +++++-----
>   arch/arm64/kvm/reset.c                | 16 ++++----
>   arch/arm64/kvm/vgic/vgic-debug.c      |  8 ++--
>   arch/arm64/kvm/vgic/vgic-init.c       | 33 ++++++++++-------
>   arch/arm64/kvm/vgic/vgic-its.c        | 29 ++++++---------
>   arch/arm64/kvm/vgic/vgic-kvm-device.c | 53 ++++++++++++---------------
>   arch/arm64/kvm/vgic/vgic-mmio-v3.c    |  4 +-
>   arch/arm64/kvm/vgic/vgic-mmio.c       | 12 +++---
>   arch/arm64/kvm/vgic/vgic-v4.c         | 11 +++---
>   arch/arm64/kvm/vgic/vgic.c            |  2 +-
>   15 files changed, 146 insertions(+), 119 deletions(-)
> 


WARNING: multiple messages have this Message-ID (diff)
From: Jeremy Linton <jeremy.linton@arm.com>
To: Oliver Upton <oliver.upton@linux.dev>, Marc Zyngier <maz@kernel.org>
Cc: James Morse <james.morse@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	kvmarm@lists.linux.dev, Zenghui Yu <yuzenghui@huawei.com>,
	linux-arm-kernel@lists.infradead.org,
	Sean Christopherson <seanjc@google.com>
Subject: Re: [PATCH v2 0/4] KVM: arm64: Fix vcpu->mutex v. kvm->lock inversion
Date: Thu, 23 Mar 2023 17:48:29 -0500	[thread overview]
Message-ID: <b5afbc8d-e2cd-ce13-4089-e18339c14562@arm.com> (raw)
In-Reply-To: <20230316211412.2651555-1-oliver.upton@linux.dev>

Hi,

On 3/16/23 16:14, Oliver Upton wrote:
> As it so happens, lock ordering in KVM/arm64 is completely backwards.
> There's a significant amount of VM-wide state that needs to be accessed
> from the context of a vCPU. Until now, this was accomplished by
> acquiring the kvm->lock, but that cannot be nested within vcpu->mutex.
> 
> This series fixes the issue with some fine-grained locking for MP state
> and a new, dedicated mutex that can nest with both kvm->lock and
> vcpu->mutex.
> 
> Tested with kvmtool and QEMU scaled up to 64 vCPUs on a kernel w/
> lockdep enabled. Applies to kvmarm/next.

This set makes the reported lockdep error go away for me, it also 
appears to complete some basic kernel/kvm testing without error as well. So,

Tested-by: Jeremy Linton <jeremy.linton@arm.com>


Thanks,

> 
> v1: http://lore.kernel.org/kvmarm/20230308083947.3760066-1-oliver.upton@linux.dev
> 
> v1 -> v2:
>   - Add a dedicated lock for serializing writes to MP state
>   - Inform lockdep of acquisition order at time of VM/vCPU creation
>   - Plug a race with GIC creation (Sean)
>   - Use the config_lock in GIC ITS flows as well. There is now a single
>     (valid) use of kvm->lock when enabling MTE.
> 
> Oliver Upton (4):
>    KVM: arm64: Avoid vcpu->mutex v. kvm->lock inversion in CPU_ON
>    KVM: arm64: Avoid lock inversion when setting the VM register width
>    KVM: arm64: Use config_lock to protect data ordered against KVM_RUN
>    KVM: arm64: Use config_lock to protect vgic state
> 
>   arch/arm64/include/asm/kvm_host.h     |  4 ++
>   arch/arm64/kvm/arm.c                  | 45 +++++++++++++++++++----
>   arch/arm64/kvm/guest.c                |  2 +
>   arch/arm64/kvm/hypercalls.c           |  4 +-
>   arch/arm64/kvm/pmu-emul.c             | 23 +++---------
>   arch/arm64/kvm/psci.c                 | 19 +++++-----
>   arch/arm64/kvm/reset.c                | 16 ++++----
>   arch/arm64/kvm/vgic/vgic-debug.c      |  8 ++--
>   arch/arm64/kvm/vgic/vgic-init.c       | 33 ++++++++++-------
>   arch/arm64/kvm/vgic/vgic-its.c        | 29 ++++++---------
>   arch/arm64/kvm/vgic/vgic-kvm-device.c | 53 ++++++++++++---------------
>   arch/arm64/kvm/vgic/vgic-mmio-v3.c    |  4 +-
>   arch/arm64/kvm/vgic/vgic-mmio.c       | 12 +++---
>   arch/arm64/kvm/vgic/vgic-v4.c         | 11 +++---
>   arch/arm64/kvm/vgic/vgic.c            |  2 +-
>   15 files changed, 146 insertions(+), 119 deletions(-)
> 


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

  parent reply	other threads:[~2023-03-23 22:48 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-16 21:14 [PATCH v2 0/4] KVM: arm64: Fix vcpu->mutex v. kvm->lock inversion Oliver Upton
2023-03-16 21:14 ` Oliver Upton
2023-03-16 21:14 ` [PATCH v2 1/4] KVM: arm64: Avoid vcpu->mutex v. kvm->lock inversion in CPU_ON Oliver Upton
2023-03-16 21:14   ` Oliver Upton
2023-03-22 12:02   ` Marc Zyngier
2023-03-22 12:02     ` Marc Zyngier
2023-03-23 19:47     ` Oliver Upton
2023-03-23 19:47       ` Oliver Upton
2023-03-16 21:14 ` [PATCH v2 2/4] KVM: arm64: Avoid lock inversion when setting the VM register width Oliver Upton
2023-03-16 21:14   ` Oliver Upton
2023-03-22 12:02   ` Marc Zyngier
2023-03-22 12:02     ` Marc Zyngier
2023-03-23 19:20     ` Oliver Upton
2023-03-23 19:20       ` Oliver Upton
2023-03-23 19:43       ` Marc Zyngier
2023-03-23 19:43         ` Marc Zyngier
2023-03-23 19:49         ` Oliver Upton
2023-03-23 19:49           ` Oliver Upton
2023-03-23 20:09   ` Jeremy Linton
2023-03-23 20:09     ` Jeremy Linton
2023-03-23 20:45     ` Oliver Upton
2023-03-23 20:45       ` Oliver Upton
2023-03-23 22:45       ` Jeremy Linton
2023-03-23 22:45         ` Jeremy Linton
2023-03-16 21:14 ` [PATCH v2 3/4] KVM: arm64: Use config_lock to protect data ordered against KVM_RUN Oliver Upton
2023-03-16 21:14   ` Oliver Upton
2023-03-16 21:14 ` [PATCH v2 4/4] KVM: arm64: Use config_lock to protect vgic state Oliver Upton
2023-03-16 21:14   ` Oliver Upton
2023-03-22 12:02   ` Marc Zyngier
2023-03-22 12:02     ` Marc Zyngier
2023-03-23 19:18     ` Oliver Upton
2023-03-23 19:18       ` Oliver Upton
2023-03-23 22:48 ` Jeremy Linton [this message]
2023-03-23 22:48   ` [PATCH v2 0/4] KVM: arm64: Fix vcpu->mutex v. kvm->lock inversion Jeremy Linton

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=b5afbc8d-e2cd-ce13-4089-e18339c14562@arm.com \
    --to=jeremy.linton@arm.com \
    --cc=james.morse@arm.com \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=maz@kernel.org \
    --cc=oliver.upton@linux.dev \
    --cc=seanjc@google.com \
    --cc=suzuki.poulose@arm.com \
    --cc=yuzenghui@huawei.com \
    /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.