7 ms·

So in this specific case, if I understood correctly, here’s what should happen: Interrupt(?) fires to trigger hypervisor, hypervisor figures out what it needs

by MBCook 10d ago

So in this specific case, if I understood correctly, here’s what should happen: Interrupt(?) fires to trigger hypervisor, hypervisor figures out what it needs to do, jumps to that code, does its job, returns. The “figured out what it needs to do” is the issue right? So what was actually happening was: Same start… CPU predicts what hypervisor will do, speculatively loads instructions from mispredicted branch target, that wrong instruction reads memory(?) against the “no data prefetch” settings for that part of memory, CPU blows up/halts/whatever. The fix is to mark the area the branch was mispredicted to in such a way that the CPU won’t prefetch instructions. Thus that won’t be run and prefetch data, thus no violation. CPU execution continues taking the correct branch and everything is fine.

sleirsgoevy 9d ago
No, that instruction does not read memory. That instruction is itself IN the inaccessible memory. It does not really matter how execution ended up in the HV in the first place. The misprediction happens due to having a branch-to-register instruction.
- MBCook 9d ago
  Ah, thanks. So instruction loads also count as data loads?
  - zephen 9d ago
    Well, that was the whole issue. After marking the memory as not accessible via a data load, the CPU was still executing there and borking itself. He had to also mark the memory as inaccessible for code loads. Which, honestly is kinda stupid. Because nobody asked the processor to start executing there. It just took it upon itself to try to start executing there, later decided that was a bad thing, and then borked itself. People talk about how terrible x86 is, but honestly, one of the reasons that x86 won for decades was because of making things that programmers did that might be suboptimal still work, even if a bit slowly (misaligned data accesses, for example). ARM does that now for that specific case, but didn't before 2002. So there's an implementation tradeoff for whether you decide to spend transistors to reduce the number of sharp edges on the tool. Obviously ARM just doesn't give a shit about this particular sharp edge.

by MBCook 10d ago

sleirsgoevy 9d ago

No, that instruction does not read memory. That instruction is itself IN the inaccessible memory. It does not really matter how execution ended up in the HV in the first place. The misprediction happens due to having a branch-to-register instruction.

MBCook 9d ago
Ah, thanks. So instruction loads also count as data loads?
- zephen 9d ago
  Well, that was the whole issue. After marking the memory as not accessible via a data load, the CPU was still executing there and borking itself. He had to also mark the memory as inaccessible for code loads. Which, honestly is kinda stupid. Because nobody asked the processor to start executing there. It just took it upon itself to try to start executing there, later decided that was a bad thing, and then borked itself. People talk about how terrible x86 is, but honestly, one of the reasons that x86 won for decades was because of making things that programmers did that might be suboptimal still work, even if a bit slowly (misaligned data accesses, for example). ARM does that now for that specific case, but didn't before 2002. So there's an implementation tradeoff for whether you decide to spend transistors to reduce the number of sharp edges on the tool. Obviously ARM just doesn't give a shit about this particular sharp edge.