Le tiistaina 28. marraskuuta 2023, 16.21.55 EET Michael Niedermayer a écrit : > On Tue, Nov 28, 2023 at 09:27:08AM +0200, Rémi Denis-Courmont wrote: > > Le 28 novembre 2023 01:22:14 GMT+02:00, Michael Niedermayer <mich...@niedermayer.cc> a écrit : > > >On Mon, Nov 27, 2023 at 05:46:40PM +0200, Rémi Denis-Courmont wrote: > > >[...] > > > > > >> Also FWIW, RV broke due to misaligned accesses and illegal vector types > > >> that QEMU tolerated. That is rather an argument against QEMU than > > >> against this MR but still. > > > > > >has someone reported this to qemu ? > > >(seems like a bug) > > > > It's not a bug. The specification leaves those cases *undefined*. QEMU > > supports them because they can, and adding sanity checks would just slow > > stuff down. > > > > Also generally QEMU TCG policy seems to be maximize perf and > > compatibility, not formal correctness. > I think i read somewhere that recent qemu supposedly checks alignment on arm > more completely. But i couldnt quickly find a official statement about that
As of 8.2.0-rc2, it most definitely does not: ----8<---- static inline void gen_check_sp_alignment(DisasContext *s) { /* The AArch64 architecture mandates that (if enabled via PSTATE * or SCTLR bits) there is a check that SP is 16-aligned on every * SP-relative load or store (with an exception generated if it is not). * In line with general QEMU practice regarding misaligned accesses, * we omit these checks for the sake of guest program performance. * This function is provided as a hook so we can more easily add these * checks in future (possibly as a "favour catching guest program bugs * over speed" user selectable option). */ } ---->8---- And this is an actual violation of the specification. In the RISC-V case, QEMU is not even violating the specification, just making a different choice than the only one currently commercially available hardware implementation. > But either way, qemu could emit such code optionally when it is used for > testing. Which is one of the things people use qemu for. That would be very true for system mode "soft-MMU" QEMU, but much more questionable for user mode. In any case, I don't make their policies. > So IMHO it would make sense for qemu to detect cases that are undefined > even if for no other reason than to emulate the hw more exactly. I would agree that optional flags would be sensible. But TBH, we don't even yet know how the IPs from other vendors than Alibaba/T-Head will behave. > If this is not done, qemu can be detected and code could refuse or > fail to run -- レミ・デニ-クールモン http://www.remlab.net/ _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".