Re: [Qemu-devel] Virtual Machine Generation ID

[Michael S. Tsirkin]

On Tue, Dec 06, 2016 at 06:15:34PM -0800, Ben Warren wrote:
> Hi Michael,
> 
> I’m well on my way to implementing this, but I am really new to the QEMU code 
> base and am struggling with some concepts.  Please see below:
> > On Oct 5, 2016, at 6:29 PM, Michael S. Tsirkin <address@hidden> wrote:
> > 
> > On Tue, Oct 04, 2016 at 03:51:40PM -0700, Ed Swierk wrote:
> >> On Thu, Sep 15, 2016 at 5:36 PM, Michael S. Tsirkin <address@hidden> wrote:
> >>> On Thu, Sep 15, 2016 at 05:23:28PM -0700, Ed Swierk wrote:
> >>>> I'm wondering what it will take to finish up work on vmgenid.
> >>>> 
> >>>> https://lists.gnu.org/archive/html/qemu-devel/2016-01/msg05599.html
> >>> 
> >>> We have ACPI_BUILD_TPMLOG_FILE in tree now and I think it could be
> >>> allocated in a similar way.
> >>> Integrate patch "fw-cfg: support writeable blobs" to communicate the
> >>> allocated address back to QEMU.
> >> 
> >> Starting with Igor's last version at
> >> https://github.com/imammedo/qemu/commits/vmgen_wip , it's not clear to
> >> me which changes need to be ported, which changes are obsoleted by
> >> your new fw-cfg stuff and/or upstream churn in ACPI, device
> >> properties, etc. In particular ACPI is still a total mystery to me,
> >> though passing a single address from guest to host can't be that hard,
> >> can it?
> >> 
> >> Any clues would be appreciated.
> >> 
> >> --Ed
> > 
> > It might be best to just re-start from the beginning.
> > So the idea is that ACPI should be about supplying the address
> > to guest. To supply address to host we'll use fw cfg.
> > This would be new I think:
> > 
> > - add support for writeable fw cfg blobs
> patch applied
> > - add linker/loader command to write address of a blob into
> >  such a fw cfg file
> > - add a new file used for vm gen id, use loader command above
> >  to pass the address of a blob allocated for it to host
> I don’t really understand the meaning of “file” in this context.  It seems to 
> be a way of specifying individual fw_cfg entries without explicitly giving an 
> index, but is not something that is visible in either the host or guest file 
> system.  Is this about right?  In my code I’m using “/etc/vmgenid”

yes

> As for the blob, I’m thinking this is where my main problem is.  The 
> ‘fw_cfg_add_*()’ functions take a data pointer but doesn’t seem to copy the 
> data anywhere.  We pass essentially a pointer via ACPI to the guest, so what 
> it points to needs to be in an accessible region.  I don’t get how to define 
> the blob contents.  There are command-line ‘fw-cfg’ options where you can 
> specify a file, but it’s not clear to me how to use them.  Maybe I reserve 
> some IO memory or something?

Not sure I understand the question. fw cfg device will make
memory accessible to guest. Put the guest physical address there.
the address needs to be calculated by linker.



> > - whenever vm gen id changes, update file, if we have address
> >  of blob update that as well
> Will do that once I understand the other parts
> > - use linker to patch address of blob into acpi as well
> >  it needs to be in a separate ssdt at top level
> >  otherwise it's hard to figure out the offset.
> I have this going into a separate SSDT and can decode it using iasl on the 
> guest:
> —————
> address@hidden ~]# cat SSDT.dsl 
> /*
>  * Intel ACPI Component Architecture
>  * AML/ASL+ Disassembler version 20150717-64
>  * Copyright (c) 2000 - 2015 Intel Corporation
>  * 
>  * Disassembling to symbolic ASL+ operators
>  *
>  * Disassembly of SSDT, Tue Dec  6 16:35:14 2016
>  *
>  * Original Table Header:
>  *     Signature        "SSDT"
>  *     Length           0x0000007C (124)
>  *     Revision         0x01
>  *     Checksum         0x29
>  *     OEM ID           "BOCHS "
>  *     OEM Table ID     "VMGENID"
>  *     OEM Revision     0x00000001 (1)
>  *     Compiler ID      "BXPC"
>  *     Compiler Version 0x00000001 (1)
>  */
> DefinitionBlock ("SSDT.aml", "SSDT", 1, "BOCHS ", "VMGENID", 0x00000001)
> {
>     Scope (_SB)
>     {
>         Device (VGEN)
>         {
>             Name (_HID, "QEMU0003")  // _HID: Hardware ID
>             Name (_CID, "VM_Gen_Counter")  // _CID: Compatible ID
>             Name (_DDN, "VM_Gen_Counter")  // _DDN: DOS Device Name
>             Name (ADDR, Package (0x02)
>             {
>                 0xE7AAD010, 
>                 0x559F
>             })
>         }
>     }
> }
> —————
> The address you see is the address of the host memory where I have the GUID 
> stored, so is obviously incorrect.
> 
> > 
> > This can be reused from one of the previus versions:
> > - command line, interrupts and commands to update vm gen id
> > 
> I have these all applied and can set/get the GUID via the QMP shell, and can 
> pass GUID via QEMU command line.  As for parsing the input, I have it modeled 
> as a device right on the sysbus.  Is this how it should be done, or would I 
> pass the GUID in via the ‘fw_cfg’ command-line options, or something else?  
> It’s a bit problematic as-is because it depends on machine types that allow 
> dynamic-sysbus.
> > I can help with acpi if all the rest is clear.
> > 
> 
> 
> > -- 
> > MST
> > 
> > 
> Sorry for being so dense - I think once I get the main concepts the rest of 
> this should be straightforward.  I’m happy to post a patch of the current 
> work if that would help.  Thanks in advance for your help.
> 
> —Ben