)]}'
{
  "commit": "0b57e287138728f72d88b06e69b970c5d745c44a",
  "tree": "184f71f67f19e111e5ee97eea6f4fd131e92d4d1",
  "parents": [
    "bbdd2ad0814ea0911076419ea21b7957505cf1cc"
  ],
  "author": {
    "name": "David Gibson",
    "email": "david@gibson.dropbear.id.au",
    "time": "Mon Sep 10 12:30:57 2012 +1000"
  },
  "committer": {
    "name": "Anthony Liguori",
    "email": "aliguori@us.ibm.com",
    "time": "Mon Sep 17 10:18:48 2012 -0500"
  },
  "message": "cpu_physical_memory_write_rom() needs to do TB invalidates\n\ncpu_physical_memory_write_rom(), despite the name, can also be used to\nwrite images into RAM - and will often be used that way if the machine\nuses load_image_targphys() into RAM addresses.\n\nHowever, cpu_physical_memory_write_rom(), unlike cpu_physical_memory_rw()\ndoesn\u0027t invalidate any cached TBs which might be affected by the region\nwritten.\n\nThis was breaking reset (under full emu) on the pseries machine - we loaded\nour firmware image into RAM, and while executing it rewrite the code at\nthe entry point (correctly causing a TB invalidate/refresh).  When we\nreset the firmware image was reloaded, but the TB from the rewrite was\nstill active and caused us to get an illegal instruction trap.\n\nThis patch fixes the bug by duplicating the tb invalidate code from\ncpu_physical_memory_rw() in cpu_physical_memory_write_rom().\n\nSigned-off-by: David Gibson \u003cdavid@gibson.dropbear.id.au\u003e\nSigned-off-by: Anthony Liguori \u003caliguori@us.ibm.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "c0fbd5b149fd01929410e970b3e8f4a9b9b9700c",
      "old_mode": 33188,
      "old_path": "exec.c",
      "new_id": "f22e9e69519177fa50de3a966b35f8c8faa4a7d0",
      "new_mode": 33188,
      "new_path": "exec.c"
    }
  ]
}