From nobody Mon Apr 8 21:18:25 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4VD25C4qxhz5Fq8J for ; Mon, 8 Apr 2024 21:18:39 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VD25C35Wwz4K21 for ; Mon, 8 Apr 2024 21:18:39 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x62a.google.com with SMTP id a640c23a62f3a-a51b008b3aeso320530166b.3 for ; Mon, 08 Apr 2024 14:18:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1712611117; x=1713215917; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=mBiw9EyHfzhI9+Phzat0LAINUORRtoCYAzlU1G5Qn1k=; b=UsRwon1xpCJ83F+bQmd3+Md5bZNRSK/k63l0Qgum3g1I1QcLBxKTgWtvybSgakxqcx mJo574UHaBlnS7UDEUJxigekK9IchfeaQcY7DUOHpDAlp2WJEIkgOon0/Wc8k1IjK8Wq JMk9Vmj7tUZ6QW/N5BT84bTJuuMdmeOgOo1uXBL7TUhww2z3llwEh4wmIr1uZsLlWxr/ 7YDXuQR25PRMQupIObu9MPlvoxrFSjAH094CQ2dtDNrvW6IWDG16gmekGaU1zAvIdWmj 5TtKaN4AQh8hn+9XFOaW0rZmfLPM9XyqePm7AeMvlwC14bwfrnf/DkrKz2916PZhlyDm hLpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712611117; x=1713215917; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=mBiw9EyHfzhI9+Phzat0LAINUORRtoCYAzlU1G5Qn1k=; b=RKxy8BgDSd7RVuXVoAwcF7Se0c2TXo9c0WCRL7ssZEzIbGehLEOSrhf6Ka2XHXpC6I 9N2NwAhJ00f7PAh7ypbu1rTQNp9UABqTFoWM58fp+vbfalc20fBs32FyN0mhkIz2sF1p QuigSV+urry2HhEceRIXlQt4fBwkkX5Ae2HpThhAZhDcHJd/Q6Ooxvki7LMQ0x8MRKtS iebxvCFlt8wpL/bSL0MHwByQpG2N+tLgUnRWFi0h5/6oJPrToGOBVoT1uZPNVQZpLdLl dE5AYrSYM4QPg6UGC3Es3YTtx0af2DDLAea6JCVlbF+cy6/gVEFMKfi/XOJEpCJqc2IA o12w== X-Gm-Message-State: AOJu0YzExK4zs3tPqboOpiA4nmqPcdr8XA5MoN3n6+CS9oe3ejVE7Li0 qO/hDL8mjtUKB1w4B1T48Vvp1Tru94iCcwyVPaa+ejyzL0IRxC3nbuVqAYrt8PlbZWZxjkdu34E qFx+f2tKzhzRuOhhFQTM9yXA1SsXZmMZ7S5Pxwg== X-Google-Smtp-Source: AGHT+IHN6ywjF2L5l6uBPWvy63vbOK6X5SjScqzuvB/z+qJPi9h3MtjulDAV4Vw9jXP597/qkEE+B3kMVnD0S01gD1A= X-Received: by 2002:a17:907:728a:b0:a51:bddf:eaf2 with SMTP id dt10-20020a170907728a00b00a51bddfeaf2mr5724474ejc.18.1712611117356; Mon, 08 Apr 2024 14:18:37 -0700 (PDT) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <25700410-7722-4EC4-82EC-3D87E1937EEA@wanadoo.fr> In-Reply-To: <25700410-7722-4EC4-82EC-3D87E1937EEA@wanadoo.fr> From: Warner Losh Date: Mon, 8 Apr 2024 15:18:25 -0600 Message-ID: Subject: Re: arm64 mrs and system registers To: Paul Floyd Cc: "freebsd-arm@freebsd.org" Content-Type: multipart/alternative; boundary="00000000000049f38206159c59a0" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4VD25C35Wwz4K21 --00000000000049f38206159c59a0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Forget everything i said. I got this confused with a different bug. Sorry about that. Warner On Mon, Apr 8, 2024, 3:03=E2=80=AFPM Paul Floyd wrote: > > > On 8 Apr 2024, at 22:31, Warner Losh wrote: > > > > On Mon, Apr 8, 2024 at 9:03=E2=80=AFPM Paul Floyd wr= ote: > >> Hi >> >> I've been looking at this bugzilla item >> >> https://bugs.kde.org/show_bug.cgi?id=3D392146 >> >> Is there any difference between Linux and FreeBSD when it comes to what >> registers and fields are exposed by the kernel (see comment 17 in the >> link above). >> > > I don't think so. We've not seen issues with other drivers on aarch64 > except > when they were written on x86 and didn't have the synchronization needed > for the weaker memory models in aarch64 systems. > > >> I did have a poke around the kernel code but it's a bit hard to tell >> exactly which of the access macros are being used, without exhaustively >> grepping for them one by one. >> > > Yea, I think that there's missing atomics on the state transitions and/or > some missing locking that "magically" provides barriers that make it work > on x86. > > > Hi > > There aren=E2=80=99t any memory issues. > > The problem is that the opcodes aren=E2=80=99t fully covered. There are 3= aspects > to that > 1. What the kernel exposes > 2. What Valgrind implements (usually a subset of point 1 but it should > claim things that the kernel doesn=E2=80=99t support). > 3. Actually handling the opcode. > > If Linux and FreeBSD expose the same things then I can go ahead with > looking at a common solution. > > > A+ > Paul > > --00000000000049f38206159c59a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Forget everything i said. I got this confused with a diff= erent bug. Sorry about that.

<= br>
Warner

On Mon, Apr 8, 2024, 3:03=E2=80=AFPM= Paul Floyd <pjfloyd@wanadoo.fr> wrote:





On Mon, Apr 8, 2024 at 9:03=E2=80=AFPM P= aul Floyd <pjfloyd@wanadoo.fr> wrote:
Hi

I've been looking at this bugzilla item

https://bugs.kde.org/show_bug.cgi?id=3D39214= 6

Is there any difference between Linux and FreeBSD when it comes to what registers and fields are exposed by the kernel (see comment 17 in the
link above).

I don't think so. We&#= 39;ve not seen issues with other drivers on aarch64 except
when t= hey were written on x86 and didn't have the synchronization needed
for the weaker memory models in aarch64 systems.
=C2=A0
I did have a poke around the kernel code but it's a bit hard to tell exactly which of the access macros are being used, without exhaustively grepping for them one by one.

Yea, I th= ink that there's missing atomics on the state transitions and/or
<= div>some missing locking that "magically" provides barriers that = make it work
on x86.


Hi

There aren=E2= =80=99t any memory issues.

The problem is that the= opcodes aren=E2=80=99t fully covered. There are 3 aspects to that
1. What the kernel exposes
2. What Valgrind implements (usually= a subset of point 1 but it should claim things that the kernel doesn=E2=80= =99t support).
3. Actually handling the opcode.

If Linux and FreeBSD expose the same things then I can go ahead wit= h looking at a common solution.


A+<= /div>
Paul

--00000000000049f38206159c59a0--