On 12/31/14 18:58, Laszlo Ersek wrote: > On 12/31/14 18:44, Peter Maydell wrote: >> On 31 December 2014 at 17:17, Peter Maydell <peter.mayd...@linaro.org> wrote: >>> Unpatched QEMU + QEMU_EFI.fd.v4 : doesn't boot (doesn't load kernel) >>> Patched QEMU + QEMU_EFI.fd.v4_noswizzle : boots OK (dracut-initqueue >>> starts downloading things). >> >> Just noticed you asked for the full matrix of tests: >> patched QEMU + fd.v4 : doesn't boot (doesn't load kernel) >> unpatched + noswizzle : boots OK >> >> That's a bit confusing... > > It's not confusing. When you run unpatched qemu *on a big endian host*, > that's identical to what the patched code does *on a big endian host*. > > The full matrix actually has 8 elements (3 dimensions with 2 values per > dimension) -- host endianness, patched qemu vs. unpatched qemu, and > swizzling vs. non-swizzling firmware.
To elaborate a bit more (I hope I can manage after several glasses of wine): The central idea is that the firmware should not swizzle directly in the transport code. It should only swizzle dependent on the individual integer encodings in the payload for a given key. QEMU's read accessor should build the host-endian representation of the big-endian interpretation of the fw_cfg *(sub)string*. This is what the patch does. The matrix is (guest endianness is invariably LE): qemu firmware swizzles host boots patched (== firmware is buggy) endianness ------- ---------------------- ---------- ------------------------- 0 0 BE yes (your test #4) 0 0 LE no (tested right now) 0 1 BE no (your test #1) 0 1 LE yes (my earliest test) 1 0 BE yes (your test #2) 1 0 LE yes (my test for this p.) 1 1 BE no (your test #3) 1 1 LE no (tested right now) Thanks Laszlo
