Re: [Qemu-devel] Virtual Machine Generation ID

["Michael S. Tsirkin" <mst@redhat.com>]

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 <mst@redhat.com> 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 <mst@redhat.com> 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:
> —————
> [root@playground ~]# 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