All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Alexandru Elisei <alexandru.elisei@arm.com>
Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
	kvm@vger.kernel.org, James Morse <james.morse@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Oliver Upton <oliver.upton@linux.dev>,
	Zenghui Yu <yuzenghui@huawei.com>,
	Joey Gouly <joey.gouly@arm.com>,
	Anshuman Khandual <anshuman.khandual@arm.com>,
	Przemyslaw Gaj <pgaj@cadence.com>
Subject: Re: [PATCH v3 14/18] KVM: arm64: nv: Add SW walker for AT S1 emulation
Date: Fri, 16 Aug 2024 14:44:58 +0100	[thread overview]
Message-ID: <86jzggzin9.wl-maz@kernel.org> (raw)
In-Reply-To: <Zr8xzdmMELK07YUo@raptor>

On Fri, 16 Aug 2024 12:02:37 +0100,
Alexandru Elisei <alexandru.elisei@arm.com> wrote:
> 
> Hi Marc,
> 
> On Fri, Aug 16, 2024 at 11:37:24AM +0100, Marc Zyngier wrote:
> > Hi Alex,
> > 
> > On Fri, 16 Aug 2024 10:22:43 +0100,
> > Alexandru Elisei <alexandru.elisei@arm.com> wrote:
> > > 
> > > Hi Marc,
> > > 
> > > On Thu, Aug 15, 2024 at 07:28:41PM +0100, Marc Zyngier wrote:
> > > > 
> > > > Hi Alex,
> > > > 
> > > > On Thu, 15 Aug 2024 17:44:02 +0100,
> > > > Alexandru Elisei <alexandru.elisei@arm.com> wrote:
> > 
> > [...]
> > 
> > > > > > +static bool par_check_s1_perm_fault(u64 par)
> > > > > > +{
> > > > > > +	u8 fst = FIELD_GET(SYS_PAR_EL1_FST, par);
> > > > > > +
> > > > > > +	return  ((fst & ESR_ELx_FSC_TYPE) == ESR_ELx_FSC_PERM &&
> > > > > > +		 !(par & SYS_PAR_EL1_S));
> > > > > 
> > > > > ESR_ELx_FSC_PERM = 0x0c is a permission fault, level 0, which Arm ARM says can
> > > > > only happen when FEAT_LPA2. I think the code should check that the value for
> > > > > PAR_EL1.FST is in the interval (ESR_ELx_FSC_PERM_L(0), ESR_ELx_FSC_PERM_L(3)].
> > > > 
> > > > I honestly don't want to second-guess the HW. If it reports something
> > > > that is the wrong level, why should we trust the FSC at all?
> > > 
> > > Sorry, I should have been clearer.
> > > 
> > > It's not about the hardware reporting a fault on level 0 of the translation
> > > tables, it's about the function returning false if the hardware reports a
> > > permission fault on levels 1, 2 or 3 of the translation tables.
> > > 
> > > For example, on a permssion fault on level 3, PAR_EL1. FST = 0b001111 = 0x0F,
> > > which means that the condition:
> > > 
> > > (fst & ESR_ELx_FSC_TYPE) == ESR_ELx_FSC_PERM (which is 0x0C) is false and KVM
> > > will fall back to the software walker.
> > > 
> > > Does that make sense to you?
> > 
> > I'm afraid I still don't get it.
> > 
> > From the kernel source:
> > 
> > #define ESR_ELx_FSC_TYPE	(0x3C)
> > 
> > This is a mask covering all fault types.
> > 
> > #define ESR_ELx_FSC_PERM	(0x0C)
> > 
> > This is the value for a permission fault, not encoding a level.
> > 
> > Taking your example:
> > 
> > (fst & ESR_ELx_FSC_TYPE) == (0x0F & 0x3C) == 0x0C == ESR_ELx_FSC_PERM
> > 
> > As I read it, the condition is true, as it catches a permission fault
> > on any level between 0 and 3.
> > 
> > You're obviously seeing something I don't, and I'm starting to
> > question my own sanity...
> 
> No, no, sorry for leading you on a wild goose chase, I read 0x3F for
> ESR_ELx_FSC_TYPE, which the value for the variable directly above it, instead of
> 0x3C :(
> 
> My bad, the code is correct!

Ah, glad we agree, I was starting to worry!

Thanks,

	M.

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

  reply	other threads:[~2024-08-16 13:45 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-13 10:05 [PATCH v3 00/18] KVM: arm64: nv: Add support for address translation instructions Marc Zyngier
2024-08-13 10:05 ` [PATCH v3 01/18] arm64: Add missing APTable and TCR_ELx.HPD masks Marc Zyngier
2024-08-13 10:05 ` [PATCH v3 02/18] arm64: Add PAR_EL1 field description Marc Zyngier
2024-08-13 10:05 ` [PATCH v3 03/18] arm64: Add system register encoding for PSTATE.PAN Marc Zyngier
2024-08-13 10:05 ` [PATCH v3 04/18] arm64: Add ESR_ELx_FSC_ADDRSZ_L() helper Marc Zyngier
2024-08-13 10:05 ` [PATCH v3 05/18] KVM: arm64: Make kvm_at() take an OP_AT_* Marc Zyngier
2024-08-13 10:05 ` [PATCH v3 06/18] KVM: arm64: nv: Enforce S2 alignment when contiguous bit is set Marc Zyngier
2024-08-13 10:05 ` [PATCH v3 07/18] KVM: arm64: nv: Turn upper_attr for S2 walk into the full descriptor Marc Zyngier
2024-08-13 10:05 ` [PATCH v3 08/18] KVM: arm64: nv: Honor absence of FEAT_PAN2 Marc Zyngier
2024-08-13 10:05 ` [PATCH v3 09/18] KVM: arm64: nv: Add basic emulation of AT S1E{0,1}{R,W} Marc Zyngier
2024-08-13 10:05 ` [PATCH v3 10/18] KVM: arm64: nv: Add basic emulation of AT S1E1{R,W}P Marc Zyngier
2024-08-13 10:05 ` [PATCH v3 11/18] KVM: arm64: nv: Add basic emulation of AT S1E2{R,W} Marc Zyngier
2024-08-13 10:05 ` [PATCH v3 12/18] KVM: arm64: nv: Add emulation of AT S12E{0,1}{R,W} Marc Zyngier
2024-08-13 10:05 ` [PATCH v3 13/18] KVM: arm64: nv: Make ps_to_output_size() generally available Marc Zyngier
2024-08-13 10:05 ` [PATCH v3 14/18] KVM: arm64: nv: Add SW walker for AT S1 emulation Marc Zyngier
2024-08-14 10:08   ` Marc Zyngier
2024-08-15 16:44   ` Alexandru Elisei
2024-08-15 18:28     ` Marc Zyngier
2024-08-16  9:22       ` Alexandru Elisei
2024-08-16 10:37         ` Marc Zyngier
2024-08-16 11:02           ` Alexandru Elisei
2024-08-16 13:44             ` Marc Zyngier [this message]
2024-08-13 10:05 ` [PATCH v3 15/18] KVM: arm64: nv: Sanitise SCTLR_EL1.EPAN according to VM configuration Marc Zyngier
2024-08-13 10:05 ` [PATCH v3 16/18] KVM: arm64: nv: Make AT+PAN instructions aware of FEAT_PAN3 Marc Zyngier
2024-08-15 16:47   ` Alexandru Elisei
2024-08-13 10:05 ` [PATCH v3 17/18] KVM: arm64: nv: Plumb handling of AT S1* traps from EL2 Marc Zyngier
2024-08-13 10:05 ` [PATCH v3 18/18] KVM: arm64: nv: Add support for FEAT_ATS1A Marc Zyngier

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=86jzggzin9.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=alexandru.elisei@arm.com \
    --cc=anshuman.khandual@arm.com \
    --cc=james.morse@arm.com \
    --cc=joey.gouly@arm.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=oliver.upton@linux.dev \
    --cc=pgaj@cadence.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.