bug fix for softmmu slow_st unaligned access

For example, the memory address 0x10008000 is on an unwritable page.When the instruction "add dword ptr [0x10007FFF],0x12345678" is executed,the OS will set 0x10008000 page be a writable page and re-execute this instruction. But softmmu has modifed the value of 0x10007FFF,so after re-executing this instruction, the final result is wrong(double-added on 0x10007FFF). Reversing the stored byte order can fix this bug.

softmmu.patch:

*** qemu.orig/softmmu_template.h Sun Oct 28 11:15:52 2007
--- qemu/softmmu_template.h Sun Oct 28 11:22:24 2007
*************** static void glue(glue(slow_st, SUFFIX), *** 282,288 ****

          } else if (((addr & ~TARGET_PAGE_MASK) + DATA_SIZE - 1) >=
TARGET_PAGE_SIZE) {
          do_unaligned_access:
              /* XXX: not efficient, but simple */

! for(i = 0;i < DATA_SIZE; i++) {
#ifdef TARGET_WORDS_BIGENDIAN
glue(slow_stb, MMUSUFFIX)(addr + i, val >> (((DATA_SIZE -
1) * 8) - (i * 8)),

                                            mmu_idx, retaddr);
--- 282,288 ----
          } else if (((addr & ~TARGET_PAGE_MASK) + DATA_SIZE - 1) >=
TARGET_PAGE_SIZE) {
          do_unaligned_access:
              /* XXX: not efficient, but simple */

! for(i = DATA_SIZE-1;i >= 0; i--) {
#ifdef TARGET_WORDS_BIGENDIAN
glue(slow_stb, MMUSUFFIX)(addr + i, val >> (((DATA_SIZE -
1) * 8) - (i * 8)),

                                            mmu_idx, retaddr);

http://www.nabble.com/file/p13449885/softmmu.patch softmmu.patch

View this message in context: http://www.nabble.com/-PATCH-bug-fix-for-softmmu-slow_st-unaligned-access-tf4705397.html#a13449885
Sent from the QEMU - Dev mailing list archive at Nabble.com.

Hi,

I'm not sure I understand, but what happens if now the 10008000 page is writable and 10007fff isn't, thus the OS needs to make it writable and re-execute? I guess reversing the accesses order is not a solution?

Regards,
Andrew

If the 0x10008000 page is writable and 0x10007FFF isn't, softmmu can raise this exception before modifing 0x10007FFF-0x10008002 because softmmu checks 0x10007FFF at first. I don't know if reversing the order is an exact solution,but its simple and working.

btw, I found this bug because I found the some windows dll reloc offset are calculated incorrectly by the guest OS. If you need a sample, I can give it to you.

View this message in context: http://www.nabble.com/-PATCH-bug-fix-for-softmmu-slow_st-unaligned-access-tf4705397.html#a13502111
Sent from the QEMU - Dev mailing list archive at Nabble.com.

Hi,

Assuming that DATA_SIZE is less than page size, I think it is okay for a workaround, I committed it. It shows that permissions are checked two times for the first byte (0x10007ffff) but maybe that's okay since this is a slow access anyway.
Regards