Date: Mon, 8 Apr 2024 23:03:03 +0200 From: Paul Floyd <pjfloyd@wanadoo.fr> To: freebsd-arm@freebsd.org Subject: Re: arm64 mrs and system registers Message-ID: <25700410-7722-4EC4-82EC-3D87E1937EEA@wanadoo.fr> In-Reply-To: <CANCZdfpQBTWK-8DTR0TwE8LzPe81EQ7LzwZpw54iQeAs9d7Fvw@mail.gmail.com> References: <e7aa2897-e05a-4a91-a1a0-f6c0a03156ae@wanadoo.fr> <CANCZdfpQBTWK-8DTR0TwE8LzPe81EQ7LzwZpw54iQeAs9d7Fvw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_BCCFAA6D-72A5-44DF-AD11-67D9B7519CF4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 8 Apr 2024, at 22:31, Warner Losh <imp@bsdimp.com> wrote: >=20 >=20 >=20 > On Mon, Apr 8, 2024 at 9:03=E2=80=AFPM Paul Floyd <pjfloyd@wanadoo.fr = <mailto:pjfloyd@wanadoo.fr>> wrote: >> Hi >>=20 >> I've been looking at this bugzilla item >>=20 >> https://bugs.kde.org/show_bug.cgi?id=3D392146 >>=20 >> Is there any difference between Linux and FreeBSD when it comes to = what=20 >> registers and fields are exposed by the kernel (see comment 17 in the=20= >> link above). >=20 > 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. > =20 >> I did have a poke around the kernel code but it's a bit hard to tell=20= >> exactly which of the access macros are being used, without = exhaustively=20 >> grepping for them one by one. >=20 > 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. >=20 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 --Apple-Mail=_BCCFAA6D-72A5-44DF-AD11-67D9B7519CF4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"content-type" content=3D"text/html; = charset=3Dutf-8"></head><body style=3D"overflow-wrap: break-word; = -webkit-nbsp-mode: space; line-break: = after-white-space;"><br><div><br><blockquote type=3D"cite"><div>On 8 Apr = 2024, at 22:31, Warner Losh <imp@bsdimp.com> wrote:</div><br = class=3D"Apple-interchange-newline"><div><div dir=3D"ltr"><div = dir=3D"ltr"><br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" = class=3D"gmail_attr">On Mon, Apr 8, 2024 at 9:03=E2=80=AFPM Paul Floyd = <<a href=3D"mailto:pjfloyd@wanadoo.fr">pjfloyd@wanadoo.fr</a>> = wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px = 0px 0px 0.8ex;border-left:1px solid = rgb(204,204,204);padding-left:1ex">Hi<br> <br> I've been looking at this bugzilla item<br> <br> <a href=3D"https://bugs.kde.org/show_bug.cgi?id=3D392146" = rel=3D"noreferrer" = target=3D"_blank">https://bugs.kde.org/show_bug.cgi?id=3D392146</a><br>; <br> Is there any difference between Linux and FreeBSD when it comes to what = <br> registers and fields are exposed by the kernel (see comment 17 in the = <br> link above).<br></blockquote><div><br></div><div>I don't think so. We've = not seen issues with other drivers on aarch64 except</div><div>when they = were written on x86 and didn't have the synchronization = needed</div><div>for the weaker memory models in aarch64 = systems.</div><div> </div><blockquote class=3D"gmail_quote" = style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid = rgb(204,204,204);padding-left:1ex"> I did have a poke around the kernel code but it's a bit hard to tell = <br> exactly which of the access macros are being used, without exhaustively = <br> grepping for them one by one.<br></blockquote><div><br></div><div>Yea, I = think that there's missing atomics on the state transitions = and/or</div><div>some missing locking that "magically" provides barriers = that make it work</div><div>on x86.</div><div><br></div></div></div> </div></blockquote><br></div><div>Hi</div><div><br></div><div>There = aren=E2=80=99t any memory issues.</div><div><br></div><div>The problem = is that the opcodes aren=E2=80=99t fully covered. There are 3 aspects to = that</div><div>1. What the kernel exposes</div><div>2. What Valgrind = implements (usually a subset of point 1 but it should claim things that = the kernel doesn=E2=80=99t support).</div><div>3. Actually handling the = opcode.</div><div><br></div><div>If Linux and FreeBSD expose the same = things then I can go ahead with looking at a common = solution.</div><div><br></div><div><br></div><div>A+</div><div>Paul</div><= br></body></html>= --Apple-Mail=_BCCFAA6D-72A5-44DF-AD11-67D9B7519CF4--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?25700410-7722-4EC4-82EC-3D87E1937EEA>