On Fri, 1 Mar 2019 14:49:45 +0100 Laszlo Ersek <ler...@redhat.com> wrote:
> On 02/28/19 15:02, Shameerali Kolothum Thodi wrote: > > > Ah..I missed the fact that, firmware indeed sees an update in the blob len > > here > > (rounded or not) after reboot. So don’t think x86 has the same issue and > > padding > > is not the right solution as Igor explained in his reply. > > > > I will try to debug this further. Any pointers welcome. > > How about this. > > (1) The firmware looks up the fw_cfg file called "etc/table-loader" in > the fw_cfg file directory (identified by constant selector key 0x0019, > FW_CFG_FILE_DIR). > > (2) The directory entry, once found, tells the firmware two things > simultaneously. The selector key, and the size of the blob. > > (3) The firmware selects the selector key from step (2). > > (4) QEMU regenerates the ACPI payload (as a select callback). > > (5) The firmware reads the number of bytes from the fw_cfg blob that it > learned in step (2). > > Here's the problem. As long as QEMU used to perform step (4) only for > the purpose of refreshing PCI resources in the ACPI payload, step (4) > wouldn't *resize* the blob. > > However, if step (4) enlarges the blob, then the byte count that step > (5) uses -- from step (2) -- for reading, is obsolete. I've thought that was a problem with IO based fw_cfg, as reading size/content were separates steps and that it was solved by DMA based fw_cfg file read. > > Thanks > Laszlo
