Date: Mon, 8 Apr 2024 15:18:25 -0600 From: Warner Losh <imp@bsdimp.com> To: Paul Floyd <pjfloyd@wanadoo.fr> Cc: "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: arm64 mrs and system registers Message-ID: <CANCZdfq0cT-vvw_bXmt4JDAupR8nTDd_xVa6SdGAHK_0%2Br5DAw@mail.gmail.com> In-Reply-To: <25700410-7722-4EC4-82EC-3D87E1937EEA@wanadoo.fr> References: <e7aa2897-e05a-4a91-a1a0-f6c0a03156ae@wanadoo.fr> <CANCZdfpQBTWK-8DTR0TwE8LzPe81EQ7LzwZpw54iQeAs9d7Fvw@mail.gmail.com> <25700410-7722-4EC4-82EC-3D87E1937EEA@wanadoo.fr>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] Forget everything i said. I got this confused with a different bug. Sorry about that. Warner On Mon, Apr 8, 2024, 3:03 PM Paul Floyd <pjfloyd@wanadoo.fr> wrote: > > > On 8 Apr 2024, at 22:31, Warner Losh <imp@bsdimp.com> wrote: > > > > On Mon, Apr 8, 2024 at 9:03 PM Paul Floyd <pjfloyd@wanadoo.fr> wrote: > >> Hi >> >> I've been looking at this bugzilla item >> >> https://bugs.kde.org/show_bug.cgi?id=392146 >> >> 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’t any memory issues. > > The problem is that the opcodes aren’t 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’t 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 > > [-- Attachment #2 --] <div dir="auto">Forget everything i said. I got this confused with a different bug. Sorry about that.<div dir="auto"><br></div><div dir="auto"><br><div dir="auto">Warner</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 8, 2024, 3:03 PM Paul Floyd <<a href="mailto:pjfloyd@wanadoo.fr">pjfloyd@wanadoo.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="line-break:after-white-space"><br><div><br><blockquote type="cite"><div>On 8 Apr 2024, at 22:31, Warner Losh <<a href="mailto:imp@bsdimp.com" target="_blank" rel="noreferrer">imp@bsdimp.com</a>> wrote:</div><br><div><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 8, 2024 at 9:03 PM Paul Floyd <<a href="mailto:pjfloyd@wanadoo.fr" target="_blank" rel="noreferrer">pjfloyd@wanadoo.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="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="https://bugs.kde.org/show_bug.cgi?id=392146" rel="noreferrer noreferrer" target="_blank">https://bugs.kde.org/show_bug.cgi?id=392146</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="gmail_quote" style="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’t any memory issues.</div><div><br></div><div>The problem is that the opcodes aren’t 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’t 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></div></blockquote></div>help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfq0cT-vvw_bXmt4JDAupR8nTDd_xVa6SdGAHK_0%2Br5DAw>