[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Virtual Machine Generation ID
From: |
Michael S. Tsirkin |
Subject: |
Re: [Qemu-devel] Virtual Machine Generation ID |
Date: |
Mon, 16 Jan 2017 16:21:58 +0200 |
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
- Re: [Qemu-devel] Virtual Machine Generation ID, Ben Warren, 2017/01/15
- Re: [Qemu-devel] Virtual Machine Generation ID, Igor Mammedov, 2017/01/16
- Re: [Qemu-devel] Virtual Machine Generation ID,
Michael S. Tsirkin <=
- Re: [Qemu-devel] Virtual Machine Generation ID, Ben Warren, 2017/01/16
- Re: [Qemu-devel] Virtual Machine Generation ID, Igor Mammedov, 2017/01/17
- Re: [Qemu-devel] Virtual Machine Generation ID, Ed Swierk, 2017/01/17
- Re: [Qemu-devel] Virtual Machine Generation ID, Michael S. Tsirkin, 2017/01/17
- Re: [Qemu-devel] Virtual Machine Generation ID, Ed Swierk, 2017/01/17
- Re: [Qemu-devel] Virtual Machine Generation ID, Michael S. Tsirkin, 2017/01/17
- Re: [Qemu-devel] Virtual Machine Generation ID, Ben Warren, 2017/01/17
- Re: [Qemu-devel] Virtual Machine Generation ID, Igor Mammedov, 2017/01/17
- Re: [Qemu-devel] Virtual Machine Generation ID, Michael S. Tsirkin, 2017/01/17
- Re: [Qemu-devel] Virtual Machine Generation ID, Michael S. Tsirkin, 2017/01/17