Re: [Qemu-devel] Virtual Machine Generation ID

[Igor Mammedov]

On Sat, 14 Jan 2017 22:17:53 -0800
Ben Warren <address@hidden> wrote:

> 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.
post here a link to your current repo so I could check it

> 
> thanks,
> Ben