[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-arm] [RFC PATCH 0/4] ARM virt: ACPI memory hotplug support
From: |
Igor Mammedov |
Subject: |
Re: [Qemu-arm] [RFC PATCH 0/4] ARM virt: ACPI memory hotplug support |
Date: |
Fri, 1 Mar 2019 18:39:24 +0100 |
On Fri, 1 Mar 2019 14:49:45 +0100
Laszlo Ersek <address@hidden> 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