qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Virtual Machine Generation ID


From: Ben Warren
Subject: Re: [Qemu-devel] Virtual Machine Generation ID
Date: Tue, 6 Dec 2016 18:15:34 -0800

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”

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?
> - 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

Attachment: smime.p7s
Description: S/MIME cryptographic signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]