On Thu, Mar 31, 2022 at 2:36 PM Palmer Dabbelt <pal...@dabbelt.com> wrote: > > On Wed, 30 Mar 2022 20:23:21 PDT (-0700), alistai...@gmail.com wrote: > > On Thu, Mar 31, 2022 at 3:11 AM Idan Horowitz <idan.horow...@gmail.com> > > wrote: > >> > >> On Wed, 30 Mar 2022 at 19:11, Palmer Dabbelt <pal...@dabbelt.com> wrote: > >> > > >> > > >> > Presumably you mean "revert" here? That might be the right way to go, > >> > just to avoid breaking users (even if we fix the kernel bug, it'll take > >> > a while to get everyone to update). That said, this smells like the > >> > sort of thing that's going to crop up at arbitrary times in dynamic > >> > systems so while a revert looks like it'd work around the boot issue we > >> > might be making more headaches for folks down the road. > >> > > >> > >> The opposite in fact, I did not suggest to revert it, but rather undo > >> the revert (as Alistair already removed it from the apply-next tree), > >> since my original patch fixes buggy behaviour that is blocking the > >> testing of some embedded software on QEMU. > > Ah, sorry -- the QEMU tree I was looking at still had the patch in > there, must have just been an old one. > > > So, this is a little tricky. > > > > We want to apply the fix, but that will break current users. > > > > Once the fix is merged into Linux we can apply it here. That should > > hopefully be right at the start of the 7.1 QEMU development window, > > which should give time for the fix to propagate into stable kernels > > and not break too many people by the time QEMU is released. > > If you think this is a Linux bug then that makes sense, but I think this > is a QEMU bug -- I sent a patch, not sure if it went through as it didn't > make it to lore.
Ah whoops. I saw the patch but didn't read it, then I assumed it was a Linux bug from your diff earlier. > > I also think the bug will manifest without the TB exit patch, maybe in > single-step mode and definately if we happen to exit the TB at that > point for other reasons. Assuming my reasoning is correct in that > patch, we may also be hitting this as arbitrary corruption anywhere. > I'd started to write up a "QEMU errata" Linux patch for this, but then > convinced myself that just adding the sfence.vma was insufficient. Yeah, looking at it now I agree, I'll send a PR for 7.0. Alistair
