All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oliver Upton <oliver.upton@linux.dev>
To: James Morse <james.morse@arm.com>
Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
	Marc Zyngier <maz@kernel.org>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Zenghui Yu <yuzenghui@huawei.com>
Subject: Re: [PATCH v2 0/4] KVM: arm64: Hide unsupported MPAM from the guest
Date: Tue, 23 Jan 2024 19:00:23 +0000	[thread overview]
Message-ID: <ZbAMxyGcSZY7Kl7Z@linux.dev> (raw)
In-Reply-To: <f06ed418-922d-54c5-22a0-bde127146b5a@arm.com>

On Fri, Jan 19, 2024 at 05:15:59PM +0000, James Morse wrote:

[...]

> > We've already done something similar to hide our mistakes with IMP DEF
> > PMU versions in commit f90f9360c3d7 ("KVM: arm64: Rewrite IMPDEF PMU
> > version as NI"), and I think MPAM may be a good candidate for something
> > similar.
> 
> As there is precedent, I feel less dirty doing that!
> 
> This also solves the problem of the VMM re-writing the broken value after the vCPU has
> started running, and getting a surprise error. A weird side effect of doing this would be
> you can write MPAM=1 on A53 and KVM will ignore it, I don't want user-space to start
> relying on that! I'll add a final-cap check so this can only be ignored on hardware that
> actually has MPAM, and could have been exposed to the bug.

Ah, good idea. I probably should've done something similar in the PMU
case.

-- 
Thanks,
Oliver

WARNING: multiple messages have this Message-ID (diff)
From: Oliver Upton <oliver.upton@linux.dev>
To: James Morse <james.morse@arm.com>
Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
	Marc Zyngier <maz@kernel.org>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Zenghui Yu <yuzenghui@huawei.com>
Subject: Re: [PATCH v2 0/4] KVM: arm64: Hide unsupported MPAM from the guest
Date: Tue, 23 Jan 2024 19:00:23 +0000	[thread overview]
Message-ID: <ZbAMxyGcSZY7Kl7Z@linux.dev> (raw)
In-Reply-To: <f06ed418-922d-54c5-22a0-bde127146b5a@arm.com>

On Fri, Jan 19, 2024 at 05:15:59PM +0000, James Morse wrote:

[...]

> > We've already done something similar to hide our mistakes with IMP DEF
> > PMU versions in commit f90f9360c3d7 ("KVM: arm64: Rewrite IMPDEF PMU
> > version as NI"), and I think MPAM may be a good candidate for something
> > similar.
> 
> As there is precedent, I feel less dirty doing that!
> 
> This also solves the problem of the VMM re-writing the broken value after the vCPU has
> started running, and getting a surprise error. A weird side effect of doing this would be
> you can write MPAM=1 on A53 and KVM will ignore it, I don't want user-space to start
> relying on that! I'll add a final-cap check so this can only be ignored on hardware that
> actually has MPAM, and could have been exposed to the bug.

Ah, good idea. I probably should've done something similar in the PMU
case.

-- 
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:[~2024-01-23 19:00 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-07 15:08 [PATCH v2 0/4] KVM: arm64: Hide unsupported MPAM from the guest James Morse
2023-12-07 15:08 ` James Morse
2023-12-07 15:08 ` [PATCH v2 1/4] arm64: head.S: Initialise MPAM EL2 registers and disable traps James Morse
2023-12-07 15:08   ` James Morse
2023-12-07 15:08 ` [PATCH v2 2/4] arm64: cpufeature: discover CPU support for MPAM James Morse
2023-12-07 15:08   ` James Morse
2023-12-07 15:08 ` [PATCH v2 3/4] KVM: arm64: Fix missing traps of guest accesses to the MPAM registers James Morse
2023-12-07 15:08   ` James Morse
2023-12-07 15:08 ` [PATCH v2 4/4] KVM: arm64: Disable MPAM visibility by default, and handle traps James Morse
2023-12-07 15:08   ` James Morse
2023-12-13 20:24 ` [PATCH v2 0/4] KVM: arm64: Hide unsupported MPAM from the guest Oliver Upton
2023-12-13 20:24   ` Oliver Upton
2024-01-19 17:15   ` James Morse
2024-01-19 17:15     ` James Morse
2024-01-23 19:00     ` Oliver Upton [this message]
2024-01-23 19:00       ` Oliver Upton
2024-03-08 17:48       ` Jing Zhang
2024-03-08 17:48         ` Jing Zhang
2024-03-21 15:37         ` James Morse
2024-03-21 15:37           ` James Morse

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=ZbAMxyGcSZY7Kl7Z@linux.dev \
    --to=oliver.upton@linux.dev \
    --cc=james.morse@arm.com \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=maz@kernel.org \
    --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.