On Wed, 8 Feb 2017 12:17:54 +0100 Laszlo Ersek <ler...@redhat.com> wrote:
> On 02/08/17 12:04, Igor Mammedov wrote: > > On Wed, 8 Feb 2017 01:48:42 +0100 > > Laszlo Ersek <ler...@redhat.com> wrote: > > [snip] > > >> (2) Structure of the vmgenid fw_cfg blob, AKA "why that darn offset 40 > >> decimal". > >> > >> I explained it under points (6) and (7) in the following message: > >> > >> Message-Id: <c16a03d5-820a-f719-81ea-43858f903...@redhat.com> > >> URL: https://www.mail-archive.com/qemu-devel@nongnu.org/msg425226.html > >> > >> The story is that *wherever* an ADD_POINTER command points to -- that > >> is, at the *exact* target address --, OVMF will look for an ACPI table > >> header, somewhat heuristically. If it finds a byte pattern that (a) fits > >> into the remaining blob and (b) passes some superficial ACPI table > >> header checks, such as length and checksum, then OVMF assumes that the > >> blob contains an ACPI table there, and passes the address (again, the > >> exact, relocated, absolute target address of ADD_POINTER) to > >> EFI_ACPI_TABLE_PROTOCOL.InstallAcpiTable(). > >> > >> We want to disable this heuristic for the vmgenid blob. *If* the blob > >> contained only 16 bytes (for the GUID), then the heuristic would > >> automatically disable itself, because the ACPI table header (36 bytes) > >> is larger than 16 bytes, so OVMF wouldn't even look. However, for the > >> caching and other VMGENID requirements, we need to allocate a full page > >> with the blob (4KB), hence OVMF *will* look. If we placed the GUID right > >> at the start of the page, then OVMF would sanity-check it as an ACPI > >> table header. The check would *most likely* not pass, so things would be > >> fine in practice, but we can do better than that: just put 40 zero bytes > >> at the front of the blob. > >> > >> And this is why the ADD_POINTER command has to point to the beginning of > >> the blob (i.e., 36 zero bytes), to "suppress the OVMF ACPI SDT header > >> detection". (The other 4 bytes are for arriving at an address divisible > >> by 8, which is a VMGENID requirement for the GUID.) > > that's deserves a comment in code/doc as it's non obvious to someone > > who is not familiar with OVMF. > > It is mentioned in the document "docs/specs/vmgenid.txt", added in patch 3. > > I didn't want to push for more details there, but if you think it's > helpful or even required, then Ben should please simply add a > > Rationale for padding at the front (OVMF SDT Header probe suppressor) > --------------------------------------------------------------------- > > subsection under the > > GUID Storage Format > ------------------- > > section, and just dump the above into it. > > Maybe tone down the over-use of *bold*. :) + comment/reference to doc in the code where this 'suppressor' is used, otherwise it would be easy to forget why pointer points to the blob start instead of directly to GUID. > > Thanks! > Laszlo > >
