From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45841) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cTUp7-0007yt-4b for qemu-devel@nongnu.org; Tue, 17 Jan 2017 09:33:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cTUp4-0006Tw-0w for qemu-devel@nongnu.org; Tue, 17 Jan 2017 09:33:21 -0500 Received: from mx1.redhat.com ([209.132.183.28]:33640) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cTUp3-0006TQ-P8 for qemu-devel@nongnu.org; Tue, 17 Jan 2017 09:33:17 -0500 Date: Tue, 17 Jan 2017 16:33:15 +0200 From: "Michael S. Tsirkin" Message-ID: <20170117163002-mutt-send-email-mst@kernel.org> References: <20160916033402-mutt-send-email-mst@kernel.org> <20161006041949-mutt-send-email-mst@kernel.org> <20161211052355-mutt-send-email-mst@kernel.org> <20170116161857-mutt-send-email-mst@kernel.org> <85C3D50B-7AFD-41E7-AD1B-634A42D04BB2@skyportsystems.com> <20170117142650.2a2a351f@nial.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] Virtual Machine Generation ID List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ed Swierk Cc: Igor Mammedov , Ben Warren , Laszlo Ersek , qemu-devel@nongnu.org Because this relies on guest to run code to read out the new fw cfg. Thus guest can not reliably detect that host didn't update the gen id - new one might be there in fw cfg but not yet read. RSDP never changes during guest lifetime so the issue does not occur. On Tue, Jan 17, 2017 at 06:26:57AM -0800, Ed Swierk wrote: > Why is using fw_cfg for vmgenid preferable to the approach used for > RSDP: call acpi_add_rom_blob() to allocate a MemoryRegion with the > initial vmgenid guid, and call acpi_ram_update() with the new guid > whenever the host needs to change it? >=20 > --Ed >=20 >=20 > On Tue, Jan 17, 2017 at 5:26 AM, Igor Mammedov wr= ote: > > On Mon, 16 Jan 2017 10:57:42 -0800 > > Ben Warren wrote: > > > >> > On Jan 16, 2017, at 6:21 AM, Michael S. Tsirkin w= rote: > >> > > >> > 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 wrote: > >> >> > >> >> On Tue, Dec 06, 2016 at 06:15:34PM -0800, Ben Warren wrote: > >> >> > >> >> Hi Michael, > >> >> > >> >> I=E2=80=99m well on my way to implementing this, but I am = really new to the > >> >> QEMU code base and am struggling with some concepts. Plea= se see below: > >> >> > >> >> On Oct 5, 2016, at 6:29 PM, Michael S. Tsirkin > >> >> wrote: > >> >> > >> >> On Tue, Oct 04, 2016 at 03:51:40PM -0700, Ed Swierk wr= ote: > >> >> > >> >> On Thu, Sep 15, 2016 at 5:36 PM, Michael S. Tsirki= n < > >> >> mst@redhat.com> wrote: > >> >> > >> >> On Thu, Sep 15, 2016 at 05:23:28PM -0700, Ed S= wierk wrote: > >> >> > >> >> I'm wondering what it will take to finish = up work on > >> >> vmgenid. > >> >> > >> >> https://lists.gnu.org/archive/html/qemu-de= vel/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 blo= bs" 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 ACP= I, device > >> >> properties, etc. In particular ACPI is still a tot= al 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 comman= d above > >> >> to pass the address of a blob allocated for it to host > >> >> > >> >> I don=E2=80=99t really understand the meaning of =E2=80=9C= file=E2=80=9D 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 v= isible in > >> >> either the host or guest file system. Is this about right= ? In my code > >> >> I=E2=80=99m using =E2=80=9C/etc/vmgenid=E2=80=9D > >> >> > >> >> > >> >> yes > >> >> > >> >> > >> >> As for the blob, I=E2=80=99m thinking this is where my mai= n problem is. The > >> >> =E2=80=98fw_cfg_add_*()=E2=80=99 functions take a data poi= nter but doesn=E2=80=99t 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 r= egion. I > >> >> don=E2=80=99t get how to define the blob contents. There = are command-line > >> >> =E2=80=98fw-cfg=E2=80=99 options where you can specify a f= ile, but it=E2=80=99s not clear to me > >> >> how to use them. Maybe I reserve some IO memory or someth= ing? > >> >> > >> >> > >> >> Not sure I understand the question. fw cfg device will make > >> >> memory accessible to guest. Put the guest physical address the= re. > >> >> the address needs to be calculated by linker. > >> >> > >> >> > >> >> I=E2=80=99m almost ready to submit a V2 of the patch set, but the= re=E2=80=99s still one issue > >> >> that I can=E2=80=99t 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 gues= t does not > >> >> see the changes. Is there something I need to do on the QEMU sid= e to =E2=80=9Cpush=E2=80=9D > >> >> the updated fw_cfg contents to the guest? I=E2=80=99ve noticed t= his both when writing > >> >> a qtest for the feature, and also in a Linux kernel module I wrot= e 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 > >> > > >> I=E2=80=99ve tried with your patch "fw-cfg-support-writeable-blobs=E2= =80=9D, setting the =E2=80=98read-only=E2=80=99 flag on my blob to false: > >> > >> fw_cfg_add_file_callback(s, VMGENID_FW_CFG_FILE, NULL, NULL, vms->gu= id.data, sizeof(vms->guid.data), false); > >> > >> and it doesn=E2=80=99t seem to make a difference. > >> > >> I think we have a misunderstanding here. I=E2=80=99m storing the VM= Generation ID __data__ (a GUID) in a fw_cfg blob, not the address. I=E2= =80=99ll submit the patch set ASAP so you will understand. > > there should be another fw_cfg file for address so > > that guest would be able to write it back into QEMU > > > >> > >> > -- > >> > MST > >> > >> regards, > >> Ben > >> > >