On 4/25/19 10:29 AM, Li Qiang wrote: > > > Gerd Hoffmann <kra...@redhat.com <mailto:kra...@redhat.com>> 于2019年4月 > 25日周四 下午4:15写道： > > On Wed, Apr 24, 2019 at 09:16:56AM +0800, Li Qiang wrote: > > Thomas Huth <th...@redhat.com <mailto:th...@redhat.com>> 于2019年4 > 月24日周三 上午12:29写道： > > > > > Is this endianess-safe? Or do you need to byteswap > reboot_timeout if the > > > host and guest endianess does not match? > > > > Good question! > > > > IIUC, the qemu fw_cfg store the 'file' entry data just in byte stream. > > No. Integers are defined to be little endian. See fw_cfg_add_i64() for > example, there is an explicit cpu_to_le64() call for that. > > > > Yes, for the fw_cfg 'integer' entry it is stored as little endian. > But for the fw_cfg 'file' entry interpred as an integer, there is no > specify the endianess.
I agree with Li, the endianess of 'reboot-timeout' is not clear. >From docs/specs/fw_cfg.txt: === All Other Data Items === Please consult the QEMU source for the most up-to-date and authoritative list of selector keys and their respective items' purpose, format and writeability. So checking the git history, this code was introduced in commit ac05f3492421, very similar to commit 3d3b8303c6f8 for the 'boot-menu-wait' entry, which explicitely use little-endian, so I think it is safe to consider it little-endian and add a comment about its endianess (referring the previous commits in the patch description). Thanks, Phil. > > Thanks, > Li Qiang > > > > cheers, > Gerd >
