All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oliver Upton <oliver.upton@linux.dev>
To: Akihiko Odaki <akihiko.odaki@daynix.com>
Cc: Mark Brown <broonie@kernel.org>, Marc Zyngier <maz@kernel.org>,
	linux-kernel@vger.kernel.org, kvmarm@lists.linux.dev,
	kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org,
	Mathieu Poirier <mathieu.poirier@linaro.org>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Alexandru Elisei <alexandru.elisei@arm.com>,
	James Morse <james.morse@arm.com>, Will Deacon <will@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	asahi@lists.linux.dev, Alyssa Rosenzweig <alyssa@rosenzweig.io>,
	Sven Peter <sven@svenpeter.dev>, Hector Martin <marcan@marcan.st>
Subject: Re: [PATCH v5 7/7] KVM: arm64: Normalize cache configuration
Date: Thu, 5 Jan 2023 20:45:53 +0000	[thread overview]
Message-ID: <Y7c3AZJhlxKcc7y2@google.com> (raw)
In-Reply-To: <20221230095452.181764-8-akihiko.odaki@daynix.com>

Hi Akihiko,

On Fri, Dec 30, 2022 at 06:54:52PM +0900, Akihiko Odaki wrote:

[...]

> @@ -417,6 +418,9 @@ struct kvm_vcpu_arch {
>  		u64 last_steal;
>  		gpa_t base;
>  	} steal;
> +
> +	/* Per-vcpu CCSIDR override or NULL */
> +	u32 *ccsidr;

I don't believe we need to store this per-vCPU. Of course, it is
possible to userspace to observe heterogeneous cache topologies
depending on what core the KVM_GET_ONE_REG ioctl is handled on.

WDYT about keeping track of this per-VM? The value should be whatever
was last written by userspace. To avoid breaking userspace this would
also need to allow mismatched writes (i.e. vCPU0 has a different
configuration than vCPU1).

[...]

> +static u8 get_min_cache_line_size(u32 csselr)

It would be nice to have a comment indicating that it returns
Log2(line_size), not line size outright.

> +{
> +	u64 ctr_el0;
> +	int field;
> +
> +	ctr_el0 = read_sanitised_ftr_reg(SYS_CTR_EL0);
> +	field = csselr & CSSELR_EL1_InD ? CTR_EL0_IminLine_SHIFT : CTR_EL0_DminLine_SHIFT;
> +
> +	return cpuid_feature_extract_unsigned_field(ctr_el0, field) - 2;

This probably deserves a comment describing that CTR_EL0 represents line
size in units of words, not bytes. Furthermore, a subtle reminder on the
log transformation being done here would help also.

> +}
> +
>  /* Which cache CCSIDR represents depends on CSSELR value. */
> -static u32 get_ccsidr(u32 csselr)
> +static u32 get_ccsidr(struct kvm_vcpu *vcpu, u32 csselr)
>  {
> -	u32 ccsidr;
> +	if (vcpu->arch.ccsidr)
> +		return vcpu->arch.ccsidr[csselr];
>  
> -	/* Make sure noone else changes CSSELR during this! */
> -	local_irq_disable();
> -	write_sysreg(csselr, csselr_el1);
> -	isb();
> -	ccsidr = read_sysreg(ccsidr_el1);
> -	local_irq_enable();
> +	/*
> +	 * Fabricate a CCSIDR value as the overriding value does not exist.
> +	 * The real CCSIDR value will not be used as it can vary by the
> +	 * physical CPU which the vcpu currently resides in.
> +	 *
> +	 * The line size is determined with get_min_cache_line_size(), which
> +	 * should be valid for all CPUs even if they have different cache
> +	 * configuration.
> +	 *
> +	 * The associativity bits are cleared, meaning the geometry of all data
> +	 * and unified caches (which are guaranteed to be PIPT and thus
> +	 * non-aliasing) are 1 set and 1 way.
> +	 * Guests should not be doing cache operations by set/way at all, and
> +	 * for this reason, we trap them and attempt to infer the intent, so
> +	 * that we can flush the entire guest's address space at the appropriate
> +	 * time. The exposed geometry minimizes the number of the traps.
> +	 * [If guests should attempt to infer aliasing properties from the
> +	 * geometry (which is not permitted by the architecture), they would
> +	 * only do so for virtually indexed caches.]
> +	 *
> +	 * We don't check if the cache level exists as it is allowed to return
> +	 * an UNKNOWN value if not.
> +	 */
> +	return get_min_cache_line_size(csselr) << CCSIDR_EL1_LineSize_SHIFT;

I don't believe this is correct. The value of CCSIDR_EL1.LineSize is
actually:

   Log2(Number of bytes in cache line) - 4 (from DDI0487I.a D17.2.26)


With that, I'd expect the following instead:

	line_size = get_min_cache_line_size(csselr);
	return FIELD_PREP(CCSIDR_EL1_LineSize_MASK, line_size - 4);

--
Thanks,
Oliver

WARNING: multiple messages have this Message-ID (diff)
From: Oliver Upton <oliver.upton@linux.dev>
To: Akihiko Odaki <akihiko.odaki@daynix.com>
Cc: Alyssa Rosenzweig <alyssa@rosenzweig.io>,
	Hector Martin <marcan@marcan.st>,
	Mathieu Poirier <mathieu.poirier@linaro.org>,
	Marc Zyngier <maz@kernel.org>, Sven Peter <sven@svenpeter.dev>,
	linux-kernel@vger.kernel.org, Will Deacon <will@kernel.org>,
	Mark Brown <broonie@kernel.org>,
	asahi@lists.linux.dev, Catalin Marinas <catalin.marinas@arm.com>,
	kvmarm@lists.linux.dev, kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v5 7/7] KVM: arm64: Normalize cache configuration
