All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
To: <linux-arm-kernel@lists.infradead.org>,
	<kvmarm@lists.cs.columbia.edu>, <linux-kernel@vger.kernel.org>
Cc: <maz@kernel.org>, <will@kernel.org>, <catalin.marinas@arm.com>,
	<james.morse@arm.com>, <julien.thierry.kdev@gmail.com>,
	<suzuki.poulose@arm.com>, <jean-philippe@linaro.org>,
	<Alexandru.Elisei@arm.com>, <qperret@google.com>,
	<linuxarm@huawei.com>
Subject: [PATCH v3 0/4] kvm/arm: New VMID allocator based on asid
Date: Thu, 29 Jul 2021 11:40:05 +0100	[thread overview]
Message-ID: <20210729104009.382-1-shameerali.kolothum.thodi@huawei.com> (raw)

Hi,

Major changes since v2 (Based on Will's feedback)
  -Dropped adding a new static key and cpufeature for retrieving
   supported VMID bits. Instead, we now make use of the 
   kvm_arm_vmid_bits variable (patch #2).

  -Since we expect less frequent rollover in the case of VMIDs,
   the TLB invalidation is now broadcasted on rollover instead
   of keeping per CPU flush_pending info and issuing a local
   context flush.  

 -Clear active_vmids on vCPU schedule out to avoid unnecessarily
  reserving the VMID space(patch #3). 

 -I have kept the struct kvm_vmid as it is for now(instead of a
  typedef as suggested), as we may soon add another variable to
  it when we introduce Pinned KVM VMID support.

Sanity tested on HiSilicon D06 board.

Thanks,
Shameer


RFCv1 --> v2
   - Dropped "pinned VMID" support for now.
   - Dropped RFC tag.

History(from RFC v1):
-------------------

Please find the RFC series here,
https://lore.kernel.org/kvmarm/20210506165232.1969-1-shameerali.kolothum.thodi@huawei.com/

This is based on a suggestion from Will [0] to try out the asid
based kvm vmid solution as a separate VMID allocator instead of
the shared lib approach attempted in v4[1].

The idea is to compare both the approaches and see whether the
shared lib solution with callbacks make sense or not. 

Though we are not yet using the pinned vmids yet, patch #2 has
code for pinned vmid support. This is just to help the comparison.

Test Setup/Results
----------------
The measurement was made with maxcpus set to 8 and with the
number of VMID limited to 4-bit. The test involves running
concurrently 40 guests with 2 vCPUs. Each guest will then
execute hackbench 5 times before exiting.

The performance difference between the current algo and the
new one are(avg. of 10 runs):
    - 1.9% less entry/exit from the guest
    - 0.5% faster

This is more or less comparable to v4 numbers.

For the complete series, please see,
https://github.com/hisilicon/kernel-dev/tree/private-v5.12-rc7-vmid-2nd-rfc

and for the shared asid lib v4 solution,
https://github.com/hisilicon/kernel-dev/tree/private-v5.12-rc7-asid-v4

As you can see there are ofcourse code duplication with this
approach but may be it is more easy to maintain considering
the complexity involved.

Please take a look and let me know your feedback.

Thanks,
Shameer

Julien Grall (1):
  KVM: arm64: Align the VMID allocation with the arm64 ASID one

Shameer Kolothum (3):
  KVM: arm64: Introduce a new VMID allocator for KVM
  KVM: arm64: Make VMID bits accessible outside of allocator
  KVM: arm64: Clear active_vmids on vCPU schedule out

 arch/arm64/include/asm/kvm_host.h     |  10 +-
 arch/arm64/include/asm/kvm_mmu.h      |   4 +-
 arch/arm64/kernel/image-vars.h        |   3 +
 arch/arm64/kvm/Makefile               |   2 +-
 arch/arm64/kvm/arm.c                  | 122 +++++------------
 arch/arm64/kvm/hyp/nvhe/mem_protect.c |   3 +-
 arch/arm64/kvm/mmu.c                  |   1 -
 arch/arm64/kvm/vmid.c                 | 182 ++++++++++++++++++++++++++
 8 files changed, 228 insertions(+), 99 deletions(-)
 create mode 100644 arch/arm64/kvm/vmid.c

-- 
2.17.1


WARNING: multiple messages have this Message-ID (diff)
From: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
To: <linux-arm-kernel@lists.infradead.org>,
	<kvmarm@lists.cs.columbia.edu>, <linux-kernel@vger.kernel.org>
Cc: jean-philippe@linaro.org, maz@kernel.org, linuxarm@huawei.com,
	catalin.marinas@arm.com, will@kernel.org
Subject: [PATCH v3 0/4] kvm/arm: New VMID allocator based on asid
Date: Thu, 29 Jul 2021 11:40:05 +0100	[thread overview]
Message-ID: <20210729104009.382-1-shameerali.kolothum.thodi@huawei.com> (raw)

Hi,

Major changes since v2 (Based on Will's feedback)
  -Dropped adding a new static key and cpufeature for retrieving
   supported VMID bits. Instead, we now make use of the 
   kvm_arm_vmid_bits variable (patch #2).

  -Since we expect less frequent rollover in the case of VMIDs,
   the TLB invalidation is now broadcasted on rollover instead
   of keeping per CPU flush_pending info and issuing a local
   context flush.  

 -Clear active_vmids on vCPU schedule out to avoid unnecessarily
  reserving the VMID space(patch #3). 

 -I have kept the struct kvm_vmid as it is for now(instead of a
  typedef as suggested), as we may soon add another variable to
  it when we introduce Pinned KVM VMID support.

Sanity tested on HiSilicon D06 board.

Thanks,
Shameer


RFCv1 --> v2
   - Dropped "pinned VMID" support for now.
   - Dropped RFC tag.

History(from RFC v1):
-------------------

Please find the RFC series here,
https://lore.kernel.org/kvmarm/20210506165232.1969-1-shameerali.kolothum.thodi@huawei.com/

This is based on a suggestion from Will [0] to try out the asid
based kvm vmid solution as a separate VMID allocator instead of
the shared lib approach attempted in v4[1].

The idea is to compare both the approaches and see whether the
shared lib solution with callbacks make sense or not. 

Though we are not yet using the pinned vmids yet, patch #2 has
code for pinned vmid support. This is just to help the comparison.

Test Setup/Results
----------------
The measurement was made with maxcpus set to 8 and with the
number of VMID limited to 4-bit. The test involves running
concurrently 40 guests with 2 vCPUs. Each guest will then
execute hackbench 5 times before exiting.

The performance difference between the current algo and the
new one are(avg. of 10 runs):
    - 1.9% less entry/exit from the guest
    - 0.5% faster

This is more or less comparable to v4 numbers.

For the complete series, please see,
https://github.com/hisilicon/kernel-dev/tree/private-v5.12-rc7-vmid-2nd-rfc

and for the shared asid lib v4 solution,
https://github.com/hisilicon/kernel-dev/tree/private-v5.12-rc7-asid-v4

As you can see there are ofcourse code duplication with this
approach but may be it is more easy to maintain considering
the complexity involved.

Please take a look and let me know your feedback.

Thanks,
Shameer

Julien Grall (1):
  KVM: arm64: Align the VMID allocation with the arm64 ASID one

Shameer Kolothum (3):
  KVM: arm64: Introduce a new VMID allocator for KVM
  KVM: arm64: Make VMID bits accessible outside of allocator
  KVM: arm64: Clear active_vmids on vCPU schedule out

 arch/arm64/include/asm/kvm_host.h     |  10 +-
 arch/arm64/include/asm/kvm_mmu.h      |   4 +-
 arch/arm64/kernel/image-vars.h        |   3 +
 arch/arm64/kvm/Makefile               |   2 +-
 arch/arm64/kvm/arm.c                  | 122 +++++------------
 arch/arm64/kvm/hyp/nvhe/mem_protect.c |   3 +-
 arch/arm64/kvm/mmu.c                  |   1 -
 arch/arm64/kvm/vmid.c                 | 182 ++++++++++++++++++++++++++
 8 files changed, 228 insertions(+), 99 deletions(-)
 create mode 100644 arch/arm64/kvm/vmid.c

-- 
2.17.1

_______________________________________________
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: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
To: <linux-arm-kernel@lists.infradead.org>,
	<kvmarm@lists.cs.columbia.edu>, <linux-kernel@vger.kernel.org>
Cc: <maz@kernel.org>, <will@kernel.org>, <catalin.marinas@arm.com>,
	<james.morse@arm.com>, <julien.thierry.kdev@gmail.com>,
	<suzuki.poulose@arm.com>, <jean-philippe@linaro.org>,
	<Alexandru.Elisei@arm.com>, <qperret@google.com>,
	<linuxarm@huawei.com>
Subject: [PATCH v3 0/4] kvm/arm: New VMID allocator based on asid
Date: Thu, 29 Jul 2021 11:40:05 +0100	[thread overview]
Message-ID: <20210729104009.382-1-shameerali.kolothum.thodi@huawei.com> (raw)

Hi,

Major changes since v2 (Based on Will's feedback)
  -Dropped adding a new static key and cpufeature for retrieving
   supported VMID bits. Instead, we now make use of the 
   kvm_arm_vmid_bits variable (patch #2).

  -Since we expect less frequent rollover in the case of VMIDs,
   the TLB invalidation is now broadcasted on rollover instead
   of keeping per CPU flush_pending info and issuing a local
   context flush.  

 -Clear active_vmids on vCPU schedule out to avoid unnecessarily
  reserving the VMID space(patch #3). 

 -I have kept the struct kvm_vmid as it is for now(instead of a
  typedef as suggested), as we may soon add another variable to
  it when we introduce Pinned KVM VMID support.

Sanity tested on HiSilicon D06 board.

Thanks,
Shameer


RFCv1 --> v2
   - Dropped "pinned VMID" support for now.
   - Dropped RFC tag.

History(from RFC v1):
-------------------

Please find the RFC series here,
https://lore.kernel.org/kvmarm/20210506165232.1969-1-shameerali.kolothum.thodi@huawei.com/

This is based on a suggestion from Will [0] to try out the asid
based kvm vmid solution as a separate VMID allocator instead of
the shared lib approach attempted in v4[1].

The idea is to compare both the approaches and see whether the
shared lib solution with callbacks make sense or not. 

Though we are not yet using the pinned vmids yet, patch #2 has
code for pinned vmid support. This is just to help the comparison.

Test Setup/Results
----------------
The measurement was made with maxcpus set to 8 and with the
number of VMID limited to 4-bit. The test involves running
concurrently 40 guests with 2 vCPUs. Each guest will then
execute hackbench 5 times before exiting.

The performance difference between the current algo and the
new one are(avg. of 10 runs):
    - 1.9% less entry/exit from the guest
    - 0.5% faster

This is more or less comparable to v4 numbers.

For the complete series, please see,
https://github.com/hisilicon/kernel-dev/tree/private-v5.12-rc7-vmid-2nd-rfc

and for the shared asid lib v4 solution,
https://github.com/hisilicon/kernel-dev/tree/private-v5.12-rc7-asid-v4

As you can see there are ofcourse code duplication with this
approach but may be it is more easy to maintain considering
the complexity involved.

Please take a look and let me know your feedback.

Thanks,
Shameer

Julien Grall (1):
  KVM: arm64: Align the VMID allocation with the arm64 ASID one

Shameer Kolothum (3):
  KVM: arm64: Introduce a new VMID allocator for KVM
  KVM: arm64: Make VMID bits accessible outside of allocator
  KVM: arm64: Clear active_vmids on vCPU schedule out

 arch/arm64/include/asm/kvm_host.h     |  10 +-
 arch/arm64/include/asm/kvm_mmu.h      |   4 +-
 arch/arm64/kernel/image-vars.h        |   3 +
 arch/arm64/kvm/Makefile               |   2 +-
 arch/arm64/kvm/arm.c                  | 122 +++++------------
 arch/arm64/kvm/hyp/nvhe/mem_protect.c |   3 +-
 arch/arm64/kvm/mmu.c                  |   1 -
 arch/arm64/kvm/vmid.c                 | 182 ++++++++++++++++++++++++++
 8 files changed, 228 insertions(+), 99 deletions(-)
 create mode 100644 arch/arm64/kvm/vmid.c

-- 
2.17.1


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

             reply	other threads:[~2021-07-29 10:43 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-29 10:40 Shameer Kolothum [this message]
2021-07-29 10:40 ` [PATCH v3 0/4] kvm/arm: New VMID allocator based on asid Shameer Kolothum
2021-07-29 10:40 ` Shameer Kolothum
2021-07-29 10:40 ` [PATCH v3 1/4] KVM: arm64: Introduce a new VMID allocator for KVM Shameer Kolothum
2021-07-29 10:40   ` Shameer Kolothum
2021-07-29 10:40   ` Shameer Kolothum
2021-08-03 11:38   ` Will Deacon
2021-08-03 11:38     ` Will Deacon
2021-08-03 11:38     ` Will Deacon
2021-08-03 12:12     ` Shameerali Kolothum Thodi
2021-08-03 12:12       ` Shameerali Kolothum Thodi
2021-08-03 12:12       ` Shameerali Kolothum Thodi
2021-07-29 10:40 ` [PATCH v3 2/4] KVM: arm64: Make VMID bits accessible outside of allocator Shameer Kolothum
2021-07-29 10:40   ` Shameer Kolothum
2021-07-29 10:40   ` Shameer Kolothum
2021-07-29 10:40 ` [PATCH v3 3/4] KVM: arm64: Align the VMID allocation with the arm64 ASID one Shameer Kolothum
2021-07-29 10:40   ` Shameer Kolothum
2021-07-29 10:40   ` Shameer Kolothum
2021-07-29 14:59   ` kernel test robot
2021-07-29 14:59     ` kernel test robot
2021-07-29 14:59     ` kernel test robot
2021-07-29 10:40 ` [PATCH v3 4/4] KVM: arm64: Clear active_vmids on vCPU schedule out Shameer Kolothum
2021-07-29 10:40   ` Shameer Kolothum
2021-07-29 10:40   ` Shameer Kolothum
2021-08-03 11:40   ` Will Deacon
2021-08-03 11:40     ` Will Deacon
2021-08-03 11:40     ` Will Deacon
2021-08-03 12:55     ` Shameerali Kolothum Thodi
2021-08-03 12:55       ` Shameerali Kolothum Thodi
2021-08-03 12:55       ` Shameerali Kolothum Thodi
2021-08-03 15:30       ` Will Deacon
2021-08-03 15:30         ` Will Deacon
2021-08-03 15:30         ` Will Deacon
2021-08-03 15:56         ` Shameerali Kolothum Thodi
2021-08-03 15:56           ` Shameerali Kolothum Thodi
2021-08-03 15:56           ` Shameerali Kolothum Thodi
2021-08-06 12:24         ` Shameerali Kolothum Thodi
2021-08-06 12:24           ` Shameerali Kolothum Thodi
2021-08-06 12:24           ` Shameerali Kolothum Thodi
2021-08-09 13:09           ` Will Deacon
2021-08-09 13:09             ` Will Deacon
2021-08-09 13:09             ` Will Deacon
2021-08-09 13:48             ` Shameerali Kolothum Thodi
2021-08-09 13:48               ` Shameerali Kolothum Thodi
2021-08-09 13:48               ` Shameerali Kolothum Thodi
2021-08-11  8:47         ` Shameerali Kolothum Thodi
2021-08-11  8:47           ` Shameerali Kolothum Thodi
2021-08-11  8:47           ` Shameerali Kolothum Thodi
2021-10-11  6:06         ` Shameerali Kolothum Thodi
2021-10-11  6:06           ` Shameerali Kolothum Thodi
2021-10-11  6:06           ` Shameerali Kolothum Thodi

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=20210729104009.382-1-shameerali.kolothum.thodi@huawei.com \
    --to=shameerali.kolothum.thodi@huawei.com \
    --cc=Alexandru.Elisei@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=james.morse@arm.com \
    --cc=jean-philippe@linaro.org \
    --cc=julien.thierry.kdev@gmail.com \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=maz@kernel.org \
    --cc=qperret@google.com \
    --cc=suzuki.poulose@arm.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.