On Fri, Oct 13, 2017 at 03:53:26PM +0800, Haozhong Zhang wrote: > On 10/12/17 17:45 +0200, Paolo Bonzini wrote: > > On 12/10/2017 14:45, Haozhong Zhang wrote: > > > Basically, QEMU builds two ROMs for guest, /rom@etc/acpi/tables and > > > /rom@etc/table-loader. The former is unstructured to guest, and > > > contains all data of guest ACPI. The latter is a BIOSLinkerLoader > > > organized as a set of commands, which direct the guest (e.g., SeaBIOS > > > on KVM/QEMU) to relocate data in the former file, recalculate checksum > > > of specified area, and fill guest address in specified ACPI field. > > > > > > One part of my patches is to implement a mechanism to tell Xen which > > > part of ACPI data is a table (NFIT), and which part defines a > > > namespace device and what the device name is. I can add two new loader > > > commands for them respectively. > > > > > > Because they just provide information and SeaBIOS in non-xen > > > environment ignores unrecognized commands, they will not break SeaBIOS > > > in non-xen environment. > > > > > > On QEMU side, most Xen-specific hacks in ACPI builder could be > > > dropped, and replaced by adding the new loader commands (though they > > > may be used only by Xen). > > > > > > On Xen side, a fw_cfg driver and a BIOSLinkerLoader command executor > > > are needed in, perhaps, hvmloader. > > > > If Xen has to parse BIOSLinkerLoader, it can use the existing commands > > to process a reduced set of ACPI tables. In other words, > > etc/acpi/tables would only include the NFIT, the SSDT with namespace > > devices, and the XSDT. etc/acpi/rsdp would include the RSDP table as usual. > > > > hvmloader can then: > > > > 1) allocate some memory for where the XSDT will go > > > > 2) process the BIOSLinkerLoader like SeaBIOS would do > > > > 3) find the RSDP in low memory, since the loader script must have placed > > it there. If it cannot find it, allocate some low memory, fill it with > > the RSDP header and revision, and and jump to step 6 > > > > 4) If it found QEMU's RSDP, use it to find QEMU's XSDT > > > > 5) Copy ACPI table pointers from QEMU to hvmloader's RSDT and/or XSDT. > > > > 6) build hvmloader tables and link them into the RSDT and/or XSDT as usual. > > > > 7) overwrite the RSDP in low memory with a pointer to hvmloader's own > > RSDT and/or XSDT, and updated the checksums > > > > QEMU's XSDT remains there somewhere in memory, unused but harmless. > > > > It can work for plan tables which do not contain AML. > > However, for a namespace device, Xen needs to know its name in order > to detect the potential name conflict with those used in Xen built > ACPI. Xen does not (and is not going to) introduce an AML parser, so > it cannot get those device names from QEMU built ACPI by its own. > > The idea of either this patch series or the new BIOSLinkerLoader > command is to let QEMU tell Xen where the definition body of a > namespace device (i.e. that part within the outmost "Device(NAME)") is > and what the device name is. Xen, after the name conflict check, can > re-package the definition body in a namespace device (w/ minimal AML > builder code added in Xen) and then in SSDT. > > > Haozhong
You most likely can do this without a new command. You can use something similiar to build_append_named_dword in combination with BIOS_LINKER_LOADER_COMMAND_ADD_POINTER like vm gen id does. -- MST
