On 16/12/2014 21:17, Laszlo Ersek wrote: >> > I can't imagine how that would happen; fw_cfg_data_mem_read() ignores >> > both "addr" and "size", and fw_cfg_read() simply advances the >> > "cur_offset" member. > Ah okay, I understand your point now; you're probably saying that > access_with_adjusted_size() traverses the offsets in the wrong order. > ... I don't see how; the only difference in the access() param list is > the shift count. (I don't know how it should work by design.)
I think I have figured it out. Guest endianness affects where those bytes are placed, but not the order in which they are fetched; and the effects of guest endianness are always cleaned up by adjust_endianness, so ultimately they do not matter. Think of how you would implement the uint64_t read in fw_cfg: File bytes 12 34 56 78 9a bc de f0 fw_cfg_data_mem_read should read size==4 BE host 0x12345678 size==4 LE host 0x78563412 size==8 BE host 0x123456789abcdef0 size==8 LE host 0xf0debc9a78563412 So the implementation of fw_cfg_data_mem_read must depend on host endianness. Instead, memory.c always fills in bytes in the same order, on the assumption that the reads are idempotent. Paolo
