On Wed, Feb 15, 2017 at 08:47:48PM +0100, Laszlo Ersek wrote:
> On 02/15/17 07:15, b...@skyportsystems.com wrote:
> > From: Ben Warren <b...@skyportsystems.com>
> >
> > This patch set adds support for passing a GUID to Windows guests. It
> > is a re-implementation of previous patch sets written by Igor Mammedov
> > et al, but this time passing the GUID data as a fw_cfg blob.
> >
> > This patch set has dependencies on new guest functionality, in
> > particular the support for a new linker-loader command and the ability
> > to write back data to QEMU over a DMA link. Work is in flight in both
> > SeaBIOS and OVMF to support this.
> >
> > v5->v6:
> > - Rebased to top of tree.
> > - Changed device from sysbus to a simple device. This removed the need
> > for
> > adding dynamic sysbus support to pc_piix boards.
> > - Removed patch that introduced QWORD patching of AML.
> > - Removed ability to set GUID via QMP/HMP.
> > - Improved comments/documentation in code.
>
> So here's my testing with a RHEL-7 guest:
>
> (1) The command line option passed to QEMU is
>
> -device vmgenid,guid=00112233-4455-6677-8899-AABBCCDDEEFF
>
> This is the example GUID provided in the SMBIOS spec v3.0.0 (DSP0134),
> section 7.2.1 "System -- UUID". (SMBIOS is only relevant here because it
> codifies the fact that Microsoft consumes UUID in little-endian order.)
> The expected representation, according to the SMBIOS spec, is
>
> 33 22 11 00 55 44 77 66 88 99 AA BB CC DD EE FF
>
> (2) Here's an excerpt from the OVMF log:
>
> > ProcessCmdAllocate: File="etc/vmgenid_guid" Alignment=0x1000 Zone=1
> > Size=0x1000 Address=0x7FE5C000
>
> This is where "etc/vmgenid_guid" is allocated and downloaded, the
> allocation address is 0x7FE5C000.
>
> > Select Item: 0x19
> > Select Item: 0x22
> > ProcessCmdAllocate: File="etc/acpi/tables" Alignment=0x40 Zone=1
> > Size=0x20000 Address=0x7E7AB000
> > ProcessCmdAddChecksum: File="etc/acpi/tables" ResultOffset=0x49 Start=0x40
> > Length=0x1403
> > ProcessCmdAddPointer: PointerFile="etc/acpi/tables"
> > PointeeFile="etc/acpi/tables" PointerOffset=0x1467 PointerSize=4
> > ProcessCmdAddPointer: PointerFile="etc/acpi/tables"
> > PointeeFile="etc/acpi/tables" PointerOffset=0x146B PointerSize=4
> > ProcessCmdAddChecksum: File="etc/acpi/tables" ResultOffset=0x144C
> > Start=0x1443 Length=0x74
> > ProcessCmdAddChecksum: File="etc/acpi/tables" ResultOffset=0x14C0
> > Start=0x14B7 Length=0x80
> > Select Item: 0x19
> > SaveCondensedWritePointerToS3Context: 0x002B/[0x00000000+8] := 0x7FE5C000
> > (0)
>
> This is where OVMF stashes the WRITE_POINTER command in "condensed"
> form, for S3. The fw_cfg selector value is 0x2B (for the fw_cfg file to
> be rewritten), the pointer is located at offset 0, has size 0, and the
> value to assign is 0x7FE5C000. And, this is #0 of the saved / condensed
> WRITE_POINTER commands.
>
> > Select Item: 0x2B
> > ProcessCmdWritePointer: PointerFile="etc/vmgenid_addr"
> > PointeeFile="etc/vmgenid_guid" PointerOffset=0x0 PointerSize=8
>
> This is where the WRITE_POINTER command is actually executed, during
> normal boot.
>
> > ProcessCmdAddPointer: PointerFile="etc/acpi/tables"
> > PointeeFile="etc/vmgenid_guid" PointerOffset=0x1561 PointerSize=4
>
> This is where we link "etc/vmgenid_guid" into VGIA.
>
> > ProcessCmdAddChecksum: File="etc/acpi/tables" ResultOffset=0x1540
> > Start=0x1537 Length=0xCA
> > ProcessCmdAddPointer: PointerFile="etc/acpi/tables"
> > PointeeFile="etc/acpi/tables" PointerOffset=0x1625 PointerSize=4
> > ProcessCmdAddPointer: PointerFile="etc/acpi/tables"
> > PointeeFile="etc/acpi/tables" PointerOffset=0x1629 PointerSize=4
> > ProcessCmdAddPointer: PointerFile="etc/acpi/tables"
> > PointeeFile="etc/acpi/tables" PointerOffset=0x162D PointerSize=4
> > ProcessCmdAddChecksum: File="etc/acpi/tables" ResultOffset=0x160A
> > Start=0x1601 Length=0x30
> > ProcessCmdAddPointer: PointerFile="etc/acpi/rsdp"
> > PointeeFile="etc/acpi/tables" PointerOffset=0x10 PointerSize=4
> > ProcessCmdAddChecksum: File="etc/acpi/rsdp" ResultOffset=0x8 Start=0x0
> > Length=0x24
> > InstallQemuFwCfgTables: unknown loader command: 0x0
> > InstallQemuFwCfgTables: unknown loader command: 0x0
> > InstallQemuFwCfgTables: unknown loader command: 0x0
> > InstallQemuFwCfgTables: unknown loader command: 0x0
> > InstallQemuFwCfgTables: unknown loader command: 0x0
> > InstallQemuFwCfgTables: unknown loader command: 0x0
> > InstallQemuFwCfgTables: unknown loader command: 0x0
> > InstallQemuFwCfgTables: unknown loader command: 0x0
> > InstallQemuFwCfgTables: unknown loader command: 0x0
> > InstallQemuFwCfgTables: unknown loader command: 0x0
> > InstallQemuFwCfgTables: unknown loader command: 0x0
> > InstallQemuFwCfgTables: unknown loader command: 0x0
> > InstallQemuFwCfgTables: unknown loader command: 0x0
> > InstallQemuFwCfgTables: unknown loader command: 0x0
> > InstallQemuFwCfgTables: unknown loader command: 0x0
> > Process2ndPassCmdAddPointer: checking for ACPI header in "etc/acpi/tables"
> > at 0x7E7AB000 (remaining: 0x20000): found "FACS" size 0x40
> > Process2ndPassCmdAddPointer: checking for ACPI header in "etc/acpi/tables"
> > at 0x7E7AB040 (remaining: 0x1FFC0): found "DSDT" size 0x1403
> > Process2ndPassCmdAddPointer: checking for ACPI header in "etc/vmgenid_guid"
> > at 0x7FE5C000 (remaining: 0x1000): not found; marking fw_cfg blob as opaque
>
> This is where the OVMF SDT Header Probe Suppressor does its job. (NB,
> the "opaque marking" has happened already in ProcessCmdWritePointer()
> too, above.)
>
> > Process2ndPassCmdAddPointer: checking for ACPI header in "etc/acpi/tables"
> > at 0x7E7AC443 (remaining: 0x1EBBD): found "FACP" size 0x74
> > Process2ndPassCmdAddPointer: checking for ACPI header in "etc/acpi/tables"
> > at 0x7E7AC4B7 (remaining: 0x1EB49): found "APIC" size 0x80
> > Process2ndPassCmdAddPointer: checking for ACPI header in "etc/acpi/tables"
> > at 0x7E7AC537 (remaining: 0x1EAC9): found "SSDT" size 0xCA
> > Process2ndPassCmdAddPointer: checking for ACPI header in "etc/acpi/tables"
> > at 0x7E7AC601 (remaining: 0x1E9FF): found "RSDT" size 0x30
> > TransferS3ContextToBootScript: boot script fragment saved,
> > ScratchBuffer=7FE4F018
>
> This is where the WRITE_POINTER commands, stashed earlier in condensed
> form, are translated to S3 Boot Script opcodes.
>
> > InstallQemuFwCfgTables: installed 5 tables
>
> Such as: FACS, DSDT, FACP, APIC, SSDT. OVMF recognizes RSDT and ignores
> it (it's handled by edk2 automatically).
>
> > InstallQemuFwCfgTables: freeing "etc/acpi/rsdp"
> > InstallQemuFwCfgTables: freeing "etc/acpi/tables"
>
> OVMF sees that the above two blobs have not been marked as "opaque" --
> they only contained ACPI tables, judged from the ADD_POINTER commands
> that pointed into them. So these two blobs are freed.
>
> Note that "etc/vmgenid_guid" is not freed.
>
> So, from the firmware log, everything looks OK.
>
> (3) I dumped the SSDT in the RHEL-7 guest:
>
> > /*
> > * Intel ACPI Component Architecture
> > * AML/ASL+ Disassembler version 20160527-64
> > * Copyright (c) 2000 - 2016 Intel Corporation
> > *
> > * Disassembling to symbolic ASL+ operators
> > *
> > * Disassembly of ssdt.dat, Wed Feb 15 19:21:11 2017
> > *
> > * Original Table Header:
> > * Signature "SSDT"
> > * Length 0x000000CA (202)
> > * Revision 0x01
> > * Checksum 0x1D
> > * OEM ID "BOCHS "
> > * OEM Table ID "VMGENID"
> > * OEM Revision 0x00000001 (1)
> > * Compiler ID "BXPC"
> > * Compiler Version 0x00000001 (1)
> > */
> > DefinitionBlock ("", "SSDT", 1, "BOCHS ", "VMGENID", 0x00000001)
> > {
> > Name (VGIA, 0x7FE5C000)
>
> Note that the value matches the value logged by the firmware in (2).
>
> > Scope (\_SB)
> > {
> > Device (VGEN)
> > {
> > Name (_HID, "QEMUVGID") // _HID: Hardware ID
> > Name (_CID, "VM_Gen_Counter") // _CID: Compatible ID
> > Name (_DDN, "VM_Gen_Counter") // _DDN: DOS Device Name
> > Method (_STA, 0, NotSerialized) // _STA: Status
> > {
> > Local0 = 0x0F
> > If (VGIA == Zero)
> > {
> > Local0 = Zero
> > }
> >
> > Return (Local0)
> > }
> >
> > Method (ADDR, 0, NotSerialized)
> > {
> > Local0 = Package (0x02) {}
> > Local0 [Zero] = (VGIA + 0x28)
> > Local0 [One] = Zero
> > Return (Local0)
> > }
> > }
> > }
> >
> > Method (\_GPE._E05, 0, NotSerialized) // _Exx: Edge-Triggered GPE
> > {
> > Notify (\_SB.VGEN, 0x80) // Status Change
> > }
> > }
>
> Looks good and matches the documentation.
>
> (4) To be sure, I checked the address against the guest dmesg, which
> contains a dump of the UEFI memory map:
>
> > [ 0.000000] efi: mem52: type=10, attr=0xf,
> > range=[0x000000007fe5a000-0x000000007fe5e000) (0MB)
>
> The page (4096 bytes) at 0x7FE5C000 falls into this range. Type=10 means
> EfiACPIMemoryNVS.
>
> (5) At this point I dumped the guest RAM with the dump-guest-memory
> monitor command, opened it with "crash", and listed it:
>
> > crash> rd -p -8 0x7FE5C000 0x40
> > 7fe5c000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > ................
> > 7fe5c010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > ................
> > 7fe5c020: 00 00 00 00 00 00 00 00 33 22 11 00 55 44 77 66
> > ........3"..UDwf
> > 7fe5c030: 88 99 aa bb cc dd ee ff 00 00 00 00 00 00 00 00
> > ................
>
> We can see that the GUID starts at 0x7FE5C000 + 0x28, and also that the
> byte-level representation matches the little endian one given in (1).
>
> This proves that the initial blob download worked fine.
>
> (6) Here I attached "gdb" to QEMU, set a breakpoint on
> vmgenid_handle_reset(), allowed the inferior process to continue
> execution.
>
> Then I suspended and resumed the guest (ACPI S3). The breakpoint was hit
> during resume:
>
> > Breakpoint 1, vmgenid_handle_reset (opaque=0x7f2bd03c36e0) at
> > .../hw/acpi/vmgenid.c:205
> > 205 VmGenIdState *vms = VMGENID(opaque);
>
> First of all, before allowing QEMU to zero out the address blob, I
> listed the address and the contents of the address blob (here exploiting
> that my host is also little endian):
>
> > (gdb) print (void*)vms->vmgenid_addr_le
> > $2 = (void *) 0x7f2bd03c37b0
>
> > (gdb) print /x *(uint64_t*)vms->vmgenid_addr_le
> > $4 = 0x7fe5c000
>
> This proves that QEMU has the right address, matching the firmware log
> from (2), and the ACPI dump from (3).
>
> (7) At this point I allowed the inferior to proceed a bit:
>
> > (gdb) n
> > 207 memset(vms->vmgenid_addr_le, 0,
> > ARRAY_SIZE(vms->vmgenid_addr_le));
> > (gdb) n
> > 208 }
>
> I verified that the blob was zeroed:
>
> > (gdb) print /x *(uint64_t*)vms->vmgenid_addr_le
> > $5 = 0x0
>
> then allowed the inferior to run free.
>
> > (gdb) cont
> > Continuing.
>
> (8) New messages appeared in the firmware log:
>
> > S3ResumeExecuteBootScript()
> > PeiS3ResumeState - 7FF92B18
> > transfer control to Standalone Boot Script Executor
> > S3BootScriptExecute:
> > TableHeader - 0x7E7A7000
> > TableHeader.Version - 0x0001
> > TableHeader.TableLength - 0x000000ED
> > ExecuteBootScript - 7E7A700D
> > EFI_BOOT_SCRIPT_MEM_WRITE_OPCODE
> > BootScriptExecuteMemoryWrite - 0x7FE4F018, 0x00000010, 0x00000000
>
> Here the ACPI S3 Boot Script, prepared in
> TransferS3ContextToBootScript() -- see (2) -- creates a DMA access
> command for fw_cfg. The DMA access command is written to pre-reserved
> memory (see "ScratchBuffer" above).
>
> > S3BootScriptWidthUint8 - 0x7FE4F018 (0x00)
> > S3BootScriptWidthUint8 - 0x7FE4F019 (0x2B)
>
> The fw_cfg selector is 0x2B. (See under (2).)
>
> > S3BootScriptWidthUint8 - 0x7FE4F01A (0x00)
> > S3BootScriptWidthUint8 - 0x7FE4F01B (0x0C)
>
> This is a combined select+skip operation.
>
> > S3BootScriptWidthUint8 - 0x7FE4F01C (0x00)
> > S3BootScriptWidthUint8 - 0x7FE4F01D (0x00)
> > S3BootScriptWidthUint8 - 0x7FE4F01E (0x00)
> > S3BootScriptWidthUint8 - 0x7FE4F01F (0x00)
>
> The skip size is 0 bytes.
>
> > S3BootScriptWidthUint8 - 0x7FE4F020 (0x00)
> > S3BootScriptWidthUint8 - 0x7FE4F021 (0x00)
> > S3BootScriptWidthUint8 - 0x7FE4F022 (0x00)
> > S3BootScriptWidthUint8 - 0x7FE4F023 (0x00)
> > S3BootScriptWidthUint8 - 0x7FE4F024 (0x00)
> > S3BootScriptWidthUint8 - 0x7FE4F025 (0x00)
> > S3BootScriptWidthUint8 - 0x7FE4F026 (0x00)
> > S3BootScriptWidthUint8 - 0x7FE4F027 (0x00)
>
> The address is irrelevant for skip, so it's just nuleld.
>
> > ExecuteBootScript - 7E7A7030
> > EFI_BOOT_SCRIPT_IO_WRITE_OPCODE
> > BootScriptExecuteIoWrite - 0x00000514, 0x00000002, 0x00000002
> > S3BootScriptWidthUint32 - 0x00000514 (0x00000000)
> > S3BootScriptWidthUint32 - 0x00000518 (0x18F0E47F)
>
> The Boot Script passes the DMA command to QEMU, by writing the address
> of the command buffer to IO ports 0x514 and 0x518, in BE byte order.
>
> > ExecuteBootScript - 7E7A704B
> > EFI_BOOT_SCRIPT_MEM_POLL_OPCODE
> > BootScriptExecuteMemPoll - 0x7FE4F018, 0x00000000FFFFFFFF,
> > 0x0000000000000000
> > S3BootScriptWidthUint32 - 0x7FE4F018
> > ExecuteBootScript - 7E7A7072
>
> This waits until the DMA command succeeds (reading back the Control
> field continuously until it reads as zero).
>
> > EFI_BOOT_SCRIPT_MEM_WRITE_OPCODE
> > BootScriptExecuteMemoryWrite - 0x7FE4F018, 0x00000018, 0x00000000
>
> This is another DMA access command for fw_cfg, prepared in the same
> pre-reserved buffer. This time
>
> > S3BootScriptWidthUint8 - 0x7FE4F018 (0x00)
> > S3BootScriptWidthUint8 - 0x7FE4F019 (0x00)
> > S3BootScriptWidthUint8 - 0x7FE4F01A (0x00)
> > S3BootScriptWidthUint8 - 0x7FE4F01B (0x10)
>
> we request a write operation,
>
> > S3BootScriptWidthUint8 - 0x7FE4F01C (0x00)
> > S3BootScriptWidthUint8 - 0x7FE4F01D (0x00)
> > S3BootScriptWidthUint8 - 0x7FE4F01E (0x00)
> > S3BootScriptWidthUint8 - 0x7FE4F01F (0x08)
>
> with a length of 8 bytes (big endian), matching the pointer size,
>
> > S3BootScriptWidthUint8 - 0x7FE4F020 (0x00)
> > S3BootScriptWidthUint8 - 0x7FE4F021 (0x00)
> > S3BootScriptWidthUint8 - 0x7FE4F022 (0x00)
> > S3BootScriptWidthUint8 - 0x7FE4F023 (0x00)
> > S3BootScriptWidthUint8 - 0x7FE4F024 (0x7F)
> > S3BootScriptWidthUint8 - 0x7FE4F025 (0xE4)
> > S3BootScriptWidthUint8 - 0x7FE4F026 (0xF0)
> > S3BootScriptWidthUint8 - 0x7FE4F027 (0x28)
>
> the data to transfer is located at 0x7FE4F028 (just below, tacked to the
> command buffer itself),
>
> > S3BootScriptWidthUint8 - 0x7FE4F028 (0x00)
> > S3BootScriptWidthUint8 - 0x7FE4F029 (0xC0)
> > S3BootScriptWidthUint8 - 0x7FE4F02A (0xE5)
> > S3BootScriptWidthUint8 - 0x7FE4F02B (0x7F)
> > S3BootScriptWidthUint8 - 0x7FE4F02C (0x00)
> > S3BootScriptWidthUint8 - 0x7FE4F02D (0x00)
> > S3BootScriptWidthUint8 - 0x7FE4F02E (0x00)
> > S3BootScriptWidthUint8 - 0x7FE4F02F (0x00)
>
> and the data to write is the original allocation address of the blob
> (0x7fe5c000).
>
> > ExecuteBootScript - 7E7A709D
> > EFI_BOOT_SCRIPT_IO_WRITE_OPCODE
> > BootScriptExecuteIoWrite - 0x00000514, 0x00000002, 0x00000002
> > S3BootScriptWidthUint32 - 0x00000514 (0x00000000)
> > S3BootScriptWidthUint32 - 0x00000518 (0x18F0E47F)
> > ExecuteBootScript - 7E7A70B8
> > EFI_BOOT_SCRIPT_MEM_POLL_OPCODE
> > BootScriptExecuteMemPoll - 0x7FE4F018, 0x00000000FFFFFFFF,
> > 0x0000000000000000
> > S3BootScriptWidthUint32 - 0x7FE4F018
> > ExecuteBootScript - 7E7A70DF
>
> Same story as above: fire off the transfer and wait until it completes.
>
> > EFI_BOOT_SCRIPT_INFORMATION_OPCODE
> > BootScriptExecuteInformation - 0x7E7A70E6
> > BootScriptInformation: DE AD BE EF
> > ExecuteBootScript - 7E7A70EA
> > S3_BOOT_SCRIPT_LIB_TERMINATE_OPCODE
> > S3BootScriptDone - Success
> > [...]
>
> The DEADBEEF informational (no-op) opcode is something that OVMF appends
> to the very end for hysterical raisins.
>
> (9) Okay, so the guest is now resumed and running, let's interrupt it in
> gdb again, and check the contents of address blob again (we know the
> address of the address blob from step (6)):
>
> > ^C
> > Program received signal SIGINT, Interrupt.
> > 0x00007f2bbf1d1ebf in ppoll () from /lib64/libc.so.6
> > (gdb) print /x *(uint64_t*)0x7f2bd03c37b0
> > $6 = 0x7fe5c000
>
> Et voila.
>
> (10) I detached gdb from QEMU, and issued the following monitor command:
>
> > $ virsh qemu-monitor-command ovmf.rhel7 --hmp 'info vm-generation-id'
> > 00112233-4455-6677-8899-aabbccddeeff
>
> (11) I also booted a Windows Server 2012 R2 guest (Q35, broadcast SMI
> enabled) with a similar vmgenid device/parameter. According to Device
> Manager | System devices, "Microsoft Hyper-V Generation Counter" is
> working properly.
>
> I also tested S3 briefly, it worked okay. (I mentioned the SMI broadcast
> above because for that, OVMF generates an independent S3 Boot Script
> fragment.)
>
>
> I'll let someone else test live migration.
>
> For patches #1, #3, #4 and #5:
>
> Tested-by: Laszlo Ersek <ler...@redhat.com>
>
> I'll soon post the OVMF patches.
>
> Thanks!
> Laszlo
How do you feel about Igor's request to change WRITE_POINTER to add
offset in there, so guest can pass in the address of GUID and
not start of table? Would that be a lot of work to add?
--
MST
