Re: [Qemu-devel] Virtual Machine Generation ID

[Michael S. Tsirkin]

On Sat, Jan 14, 2017 at 10:17:53PM -0800, Ben Warren 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.
> 
> thanks,
> Ben

fw cfg entities are assumed to be immutable. This week
I'll merge support for writeable fw cfg entries.
I don't see why you want to change fw cfg transparently
though - I think it should be like this
- guest writes GPA into fw cfg
- qemu writes gen id at this GPA

-- 
MST