Date: Thu, 5 Jan 2023 20:45:53 +0000	[thread overview]
Message-ID: <Y7c3AZJhlxKcc7y2@google.com> (raw)
In-Reply-To: <20221230095452.181764-8-akihiko.odaki@daynix.com>

Hi Akihiko,

On Fri, Dec 30, 2022 at 06:54:52PM +0900, Akihiko Odaki wrote:

[...]

> @@ -417,6 +418,9 @@ struct kvm_vcpu_arch {
>  		u64 last_steal;
>  		gpa_t base;
>  	} steal;
> +
> +	/* Per-vcpu CCSIDR override or NULL */
> +	u32 *ccsidr;

I don't believe we need to store this per-vCPU. Of course, it is
possible to userspace to observe heterogeneous cache topologies
depending on what core the KVM_GET_ONE_REG ioctl is handled on.

WDYT about keeping track of this per-VM? The value should be whatever
was last written by userspace. To avoid breaking userspace this would
also need to allow mismatched writes (i.e. vCPU0 has a different
configuration than vCPU1).

[...]

> +static u8 get_min_cache_line_size(u32 csselr)

It would be nice to have a comment indicating that it returns
Log2(line_size), not line size outright.

> +{
> +	u64 ctr_el0;
> +	int field;
> +
> +	ctr_el0 = read_sanitised_ftr_reg(SYS_CTR_EL0);
> +	field = csselr & CSSELR_EL1_InD ? CTR_EL0_IminLine_SHIFT : CTR_EL0_DminLine_SHIFT;
> +
> +	return cpuid_feature_extract_unsigned_field(ctr_el0, field) - 2;

This probably deserves a comment describing that CTR_EL0 represents line
size in units of words, not bytes. Furthermore, a subtle reminder on the
log transformation being done here would help also.

> +}
> +
>  /* Which cache CCSIDR represents depends on CSSELR value. */
> -static u32 get_ccsidr(u32 csselr)
> +static u32 get_ccsidr(struct kvm_vcpu *vcpu, u32 csselr)
>  {
> -	u32 ccsidr;
> +	if (vcpu->arch.ccsidr)
> +		return vcpu->arch.ccsidr[csselr];
>  
> -	/* Make sure noone else changes CSSELR during this! */
> -	local_irq_disable();
> -	write_sysreg(csselr, csselr_el1);
> -	isb();
> -	ccsidr = read_sysreg(ccsidr_el1);
> -	local_irq_enable();
> +	/*
> +	 * Fabricate a CCSIDR value as the overriding value does not exist.
> +	 * The real CCSIDR value will not be used as it can vary by the
> +	 * physical CPU which the vcpu currently resides in.
> +	 *
> +	 * The line size is determined with get_min_cache_line_size(), which
> +	 * should be valid for all CPUs even if they have different cache
> +	 * configuration.
> +	 *
> +	 * The associativity bits are cleared, meaning the geometry of all data
> +	 * and unified caches (which are guaranteed to be PIPT and thus
> +	 * non-aliasing) are 1 set and 1 way.
> +	 * Guests should not be doing cache operations by set/way at all, and
> +	 * for this reason, we trap them and attempt to infer the intent, so
> +	 * that we can flush the entire guest's address space at the appropriate
> +	 * time. The exposed geometry minimizes the number of the traps.
> +	 * [If guests should attempt to infer aliasing properties from the
> +	 * geometry (which is not permitted by the architecture), they would
> +	 * only do so for virtually indexed caches.]
> +	 *
> +	 * We don't check if the cache level exists as it is allowed to return
> +	 * an UNKNOWN value if not.
> +	 */
> +	return get_min_cache_line_size(csselr) << CCSIDR_EL1_LineSize_SHIFT;

I don't believe this is correct. The value of CCSIDR_EL1.LineSize is
actually:

   Log2(Number of bytes in cache line) - 4 (from DDI0487I.a D17.2.26)


With that, I'd expect the following instead:

	line_size = get_min_cache_line_size(csselr);
	return FIELD_PREP(CCSIDR_EL1_LineSize_MASK, line_size - 4);

--
Thanks,
Oliver
_______________________________________________
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: Oliver Upton <oliver.upton@linux.dev>
To: Akihiko Odaki <akihiko.odaki@daynix.com>
Cc: Mark Brown <broonie@kernel.org>, Marc Zyngier <maz@kernel.org>,
	linux-kernel@vger.kernel.org, kvmarm@lists.linux.dev,
	kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org,
	Mathieu Poirier <mathieu.poirier@linaro.org>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Alexandru Elisei <alexandru.elisei@arm.com>,
	James Morse <james.morse@arm.com>, Will Deacon <will@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	asahi@lists.linux.dev, Alyssa Rosenzweig <alyssa@rosenzweig.io>,
	Sven Peter <sven@svenpeter.dev>, Hector Martin <marcan@marcan.st>
Subject: Re: [PATCH v5 7/7] KVM: arm64: Normalize cache configuration
Date: Thu, 5 Jan 2023 20:45:53 +0000	[thread overview]
Message-ID: <Y7c3AZJhlxKcc7y2@google.com> (raw)
In-Reply-To: <20221230095452.181764-8-akihiko.odaki@daynix.com>

Hi Akihiko,

On Fri, Dec 30, 2022 at 06:54:52PM +0900, Akihiko Odaki wrote:

[...]

> @@ -417,6 +418,9 @@ struct kvm_vcpu_arch {
>  		u64 last_steal;
>  		gpa_t base;
>  	} steal;
> +
> +	/* Per-vcpu CCSIDR override or NULL */
> +	u32 *ccsidr;

I don't believe we need to store this per-vCPU. Of course, it is
possible to userspace to observe heterogeneous cache topologies
depending on what core the KVM_GET_ONE_REG ioctl is handled on.

WDYT about keeping track of this per-VM? The value should be whatever
was last written by userspace. To avoid breaking userspace this would
also need to allow mismatched writes (i.e. vCPU0 has a different
configuration than vCPU1).

[...]

> +static u8 get_min_cache_line_size(u32 csselr)

It would be nice to have a comment indicating that it returns
Log2(line_size), not line size outright.

> +{
> +	u64 ctr_el0;
> +	int field;
> +
> +	ctr_el0 = read_sanitised_ftr_reg(SYS_CTR_EL0);
> +	field = csselr & CSSELR_EL1_InD ? CTR_EL0_IminLine_SHIFT : CTR_EL0_DminLine_SHIFT;
> +
> +	return cpuid_feature_extract_unsigned_field(ctr_el0, field) - 2;

This probably deserves a comment describing that CTR_EL0 represents line
size in units of words, not bytes. Furthermore, a subtle reminder on the
log transformation being done here would help also.

> +}
> +
>  /* Which cache CCSIDR represents depends on CSSELR value. */
> -static u32 get_ccsidr(u32 csselr)
> +static u32 get_ccsidr(struct kvm_vcpu *vcpu, u32 csselr)
>  {
> -	u32 ccsidr;
> +	if (vcpu->arch.ccsidr)
> +		return vcpu->arch.ccsidr[csselr];
>  
> -	/* Make sure noone else changes CSSELR during this! */
> -	local_irq_disable();
> -	write_sysreg(csselr, csselr_el1);
> -	isb();
> -	ccsidr = read_sysreg(ccsidr_el1);
> -	local_irq_enable();
> +	/*
> +	 * Fabricate a CCSIDR value as the overriding value does not exist.
> +	 * The real CCSIDR value will not be used as it can vary by the
> +	 * physical CPU which the vcpu currently resides in.
> +	 *
> +	 * The line size is determined with get_min_cache_line_size(), which
> +	 * should be valid for all CPUs even if they have different cache
> +	 * configuration.
> +	 *
> +	 * The associativity bits are cleared, meaning the geometry of all data
> +	 * and unified caches (which are guaranteed to be PIPT and thus
> +	 * non-aliasing) are 1 set and 1 way.
> +	 * Guests should not be doing cache operations by set/way at all, and
> +	 * for this reason, we trap them and attempt to infer the intent, so
> +	 * that we can flush the entire guest's address space at the appropriate
> +	 * time. The exposed geometry minimizes the number of the traps.
> +	 * [If guests should attempt to infer aliasing properties from the
> +	 * geometry (which is not permitted by the architecture), they would
> +	 * only do so for virtually indexed caches.]
> +	 *
> +	 * We don't check if the cache level exists as it is allowed to return
> +	 * an UNKNOWN value if not.
> +	 */
> +	return get_min_cache_line_size(csselr) << CCSIDR_EL1_LineSize_SHIFT;

I don't believe this is correct. The value of CCSIDR_EL1.LineSize is
actually:

   Log2(Number of bytes in cache line) - 4 (from DDI0487I.a D17.2.26)


With that, I'd expect the following instead:

	line_size = get_min_cache_line_size(csselr);
	return FIELD_PREP(CCSIDR_EL1_LineSize_MASK, line_size - 4);

--
Thanks,
Oliver

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

  reply	other threads:[~2023-01-05 20:52 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-30  9:54 [PATCH v5 0/7] KVM: arm64: Normalize cache configuration Akihiko Odaki
2022-12-30  9:54 ` Akihiko Odaki
2022-12-30  9:54 ` Akihiko Odaki
2022-12-30  9:54 ` Akihiko Odaki
2022-12-30  9:54 ` [PATCH v5 1/7] arm64: Allow the definition of UNKNOWN system register fields Akihiko Odaki
2022-12-30  9:54   ` Akihiko Odaki
2022-12-30  9:54   ` Akihiko Odaki
2022-12-30  9:54   ` Akihiko Odaki
2022-12-30  9:54 ` [PATCH v5 2/7] arm64/sysreg: Convert CCSIDR_EL1 to automatic generation Akihiko Odaki
2022-12-30  9:54   ` Akihiko Odaki
2022-12-30  9:54   ` Akihiko Odaki
2022-12-30  9:54   ` Akihiko Odaki
2022-12-30  9:54 ` [PATCH v5 3/7] arm64/sysreg: Add CCSIDR2_EL1 Akihiko Odaki
2022-12-30  9:54   ` Akihiko Odaki
2022-12-30  9:54   ` Akihiko Odaki
2022-12-30  9:54   ` Akihiko Odaki
2022-12-30  9:54 ` [PATCH v5 4/7] arm64/cache: Move CLIDR macro definitions Akihiko Odaki
2022-12-30  9:54   ` Akihiko Odaki
2022-12-30  9:54   ` Akihiko Odaki
2022-12-30  9:54   ` Akihiko Odaki
2022-12-30  9:54 ` [PATCH v5 5/7] KVM: arm64: Always set HCR_TID2 Akihiko Odaki
2022-12-30  9:54   ` Akihiko Odaki
2022-12-30  9:54   ` Akihiko Odaki
2022-12-30  9:54   ` Akihiko Odaki
2023-01-06  4:29   ` Reiji Watanabe
2023-01-06  4:29     ` Reiji Watanabe
2022-12-30  9:54 ` [PATCH v5 6/7] KVM: arm64: Mask FEAT_CCIDX Akihiko Odaki
2022-12-30  9:54   ` Akihiko Odaki
2022-12-30  9:54   ` Akihiko Odaki
2022-12-30  9:54   ` Akihiko Odaki
2023-01-05 22:22   ` Oliver Upton
2023-01-05 22:22     ` Oliver Upton
2023-01-07  9:53     ` Akihiko Odaki
2023-01-07  9:53       ` Akihiko Odaki
2023-01-08 18:54       ` Oliver Upton
2023-01-08 18:54         ` Oliver Upton
2022-12-30  9:54 ` [PATCH v5 7/7] KVM: arm64: Normalize cache configuration Akihiko Odaki
2022-12-30  9:54   ` Akihiko Odaki
2022-12-30  9:54   ` Akihiko Odaki
2022-12-30  9:54   ` Akihiko Odaki
2023-01-05 20:45   ` Oliver Upton [this message]
2023-01-05 20:45     ` Oliver Upton
2023-01-05 20:45     ` Oliver Upton
2023-01-07 10:04     ` Akihiko Odaki
2023-01-07 10:04       ` Akihiko Odaki

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=Y7c3AZJhlxKcc7y2@google.com \
    --to=oliver.upton@linux.dev \
    --cc=akihiko.odaki@daynix.com \
    --cc=alexandru.elisei@arm.com \
    --cc=alyssa@rosenzweig.io \
    --cc=asahi@lists.linux.dev \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=james.morse@arm.com \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcan@marcan.st \
    --cc=mathieu.poirier@linaro.org \
    --cc=maz@kernel.org \
    --cc=suzuki.poulose@arm.com \
    --cc=sven@svenpeter.dev \
    --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.