SPU: Validate reservation in GET commands (Accurate DMA)

[elad335]

This originally striked me as I realized PPU accurate 128byte reservation mode does not work properly when there are two or more loads from the same address in the atomic loop. Why? because if one loads reads data X and the other reads data Y, if the reservation data there is X for example, meaning the data was changed twice by other thread (X ->Y ->X) the reservation store can even succeed in this case on rpcs3 although clearly the writes occured and the reservation store should fail in this case.

Now this pr doesnt fix, but it fixes a similar case in SPU side, where someone can use GET inside an atomic loop (essentialy reading the data twice as GETLLAR already read it) so add reservation validation checks there if this case is encountered.

Only affects Accurate SPU DMA as mentioned in the title.

[elad335]

Temporary storage, similar to a recent bugfix in GETLLAR which doesnt rely on LS to store constant data because its volatile.

[bevanweiss]

Is there something similar to PAGE_GUARD in the Linux/other OS world?
https://docs.microsoft.com/en-us/windows/win32/memory/creating-guard-pages

It seems like it might be an 'easier' way to detect if a write occurs to the reservation range.
The STATUS_GUARD_PAGE_VIOLATION exception could be caught (for the page containing the reservation), and checked against the reservation address range. If it's a match, then the flags for the reservation 'fault' are set, which the PUTLL.. opcodes should look at prior to performing their actions. If it's not a match, then the PAGE_GUARD is setup again.

[elad335]

memory protection is probably very slow, you can perf test if you want.

[kd-11]

I can confirm memory protection is painfully slow. It is already a major bottleneck for texture cache management, I'm horrified to think how it can impact common code execution paths.