Re: [Qemu-devel] Virtual Machine Generation ID

[Ben Warren]

Hi Michael,

> On Dec 10, 2016, at 7:28 PM, Michael S. Tsirkin <address@hidden> wrote:
> 
> 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.
> 
I’m almost ready to submit a V2 of the patch set, but there’s still one issue 
that I can’t figure out.  From the guest, I can read the contents of the blob.  
If I make a change to the contents of the blob (via QMP) the guest does not see 
the changes.  Is there something I need to do on the QEMU side to “push” the 
updated fw_cfg contents to the guest?  I’ve noticed this both when writing a 
qtest for the feature, and also in a Linux kernel module I wrote that reads the 
ACPI contents in a guest.

thanks,
Ben

smime.p7s
Description: S/MIME cryptographic signature