hypervisor: 0.836
architecture: 0.699
semantic: 0.521
device: 0.491
register: 0.390
arm: 0.389
performance: 0.369
debug: 0.344
assembly: 0.282
graphic: 0.233
network: 0.207
x86: 0.185
virtual: 0.160
user-level: 0.156
kernel: 0.136
mistranslation: 0.133
i386: 0.120
ppc: 0.103
peripherals: 0.083
socket: 0.065
KVM: 0.060
risc-v: 0.056
vnc: 0.056
permissions: 0.052
boot: 0.050
PID: 0.042
VMM: 0.039
TCG: 0.030
files: 0.014

AArch64: ISV is set to 1 in ESR_EL2 when taking a data abort with post-indexed instructions
Description of problem:
I think that I have a Qemu bug in my hands, but, I could still be missing something. Consider the following instruction:
`0x0000000000000000:  C3 44 00 B8    str   w3, [x6], #4`

notice the last #4, I think this is what we would call a post-indexed instruction (falls into the category of instructions with writeback). As I understand it, those instructions should not have ISV=1 in ESR_EL2 when faulting.

Here is the relevant part of the manual:

```
For other faults reported in ESR_EL2, ISV is 0 except for the following stage 2 aborts:
• AArch64 loads and stores of a single general-purpose register (including the register specified with 0b11111, including those with Acquire/Release semantics, but excluding Load Exclusive or Store Exclusive and excluding those with writeback).
```

However, I can see that Qemu sets ISV to 1 here. The ARM hardware that I tested gave me a value of ISV=0 for similar instructions.

Another example of instruction: `0x00000000000002f8:  01 1C 40 38    ldrb  w1, [x0, #1]!`
Steps to reproduce:
1. Run some hypervisor in EL2
2. Create a guest running at EL1 that executes one of the mentioned instructions (and make the instruction fault by writing to some unmapped page in SLP)
3. Observe the value of ESR_EL2 on data abort

Unfortunately, I cannot provide an image to reproduce this (the software is not open-source). But, I would be happy to help test a patch.