[{"id":1782717,"web_url":"http://patchwork.ozlabs.org/comment/1782717/","msgid":"<20171009110336.GA17824@redhat.com>","list_archive_url":null,"date":"2017-10-09T11:03:36","subject":"Re: [Qemu-devel] [PATCH v6 2/7] hw/misc: add vmcoreinfo device","submitter":{"id":2694,"url":"http://patchwork.ozlabs.org/api/people/2694/","name":"Daniel P. Berrangé","email":"berrange@redhat.com"},"content":"On Mon, Sep 11, 2017 at 06:59:24PM +0200, Marc-André Lureau wrote:\n> See docs/specs/vmcoreinfo.txt for details.\n> \n> \"etc/vmcoreinfo\" fw_cfg entry is added when using \"-device vmcoreinfo\".\n\nI'm wondering if you considered just adding the entry to fw_cfg by\ndefault, without requiring any -device arg ? Unless I'm misunderstanding,\nthis doesn't feel like a device to me - its just a well known bucket\nin fw_cfg IIUC ? Obviously its existance would need to be tied to\nthe latest machine type for ABI reasons though. The benefit of this\nis that it would \"just work\" without us having to plumb it through to\nall the downstream applications that use QEMU for mgmt guest (OpenStack,\noVirt, GNOME Boxes, virt-manager, and countless other mgmt apps).\n\nRegards,\nDaniel","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","ext-mx09.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx09.extmail.prod.ext.phx2.redhat.com;\n\tspf=fail smtp.mailfrom=berrange@redhat.com"],"Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3y9cnk6PH1z9tY0\n\tfor ;\n\tMon, 9 Oct 2017 22:04:25 +1100 (AEDT)","from localhost ([::1]:57136 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1e1VrB-0003k5-7m\n\tfor incoming@patchwork.ozlabs.org; Mon, 09 Oct 2017 07:04:21 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:53354)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1e1Vqf-0003jy-KA\n\tfor qemu-devel@nongnu.org; Mon, 09 Oct 2017 07:03:55 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1e1Vqb-00049F-Kl\n\tfor qemu-devel@nongnu.org; Mon, 09 Oct 2017 07:03:49 -0400","from mx1.redhat.com ([209.132.183.28]:33756)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from ) id 1e1Vqb-000494-E2\n\tfor qemu-devel@nongnu.org; Mon, 09 Oct 2017 07:03:45 -0400","from smtp.corp.redhat.com\n\t(int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby mx1.redhat.com (Postfix) with ESMTPS id 493524A6E6\n\tfor ; Mon, 9 Oct 2017 11:03:44 +0000 (UTC)","from redhat.com (unknown [10.42.22.189])\n\tby smtp.corp.redhat.com (Postfix) with ESMTPS id CA028709A5;\n\tMon, 9 Oct 2017 11:03:38 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com 493524A6E6","Date":"Mon, 9 Oct 2017 12:03:36 +0100","From":"\"Daniel P. Berrange\" ","To":"=?utf-8?q?Marc-Andr=C3=A9?= Lureau ","Message-ID":"<20171009110336.GA17824@redhat.com>","References":"<20170911165929.2791-1-marcandre.lureau@redhat.com>\n\t<20170911165929.2791-3-marcandre.lureau@redhat.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","In-Reply-To":"<20170911165929.2791-3-marcandre.lureau@redhat.com>","User-Agent":"Mutt/1.9.0 (2017-09-02)","X-Scanned-By":"MIMEDefang 2.79 on 10.5.11.13","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.38]);\n\tMon, 09 Oct 2017 11:03:44 +0000 (UTC)","Content-Transfer-Encoding":"quoted-printable","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]\n\t[fuzzy]","X-Received-From":"209.132.183.28","Subject":"Re: [Qemu-devel] [PATCH v6 2/7] hw/misc: add vmcoreinfo device","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Reply-To":"\"Daniel P. Berrange\" ","Cc":"ehabkost@redhat.com, mst@redhat.com, qemu-devel@nongnu.org,\n\tanderson@redhat.com, imammedo@redhat.com, lersek@redhat.com","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1782739,"web_url":"http://patchwork.ozlabs.org/comment/1782739/","msgid":"<319200616.27902916.1507549590199.JavaMail.zimbra@redhat.com>","list_archive_url":null,"date":"2017-10-09T11:46:30","subject":"Re: [Qemu-devel] [PATCH v6 2/7] hw/misc: add vmcoreinfo device","submitter":{"id":66774,"url":"http://patchwork.ozlabs.org/api/people/66774/","name":"Marc-André Lureau","email":"marcandre.lureau@redhat.com"},"content":"Hi\n\n----- Original Message -----\n> On Mon, Sep 11, 2017 at 06:59:24PM +0200, Marc-André Lureau wrote:\n> > See docs/specs/vmcoreinfo.txt for details.\n> > \n> > \"etc/vmcoreinfo\" fw_cfg entry is added when using \"-device vmcoreinfo\".\n> \n> I'm wondering if you considered just adding the entry to fw_cfg by\n> default, without requiring any -device arg ? Unless I'm misunderstanding,\n> this doesn't feel like a device to me - its just a well known bucket\n> in fw_cfg IIUC ? Obviously its existance would need to be tied to\n> the latest machine type for ABI reasons though. The benefit of this\n> is that it would \"just work\" without us having to plumb it through to\n> all the downstream applications that use QEMU for mgmt guest (OpenStack,\n> oVirt, GNOME Boxes, virt-manager, and countless other mgmt apps).\n\nv5 did that, it was using a -global fw_cfg.vmcoreinfo=on that defaulted to on.\n\nMichael preferred to have a separate -device rather than mix it with fw_cfg, since it's not directly related.\n\nWe could make -device vmcoreinfo default on on machine type >= 2.11 instead?\n\nthanks","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","ext-mx05.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx05.extmail.prod.ext.phx2.redhat.com;\n\tspf=fail smtp.mailfrom=mlureau@redhat.com"],"Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3y9dkx5XJDz9rxj\n\tfor ;\n\tMon, 9 Oct 2017 22:47:04 +1100 (AEDT)","from localhost ([::1]:57283 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1e1WWT-0003sQ-55\n\tfor incoming@patchwork.ozlabs.org; Mon, 09 Oct 2017 07:47:01 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:34017)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1e1WW5-0003s4-Le\n\tfor qemu-devel@nongnu.org; Mon, 09 Oct 2017 07:46:38 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1e1WW2-0001Pm-Kb\n\tfor qemu-devel@nongnu.org; Mon, 09 Oct 2017 07:46:37 -0400","from mx1.redhat.com ([209.132.183.28]:48776)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from ) id 1e1WW2-0001PM-Dm\n\tfor qemu-devel@nongnu.org; Mon, 09 Oct 2017 07:46:34 -0400","from smtp.corp.redhat.com\n\t(int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby mx1.redhat.com (Postfix) with ESMTPS id 44DA1552EA\n\tfor ; Mon, 9 Oct 2017 11:46:33 +0000 (UTC)","from colo-mx.corp.redhat.com\n\t(colo-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.20])\n\tby smtp.corp.redhat.com (Postfix) with ESMTPS id AE59261547;\n\tMon, 9 Oct 2017 11:46:30 +0000 (UTC)","from zmail17.collab.prod.int.phx2.redhat.com\n\t(zmail17.collab.prod.int.phx2.redhat.com [10.5.83.19])\n\tby colo-mx.corp.redhat.com (Postfix) with ESMTP id 613D618355C5;\n\tMon, 9 Oct 2017 11:46:30 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com 44DA1552EA","Date":"Mon, 9 Oct 2017 07:46:30 -0400 (EDT)","From":"=?utf-8?q?Marc-Andr=C3=A9?= Lureau ","To":"\"Daniel P. Berrange\" ","Message-ID":"<319200616.27902916.1507549590199.JavaMail.zimbra@redhat.com>","In-Reply-To":"<20171009110336.GA17824@redhat.com>","References":"<20170911165929.2791-1-marcandre.lureau@redhat.com>\n\t<20170911165929.2791-3-marcandre.lureau@redhat.com>\n\t<20171009110336.GA17824@redhat.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Transfer-Encoding":"quoted-printable","X-Originating-IP":"[10.36.112.63, 10.4.195.18]","Thread-Topic":"hw/misc: add vmcoreinfo device","Thread-Index":"/XvrJnYSiJBZsTSzfsDg5c4B9Bvj0w==","X-Scanned-By":"MIMEDefang 2.79 on 10.5.11.15","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.29]);\n\tMon, 09 Oct 2017 11:46:33 +0000 (UTC)","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]\n\t[fuzzy]","X-Received-From":"209.132.183.28","Subject":"Re: [Qemu-devel] [PATCH v6 2/7] hw/misc: add vmcoreinfo device","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"ehabkost@redhat.com, mst@redhat.com, qemu-devel@nongnu.org,\n\tanderson@redhat.com, imammedo@redhat.com, lersek@redhat.com","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1782779,"web_url":"http://patchwork.ozlabs.org/comment/1782779/","msgid":"<20171009144344.38bbd1e9@nial.brq.redhat.com>","list_archive_url":null,"date":"2017-10-09T12:43:44","subject":"Re: [Qemu-devel] [PATCH v6 2/7] hw/misc: add vmcoreinfo device","submitter":{"id":11305,"url":"http://patchwork.ozlabs.org/api/people/11305/","name":"Igor Mammedov","email":"imammedo@redhat.com"},"content":"On Mon, 9 Oct 2017 12:03:36 +0100\n\"Daniel P. Berrange\" wrote:\n\n> On Mon, Sep 11, 2017 at 06:59:24PM +0200, Marc-André Lureau wrote:\n> > See docs/specs/vmcoreinfo.txt for details.\n> > \n> > \"etc/vmcoreinfo\" fw_cfg entry is added when using \"-device vmcoreinfo\". \n> \n> I'm wondering if you considered just adding the entry to fw_cfg by\n> default, without requiring any -device arg ? Unless I'm misunderstanding,\n> this doesn't feel like a device to me - its just a well known bucket\n> in fw_cfg IIUC ? Obviously its existance would need to be tied to\n> the latest machine type for ABI reasons though. The benefit of this\n> is that it would \"just work\" without us having to plumb it through to\n> all the downstream applications that use QEMU for mgmt guest (OpenStack,\n> oVirt, GNOME Boxes, virt-manager, and countless other mgmt apps).\nit follows model set by pvpanic device, it's easier to manage from migration\nPOV, one could use it even for old machine types with new qemu (just by adding\ndevice, it makes instance not backwards migratable to old qemu but should work\nfor forward migration) and if user doesn't need it, device could be just omitted\nfrom CLI.\n\n> \n> Regards,\n> Daniel","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","ext-mx09.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx09.extmail.prod.ext.phx2.redhat.com;\n\tspf=fail smtp.mailfrom=imammedo@redhat.com"],"Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3y9g1303s8z9t5Q\n\tfor ;\n\tMon, 9 Oct 2017 23:44:20 +1100 (AEDT)","from localhost ([::1]:57695 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1e1XPt-00073p-57\n\tfor incoming@patchwork.ozlabs.org; Mon, 09 Oct 2017 08:44:17 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:47223)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1e1XPa-00072Z-W0\n\tfor qemu-devel@nongnu.org; Mon, 09 Oct 2017 08:43:59 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1e1XPX-00026A-73\n\tfor qemu-devel@nongnu.org; Mon, 09 Oct 2017 08:43:59 -0400","from mx1.redhat.com ([209.132.183.28]:51268)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from ) id 1e1XPX-00025f-10\n\tfor qemu-devel@nongnu.org; Mon, 09 Oct 2017 08:43:55 -0400","from smtp.corp.redhat.com\n\t(int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby mx1.redhat.com (Postfix) with ESMTPS id 99C694ACA5\n\tfor ; Mon, 9 Oct 2017 12:43:53 +0000 (UTC)","from nial.brq.redhat.com (unknown [10.43.2.209])\n\tby smtp.corp.redhat.com (Postfix) with ESMTP id 84A5F61548;\n\tMon, 9 Oct 2017 12:43:45 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com 99C694ACA5","Date":"Mon, 9 Oct 2017 14:43:44 +0200","From":"Igor Mammedov ","To":"\"Daniel P. Berrange\" ","Message-ID":"<20171009144344.38bbd1e9@nial.brq.redhat.com>","In-Reply-To":"<20171009110336.GA17824@redhat.com>","References":"<20170911165929.2791-1-marcandre.lureau@redhat.com>\n\t<20170911165929.2791-3-marcandre.lureau@redhat.com>\n\t<20171009110336.GA17824@redhat.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=UTF-8","Content-Transfer-Encoding":"quoted-printable","X-Scanned-By":"MIMEDefang 2.79 on 10.5.11.15","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.38]);\n\tMon, 09 Oct 2017 12:43:53 +0000 (UTC)","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]\n\t[fuzzy]","X-Received-From":"209.132.183.28","Subject":"Re: [Qemu-devel] [PATCH v6 2/7] hw/misc: add vmcoreinfo device","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"ehabkost@redhat.com, mst@redhat.com, qemu-devel@nongnu.org,\n\tanderson@redhat.com, =?utf-8?q?Marc-Andr=C3=A9?=\n\tLureau , \tlersek@redhat.com","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1782798,"web_url":"http://patchwork.ozlabs.org/comment/1782798/","msgid":"<20171009130218.GK2954@redhat.com>","list_archive_url":null,"date":"2017-10-09T13:02:18","subject":"Re: [Qemu-devel] [PATCH v6 2/7] hw/misc: add vmcoreinfo device","submitter":{"id":2694,"url":"http://patchwork.ozlabs.org/api/people/2694/","name":"Daniel P. Berrangé","email":"berrange@redhat.com"},"content":"On Mon, Oct 09, 2017 at 02:43:44PM +0200, Igor Mammedov wrote:\n> On Mon, 9 Oct 2017 12:03:36 +0100\n> \"Daniel P. Berrange\" wrote:\n> \n> > On Mon, Sep 11, 2017 at 06:59:24PM +0200, Marc-André Lureau wrote:\n> > > See docs/specs/vmcoreinfo.txt for details.\n> > > \n> > > \"etc/vmcoreinfo\" fw_cfg entry is added when using \"-device vmcoreinfo\". \n> > \n> > I'm wondering if you considered just adding the entry to fw_cfg by\n> > default, without requiring any -device arg ? Unless I'm misunderstanding,\n> > this doesn't feel like a device to me - its just a well known bucket\n> > in fw_cfg IIUC ? Obviously its existance would need to be tied to\n> > the latest machine type for ABI reasons though. The benefit of this\n> > is that it would \"just work\" without us having to plumb it through to\n> > all the downstream applications that use QEMU for mgmt guest (OpenStack,\n> > oVirt, GNOME Boxes, virt-manager, and countless other mgmt apps).\n> it follows model set by pvpanic device, it's easier to manage from migration\n> POV, one could use it even for old machine types with new qemu (just by adding\n> device, it makes instance not backwards migratable to old qemu but should work\n> for forward migration) and if user doesn't need it, device could be just omitted\n> from CLI.\n\nSure but it means that in effect no one will have this functionality enabled\nfor several years. pvpanic has been around a long time and I rarely see it\npresent in configured guests :-(\n\n\nRegards,\nDaniel","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","ext-mx03.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx03.extmail.prod.ext.phx2.redhat.com;\n\tspf=fail smtp.mailfrom=berrange@redhat.com"],"Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3y9gTW120Wz9tXc\n\tfor ;\n\tTue, 10 Oct 2017 00:05:35 +1100 (AEDT)","from localhost ([::1]:57795 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1e1XkT-0006MO-9J\n\tfor incoming@patchwork.ozlabs.org; Mon, 09 Oct 2017 09:05:33 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:53132)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1e1Xhi-0004di-FO\n\tfor qemu-devel@nongnu.org; Mon, 09 Oct 2017 09:02:46 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1e1Xhe-0005Zh-Da\n\tfor qemu-devel@nongnu.org; Mon, 09 Oct 2017 09:02:42 -0400","from mx1.redhat.com ([209.132.183.28]:40548)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from ) id 1e1Xhe-0005Z3-7e\n\tfor qemu-devel@nongnu.org; Mon, 09 Oct 2017 09:02:38 -0400","from smtp.corp.redhat.com\n\t(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby mx1.redhat.com (Postfix) with ESMTPS id 3EDE57E430\n\tfor ; Mon, 9 Oct 2017 13:02:37 +0000 (UTC)","from redhat.com (unknown [10.42.22.189])\n\tby smtp.corp.redhat.com (Postfix) with ESMTPS id 4ECFD675C9;\n\tMon, 9 Oct 2017 13:02:21 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com 3EDE57E430","Date":"Mon, 9 Oct 2017 14:02:18 +0100","From":"\"Daniel P. Berrange\" ","To":"Igor Mammedov ","Message-ID":"<20171009130218.GK2954@redhat.com>","References":"<20170911165929.2791-1-marcandre.lureau@redhat.com>\n\t<20170911165929.2791-3-marcandre.lureau@redhat.com>\n\t<20171009110336.GA17824@redhat.com>\n\t<20171009144344.38bbd1e9@nial.brq.redhat.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","In-Reply-To":"<20171009144344.38bbd1e9@nial.brq.redhat.com>","User-Agent":"Mutt/1.9.0 (2017-09-02)","X-Scanned-By":"MIMEDefang 2.79 on 10.5.11.12","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.27]);\n\tMon, 09 Oct 2017 13:02:37 +0000 (UTC)","Content-Transfer-Encoding":"quoted-printable","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]\n\t[fuzzy]","X-Received-From":"209.132.183.28","Subject":"Re: [Qemu-devel] [PATCH v6 2/7] hw/misc: add vmcoreinfo device","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Reply-To":"\"Daniel P. Berrange\" ","Cc":"ehabkost@redhat.com, mst@redhat.com, qemu-devel@nongnu.org,\n\tanderson@redhat.com, =?utf-8?q?Marc-Andr=C3=A9?=\n\tLureau , \tlersek@redhat.com","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1783261,"web_url":"http://patchwork.ozlabs.org/comment/1783261/","msgid":"<20171010003951-mutt-send-email-mst@kernel.org>","list_archive_url":null,"date":"2017-10-09T21:44:26","subject":"Re: [Qemu-devel] [PATCH v6 2/7] hw/misc: add vmcoreinfo device","submitter":{"id":2235,"url":"http://patchwork.ozlabs.org/api/people/2235/","name":"Michael S. Tsirkin","email":"mst@redhat.com"},"content":"On Mon, Oct 09, 2017 at 02:02:18PM +0100, Daniel P. Berrange wrote:\n> On Mon, Oct 09, 2017 at 02:43:44PM +0200, Igor Mammedov wrote:\n> > On Mon, 9 Oct 2017 12:03:36 +0100\n> > \"Daniel P. Berrange\" wrote:\n> > \n> > > On Mon, Sep 11, 2017 at 06:59:24PM +0200, Marc-André Lureau wrote:\n> > > > See docs/specs/vmcoreinfo.txt for details.\n> > > > \n> > > > \"etc/vmcoreinfo\" fw_cfg entry is added when using \"-device vmcoreinfo\". \n> > > \n> > > I'm wondering if you considered just adding the entry to fw_cfg by\n> > > default, without requiring any -device arg ? Unless I'm misunderstanding,\n> > > this doesn't feel like a device to me - its just a well known bucket\n> > > in fw_cfg IIUC ? Obviously its existance would need to be tied to\n> > > the latest machine type for ABI reasons though. The benefit of this\n> > > is that it would \"just work\" without us having to plumb it through to\n> > > all the downstream applications that use QEMU for mgmt guest (OpenStack,\n> > > oVirt, GNOME Boxes, virt-manager, and countless other mgmt apps).\n> > it follows model set by pvpanic device, it's easier to manage from migration\n> > POV, one could use it even for old machine types with new qemu (just by adding\n> > device, it makes instance not backwards migratable to old qemu but should work\n> > for forward migration) and if user doesn't need it, device could be just omitted\n> > from CLI.\n> \n> Sure but it means that in effect no one will have this functionality enabled\n> for several years. pvpanic has been around a long time and I rarely see it\n> present in configured guests :-(\n> \n> \n> Regards,\n> Daniel\n\nlibvirt runs with -nodefaults, right? I'd argue pretty strongly -nodefaults\nshouldn't add optional devices anyway.\n\nSo it's up to you guys, you can add it to VMs by default if you want to.\n\n\n> -- \n> |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|\n> |: https://libvirt.org -o- https://fstop138.berrange.com :|\n> |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","ext-mx10.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx10.extmail.prod.ext.phx2.redhat.com;\n\tspf=fail smtp.mailfrom=mst@redhat.com"],"Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3y9v0t30Fbz9t5Q\n\tfor ;\n\tTue, 10 Oct 2017 08:45:01 +1100 (AEDT)","from localhost ([::1]:59925 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1e1fr7-0006mq-7U\n\tfor incoming@patchwork.ozlabs.org; Mon, 09 Oct 2017 17:44:57 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:38181)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1e1fqm-0006mZ-1z\n\tfor qemu-devel@nongnu.org; Mon, 09 Oct 2017 17:44:37 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1e1fqi-0002H6-3z\n\tfor qemu-devel@nongnu.org; Mon, 09 Oct 2017 17:44:36 -0400","from mx1.redhat.com ([209.132.183.28]:44202)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from ) id 1e1fqh-0002Gq-TQ\n\tfor qemu-devel@nongnu.org; Mon, 09 Oct 2017 17:44:32 -0400","from smtp.corp.redhat.com\n\t(int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby mx1.redhat.com (Postfix) with ESMTPS id 8A7A12576C\n\tfor ; Mon, 9 Oct 2017 21:44:30 +0000 (UTC)","from redhat.com (ovpn-124-96.rdu2.redhat.com [10.10.124.96])\n\tby smtp.corp.redhat.com (Postfix) with ESMTP id 1A4316155F;\n\tMon, 9 Oct 2017 21:44:26 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com 8A7A12576C","Date":"Tue, 10 Oct 2017 00:44:26 +0300","From":"\"Michael S. Tsirkin\" ","To":"\"Daniel P. Berrange\" ","Message-ID":"<20171010003951-mutt-send-email-mst@kernel.org>","References":"<20170911165929.2791-1-marcandre.lureau@redhat.com>\n\t<20170911165929.2791-3-marcandre.lureau@redhat.com>\n\t<20171009110336.GA17824@redhat.com>\n\t<20171009144344.38bbd1e9@nial.brq.redhat.com>\n\t<20171009130218.GK2954@redhat.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=iso-8859-1","Content-Disposition":"inline","In-Reply-To":"<20171009130218.GK2954@redhat.com>","X-Scanned-By":"MIMEDefang 2.79 on 10.5.11.15","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.39]);\n\tMon, 09 Oct 2017 21:44:30 +0000 (UTC)","Content-Transfer-Encoding":"quoted-printable","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]\n\t[fuzzy]","X-Received-From":"209.132.183.28","Subject":"Re: [Qemu-devel] [PATCH v6 2/7] hw/misc: add vmcoreinfo device","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"ehabkost@redhat.com, qemu-devel@nongnu.org, anderson@redhat.com,\n\t=?iso-8859-1?q?Marc-Andr=E9?= Lureau ,\n\tIgor Mammedov , lersek@redhat.com","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1783505,"web_url":"http://patchwork.ozlabs.org/comment/1783505/","msgid":"<20171010083143.GA30015@redhat.com>","list_archive_url":null,"date":"2017-10-10T08:31:43","subject":"Re: [Qemu-devel] [PATCH v6 2/7] hw/misc: add vmcoreinfo device","submitter":{"id":2694,"url":"http://patchwork.ozlabs.org/api/people/2694/","name":"Daniel P. Berrangé","email":"berrange@redhat.com"},"content":"On Tue, Oct 10, 2017 at 12:44:26AM +0300, Michael S. Tsirkin wrote:\n> On Mon, Oct 09, 2017 at 02:02:18PM +0100, Daniel P. Berrange wrote:\n> > On Mon, Oct 09, 2017 at 02:43:44PM +0200, Igor Mammedov wrote:\n> > > On Mon, 9 Oct 2017 12:03:36 +0100\n> > > \"Daniel P. Berrange\" wrote:\n> > > \n> > > > On Mon, Sep 11, 2017 at 06:59:24PM +0200, Marc-André Lureau wrote:\n> > > > > See docs/specs/vmcoreinfo.txt for details.\n> > > > > \n> > > > > \"etc/vmcoreinfo\" fw_cfg entry is added when using \"-device vmcoreinfo\". \n> > > > \n> > > > I'm wondering if you considered just adding the entry to fw_cfg by\n> > > > default, without requiring any -device arg ? Unless I'm misunderstanding,\n> > > > this doesn't feel like a device to me - its just a well known bucket\n> > > > in fw_cfg IIUC ? Obviously its existance would need to be tied to\n> > > > the latest machine type for ABI reasons though. The benefit of this\n> > > > is that it would \"just work\" without us having to plumb it through to\n> > > > all the downstream applications that use QEMU for mgmt guest (OpenStack,\n> > > > oVirt, GNOME Boxes, virt-manager, and countless other mgmt apps).\n> > > it follows model set by pvpanic device, it's easier to manage from migration\n> > > POV, one could use it even for old machine types with new qemu (just by adding\n> > > device, it makes instance not backwards migratable to old qemu but should work\n> > > for forward migration) and if user doesn't need it, device could be just omitted\n> > > from CLI.\n> > \n> > Sure but it means that in effect no one will have this functionality enabled\n> > for several years. pvpanic has been around a long time and I rarely see it\n> > present in configured guests :-(\n> > \n> > \n> > Regards,\n> > Daniel\n> \n> libvirt runs with -nodefaults, right? I'd argue pretty strongly -nodefaults\n> shouldn't add optional devices anyway.\n\nThis isn't really adding a device though is it - it is just a well known\nlocation in fw_cfg to receive data.\n\nRegards,\nDaniel","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","ext-mx01.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx01.extmail.prod.ext.phx2.redhat.com;\n\tspf=fail smtp.mailfrom=berrange@redhat.com"],"Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3yB9N83yJRz9tYB\n\tfor ;\n\tTue, 10 Oct 2017 19:32:40 +1100 (AEDT)","from localhost ([::1]:33486 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1e1pxu-0000qV-La\n\tfor incoming@patchwork.ozlabs.org; Tue, 10 Oct 2017 04:32:38 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:53890)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1e1pxJ-0000oY-3k\n\tfor qemu-devel@nongnu.org; Tue, 10 Oct 2017 04:32:02 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1e1pxD-0003wV-A6\n\tfor qemu-devel@nongnu.org; Tue, 10 Oct 2017 04:32:01 -0400","from mx1.redhat.com ([209.132.183.28]:53906)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from ) id 1e1pxD-0003w7-1D\n\tfor qemu-devel@nongnu.org; Tue, 10 Oct 2017 04:31:55 -0400","from smtp.corp.redhat.com\n\t(int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby mx1.redhat.com (Postfix) with ESMTPS id 1E0FD81DED\n\tfor ; Tue, 10 Oct 2017 08:31:54 +0000 (UTC)","from redhat.com (unknown [10.33.36.82])\n\tby smtp.corp.redhat.com (Postfix) with ESMTPS id 1BC0562460;\n\tTue, 10 Oct 2017 08:31:46 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com 1E0FD81DED","Date":"Tue, 10 Oct 2017 09:31:43 +0100","From":"\"Daniel P. Berrange\" ","To":"\"Michael S. Tsirkin\" ","Message-ID":"<20171010083143.GA30015@redhat.com>","References":"<20170911165929.2791-1-marcandre.lureau@redhat.com>\n\t<20170911165929.2791-3-marcandre.lureau@redhat.com>\n\t<20171009110336.GA17824@redhat.com>\n\t<20171009144344.38bbd1e9@nial.brq.redhat.com>\n\t<20171009130218.GK2954@redhat.com>\n\t<20171010003951-mutt-send-email-mst@kernel.org>","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","In-Reply-To":"<20171010003951-mutt-send-email-mst@kernel.org>","User-Agent":"Mutt/1.9.0 (2017-09-02)","X-Scanned-By":"MIMEDefang 2.79 on 10.5.11.15","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.25]);\n\tTue, 10 Oct 2017 08:31:54 +0000 (UTC)","Content-Transfer-Encoding":"quoted-printable","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]\n\t[fuzzy]","X-Received-From":"209.132.183.28","Subject":"Re: [Qemu-devel] [PATCH v6 2/7] hw/misc: add vmcoreinfo device","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Reply-To":"\"Daniel P. Berrange\" ","Cc":"ehabkost@redhat.com, qemu-devel@nongnu.org, anderson@redhat.com,\n\t=?utf-8?q?Marc-Andr=C3=A9?= Lureau ,\n\tIgor Mammedov , lersek@redhat.com","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1783813,"web_url":"http://patchwork.ozlabs.org/comment/1783813/","msgid":"","list_archive_url":null,"date":"2017-10-10T15:00:18","subject":"Re: [Qemu-devel] [PATCH v6 2/7] hw/misc: add vmcoreinfo device","submitter":{"id":6442,"url":"http://patchwork.ozlabs.org/api/people/6442/","name":"Marc-André Lureau","email":"marcandre.lureau@gmail.com"},"content":"Hi\n\nOn Tue, Oct 10, 2017 at 10:31 AM, Daniel P. Berrange\n wrote:\n> On Tue, Oct 10, 2017 at 12:44:26AM +0300, Michael S. Tsirkin wrote:\n>> On Mon, Oct 09, 2017 at 02:02:18PM +0100, Daniel P. Berrange wrote:\n>> > On Mon, Oct 09, 2017 at 02:43:44PM +0200, Igor Mammedov wrote:\n>> > > On Mon, 9 Oct 2017 12:03:36 +0100\n>> > > \"Daniel P. Berrange\" wrote:\n>> > >\n>> > > > On Mon, Sep 11, 2017 at 06:59:24PM +0200, Marc-André Lureau wrote:\n>> > > > > See docs/specs/vmcoreinfo.txt for details.\n>> > > > >\n>> > > > > \"etc/vmcoreinfo\" fw_cfg entry is added when using \"-device vmcoreinfo\".\n>> > > >\n>> > > > I'm wondering if you considered just adding the entry to fw_cfg by\n>> > > > default, without requiring any -device arg ? Unless I'm misunderstanding,\n>> > > > this doesn't feel like a device to me - its just a well known bucket\n>> > > > in fw_cfg IIUC ? Obviously its existance would need to be tied to\n>> > > > the latest machine type for ABI reasons though. The benefit of this\n>> > > > is that it would \"just work\" without us having to plumb it through to\n>> > > > all the downstream applications that use QEMU for mgmt guest (OpenStack,\n>> > > > oVirt, GNOME Boxes, virt-manager, and countless other mgmt apps).\n>> > > it follows model set by pvpanic device, it's easier to manage from migration\n>> > > POV, one could use it even for old machine types with new qemu (just by adding\n>> > > device, it makes instance not backwards migratable to old qemu but should work\n>> > > for forward migration) and if user doesn't need it, device could be just omitted\n>> > > from CLI.\n>> >\n>> > Sure but it means that in effect no one will have this functionality enabled\n>> > for several years. pvpanic has been around a long time and I rarely see it\n>> > present in configured guests :-(\n>> >\n>> >\n>> > Regards,\n>> > Daniel\n>>\n>> libvirt runs with -nodefaults, right? I'd argue pretty strongly -nodefaults\n>> shouldn't add optional devices anyway.\n>\n> This isn't really adding a device though is it - it is just a well known\n> location in fw_cfg to receive data.\n\nEnabling the device on some configurations by default can be done as a\nfollow-up patch. Can we get this series reviewed & merged?\n\nthanks","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"dLIBPL6k\"; dkim-atps=neutral"],"Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3yBL023q7Hz9tYB\n\tfor ;\n\tWed, 11 Oct 2017 02:00:50 +1100 (AEDT)","from localhost ([::1]:35505 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1e1w1Y-0007PE-EG\n\tfor incoming@patchwork.ozlabs.org; Tue, 10 Oct 2017 11:00:48 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:33641)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1e1w17-0007Or-CV\n\tfor qemu-devel@nongnu.org; Tue, 10 Oct 2017 11:00:27 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1e1w16-0004Ua-Bs\n\tfor qemu-devel@nongnu.org; Tue, 10 Oct 2017 11:00:21 -0400","from mail-oi0-x22c.google.com ([2607:f8b0:4003:c06::22c]:49775)\n\tby eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16)\n\t(Exim 4.71) (envelope-from )\n\tid 1e1w16-0004U4-72\n\tfor qemu-devel@nongnu.org; Tue, 10 Oct 2017 11:00:20 -0400","by mail-oi0-x22c.google.com with SMTP id w197so41030449oif.6\n\tfor ; Tue, 10 Oct 2017 08:00:20 -0700 (PDT)","by 10.58.33.28 with HTTP; Tue, 10 Oct 2017 08:00:18 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc:content-transfer-encoding;\n\tbh=tVd3o6zzYxJcE8tbR7+VpFm6tZ7ZwXqJeLOj5apRhTk=;\n\tb=dLIBPL6kKq77FQ2KJjG7WOFmMPxIUWFFeDbRh0x8cj1asd1NZnM1roOqa8BK928utm\n\tTp9dqHCxTlCdFPibtXVJGAC+HDYHZOINzD+xOCTLlVCT4yLm3qTRW3XEnd3DmVJoluoG\n\tdNGvqYxyWYmjpMcZaKtywA017O7sAtBEqFQeAoTHv/895hYKUXVtK1+8dVUXWnY14tk6\n\tywmC5dUJyxvL7xeH+4VSZVWsrIONV9HD/tWLuCzaRTpZTDgmnOX7mSSeEwYGG9R4uerv\n\troITn0bHCe1dVzkOjGwKlAb+0NOzueRY/e40ODVayZfu+ZbQC7e2LUgEYu3xTTAosJ1B\n\tvufw==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc:content-transfer-encoding;\n\tbh=tVd3o6zzYxJcE8tbR7+VpFm6tZ7ZwXqJeLOj5apRhTk=;\n\tb=ljHWw+I8TPuiOgdg6/Pvw2SH4tV83qqTu9RWV9BVoYbH9zdHumvlEuFGIxzxWYdfRR\n\tdAGRnZH/VSVBHPclUiEv46ptMXIwVk1IU4x8fJidIUpZ+SYudKvrkGf9oHt5AgJdk87R\n\tzDEfCKQdJ50ixhP6s+ZUq+wxgBS9M1YdbFn8G0AGIlLfhwh78vfHdbgXvR2JXEhhYi6W\n\tDmNMdWVdCMSuSNngD3i3d6T8J91jHkRCfIrERWjdMajHKMPDIZ/K2BM1QhpAuGb6T6sH\n\tPYz/hb8Cw24M1MqOwlCKrGxlI70HPbP5FgzG2Vp16iSLUhGq6dcu1+jmS8Dcre9YNqGg\n\t9ZcQ==","X-Gm-Message-State":"AMCzsaV8Kp0DrS0POGiFc1Kfr4OI3tzmkqC989X+rR1f0X3Y3ywDOrQQ\n\t58KxSrg8k3sG5o7UfAj4rNGwwSfh7LN39wBtaio=","X-Google-Smtp-Source":"AOwi7QBL2E6yS1iAg1qZ25tWjBE60C67PaJiJQ6tdoVVcxDOPrH/nCCcO2N86TB6PIB9htvL32Mx1XjmR5AZluWoRvI=","X-Received":"by 10.202.73.14 with SMTP id w14mr6459719oia.258.1507647619318; \n\tTue, 10 Oct 2017 08:00:19 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"<20171010083143.GA30015@redhat.com>","References":"<20170911165929.2791-1-marcandre.lureau@redhat.com>\n\t<20170911165929.2791-3-marcandre.lureau@redhat.com>\n\t<20171009110336.GA17824@redhat.com>\n\t<20171009144344.38bbd1e9@nial.brq.redhat.com>\n\t<20171009130218.GK2954@redhat.com>\n\t<20171010003951-mutt-send-email-mst@kernel.org>\n\t<20171010083143.GA30015@redhat.com>","From":"=?utf-8?q?Marc-Andr=C3=A9_Lureau?= ","Date":"Tue, 10 Oct 2017 17:00:18 +0200","Message-ID":"","To":"\"Daniel P. Berrange\" ","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","X-detected-operating-system":"by eggs.gnu.org: Genre and OS details not\n\trecognized.","X-Received-From":"2607:f8b0:4003:c06::22c","Subject":"Re: [Qemu-devel] [PATCH v6 2/7] hw/misc: add vmcoreinfo device","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Eduardo Habkost ,\n\t\"Michael S. Tsirkin\" , QEMU , \n\tDave Anderson ,\n\tIgor Mammedov , Laszlo Ersek ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1783814,"web_url":"http://patchwork.ozlabs.org/comment/1783814/","msgid":"<20171010180333-mutt-send-email-mst@kernel.org>","list_archive_url":null,"date":"2017-10-10T15:03:53","subject":"Re: [Qemu-devel] [PATCH v6 2/7] hw/misc: add vmcoreinfo device","submitter":{"id":2235,"url":"http://patchwork.ozlabs.org/api/people/2235/","name":"Michael S. Tsirkin","email":"mst@redhat.com"},"content":"On Tue, Oct 10, 2017 at 05:00:18PM +0200, Marc-André Lureau wrote:\n> Hi\n> \n> On Tue, Oct 10, 2017 at 10:31 AM, Daniel P. Berrange\n> wrote:\n> > On Tue, Oct 10, 2017 at 12:44:26AM +0300, Michael S. Tsirkin wrote:\n> >> On Mon, Oct 09, 2017 at 02:02:18PM +0100, Daniel P. Berrange wrote:\n> >> > On Mon, Oct 09, 2017 at 02:43:44PM +0200, Igor Mammedov wrote:\n> >> > > On Mon, 9 Oct 2017 12:03:36 +0100\n> >> > > \"Daniel P. Berrange\" wrote:\n> >> > >\n> >> > > > On Mon, Sep 11, 2017 at 06:59:24PM +0200, Marc-André Lureau wrote:\n> >> > > > > See docs/specs/vmcoreinfo.txt for details.\n> >> > > > >\n> >> > > > > \"etc/vmcoreinfo\" fw_cfg entry is added when using \"-device vmcoreinfo\".\n> >> > > >\n> >> > > > I'm wondering if you considered just adding the entry to fw_cfg by\n> >> > > > default, without requiring any -device arg ? Unless I'm misunderstanding,\n> >> > > > this doesn't feel like a device to me - its just a well known bucket\n> >> > > > in fw_cfg IIUC ? Obviously its existance would need to be tied to\n> >> > > > the latest machine type for ABI reasons though. The benefit of this\n> >> > > > is that it would \"just work\" without us having to plumb it through to\n> >> > > > all the downstream applications that use QEMU for mgmt guest (OpenStack,\n> >> > > > oVirt, GNOME Boxes, virt-manager, and countless other mgmt apps).\n> >> > > it follows model set by pvpanic device, it's easier to manage from migration\n> >> > > POV, one could use it even for old machine types with new qemu (just by adding\n> >> > > device, it makes instance not backwards migratable to old qemu but should work\n> >> > > for forward migration) and if user doesn't need it, device could be just omitted\n> >> > > from CLI.\n> >> >\n> >> > Sure but it means that in effect no one will have this functionality enabled\n> >> > for several years. pvpanic has been around a long time and I rarely see it\n> >> > present in configured guests :-(\n> >> >\n> >> >\n> >> > Regards,\n> >> > Daniel\n> >>\n> >> libvirt runs with -nodefaults, right? I'd argue pretty strongly -nodefaults\n> >> shouldn't add optional devices anyway.\n> >\n> > This isn't really adding a device though is it - it is just a well known\n> > location in fw_cfg to receive data.\n> \n> Enabling the device on some configurations by default can be done as a\n> follow-up patch. Can we get this series reviewed & merged?\n> \n> thanks\n\nI plan to merge this in the next pull request.\n\n> -- \n> Marc-André Lureau","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","ext-mx02.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx02.extmail.prod.ext.phx2.redhat.com;\n\tspf=fail smtp.mailfrom=mst@redhat.com"],"Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3yBL4G1z9Lz9tYK\n\tfor ;\n\tWed, 11 Oct 2017 02:04:29 +1100 (AEDT)","from localhost ([::1]:35515 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1e1w54-0000Zv-A4\n\tfor incoming@patchwork.ozlabs.org; Tue, 10 Oct 2017 11:04:26 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:34961)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1e1w4g-0000ZT-H7\n\tfor qemu-devel@nongnu.org; Tue, 10 Oct 2017 11:04:08 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1e1w4a-0006pj-LL\n\tfor qemu-devel@nongnu.org; Tue, 10 Oct 2017 11:04:02 -0400","from mx1.redhat.com ([209.132.183.28]:32082)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from ) id 1e1w4a-0006pW-DA\n\tfor qemu-devel@nongnu.org; Tue, 10 Oct 2017 11:03:56 -0400","from smtp.corp.redhat.com\n\t(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby mx1.redhat.com (Postfix) with ESMTPS id 6879F820F9;\n\tTue, 10 Oct 2017 15:03:55 +0000 (UTC)","from redhat.com (ovpn-124-102.rdu2.redhat.com [10.10.124.102])\n\tby smtp.corp.redhat.com (Postfix) with ESMTP id 0281469542;\n\tTue, 10 Oct 2017 15:03:53 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com 6879F820F9","Date":"Tue, 10 Oct 2017 18:03:53 +0300","From":"\"Michael S. Tsirkin\" ","To":"=?iso-8859-1?q?Marc-Andr=E9?= Lureau ","Message-ID":"<20171010180333-mutt-send-email-mst@kernel.org>","References":"<20170911165929.2791-1-marcandre.lureau@redhat.com>\n\t<20170911165929.2791-3-marcandre.lureau@redhat.com>\n\t<20171009110336.GA17824@redhat.com>\n\t<20171009144344.38bbd1e9@nial.brq.redhat.com>\n\t<20171009130218.GK2954@redhat.com>\n\t<20171010003951-mutt-send-email-mst@kernel.org>\n\t<20171010083143.GA30015@redhat.com>\n\t","MIME-Version":"1.0","Content-Type":"text/plain; charset=iso-8859-1","Content-Disposition":"inline","In-Reply-To":"","X-Scanned-By":"MIMEDefang 2.79 on 10.5.11.12","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.26]);\n\tTue, 10 Oct 2017 15:03:55 +0000 (UTC)","Content-Transfer-Encoding":"quoted-printable","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]\n\t[fuzzy]","X-Received-From":"209.132.183.28","Subject":"Re: [Qemu-devel] [PATCH v6 2/7] hw/misc: add vmcoreinfo device","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Eduardo Habkost , QEMU ,\n\tDave Anderson ,\n\tIgor Mammedov , Laszlo Ersek ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1783817,"web_url":"http://patchwork.ozlabs.org/comment/1783817/","msgid":"<20171010150628.GI30015@redhat.com>","list_archive_url":null,"date":"2017-10-10T15:06:28","subject":"Re: [Qemu-devel] [PATCH v6 2/7] hw/misc: add vmcoreinfo device","submitter":{"id":2694,"url":"http://patchwork.ozlabs.org/api/people/2694/","name":"Daniel P. Berrangé","email":"berrange@redhat.com"},"content":"On Tue, Oct 10, 2017 at 05:00:18PM +0200, Marc-André Lureau wrote:\n> Hi\n> \n> On Tue, Oct 10, 2017 at 10:31 AM, Daniel P. Berrange\n> wrote:\n> > On Tue, Oct 10, 2017 at 12:44:26AM +0300, Michael S. Tsirkin wrote:\n> >> On Mon, Oct 09, 2017 at 02:02:18PM +0100, Daniel P. Berrange wrote:\n> >> > On Mon, Oct 09, 2017 at 02:43:44PM +0200, Igor Mammedov wrote:\n> >> > > On Mon, 9 Oct 2017 12:03:36 +0100\n> >> > > \"Daniel P. Berrange\" wrote:\n> >> > >\n> >> > > > On Mon, Sep 11, 2017 at 06:59:24PM +0200, Marc-André Lureau wrote:\n> >> > > > > See docs/specs/vmcoreinfo.txt for details.\n> >> > > > >\n> >> > > > > \"etc/vmcoreinfo\" fw_cfg entry is added when using \"-device vmcoreinfo\".\n> >> > > >\n> >> > > > I'm wondering if you considered just adding the entry to fw_cfg by\n> >> > > > default, without requiring any -device arg ? Unless I'm misunderstanding,\n> >> > > > this doesn't feel like a device to me - its just a well known bucket\n> >> > > > in fw_cfg IIUC ? Obviously its existance would need to be tied to\n> >> > > > the latest machine type for ABI reasons though. The benefit of this\n> >> > > > is that it would \"just work\" without us having to plumb it through to\n> >> > > > all the downstream applications that use QEMU for mgmt guest (OpenStack,\n> >> > > > oVirt, GNOME Boxes, virt-manager, and countless other mgmt apps).\n> >> > > it follows model set by pvpanic device, it's easier to manage from migration\n> >> > > POV, one could use it even for old machine types with new qemu (just by adding\n> >> > > device, it makes instance not backwards migratable to old qemu but should work\n> >> > > for forward migration) and if user doesn't need it, device could be just omitted\n> >> > > from CLI.\n> >> >\n> >> > Sure but it means that in effect no one will have this functionality enabled\n> >> > for several years. pvpanic has been around a long time and I rarely see it\n> >> > present in configured guests :-(\n> >> >\n> >> >\n> >> > Regards,\n> >> > Daniel\n> >>\n> >> libvirt runs with -nodefaults, right? I'd argue pretty strongly -nodefaults\n> >> shouldn't add optional devices anyway.\n> >\n> > This isn't really adding a device though is it - it is just a well known\n> > location in fw_cfg to receive data.\n> \n> Enabling the device on some configurations by default can be done as a\n> follow-up patch. Can we get this series reviewed & merged?\n\nThe problem with the -device approach + turning it on by default is that there\nis no way to turn it off again if you don't want it. eg there's way to undo\nan implicit '-device foo' except via -nodefaults, but since libvirt uses that\nalready it would negate the effect of enabling it by default unconditionally.\n\nYour previous approach of \"-global fw_cfg.vmcoreinfo=on\" is nicer in this\nrespect, as you can trivially turn it on/off, overriding the default state\nin both directions.\n\nRegards,\nDaniel","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","ext-mx02.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx02.extmail.prod.ext.phx2.redhat.com;\n\tspf=fail smtp.mailfrom=berrange@redhat.com"],"Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3yBL7T6lYSz9tYM\n\tfor ;\n\tWed, 11 Oct 2017 02:07:17 +1100 (AEDT)","from localhost ([::1]:35527 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1e1w7n-0001QP-Ov\n\tfor incoming@patchwork.ozlabs.org; Tue, 10 Oct 2017 11:07:15 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:35792)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1e1w7I-0001QA-6O\n\tfor qemu-devel@nongnu.org; Tue, 10 Oct 2017 11:06:48 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1e1w7B-0008Fd-P0\n\tfor qemu-devel@nongnu.org; Tue, 10 Oct 2017 11:06:44 -0400","from mx1.redhat.com ([209.132.183.28]:43496)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from ) id 1e1w7B-0008FM-FO\n\tfor qemu-devel@nongnu.org; Tue, 10 Oct 2017 11:06:37 -0400","from smtp.corp.redhat.com\n\t(int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby mx1.redhat.com (Postfix) with ESMTPS id 8E59F883D9;\n\tTue, 10 Oct 2017 15:06:36 +0000 (UTC)","from redhat.com (unknown [10.33.36.82])\n\tby smtp.corp.redhat.com (Postfix) with ESMTPS id BD4976249F;\n\tTue, 10 Oct 2017 15:06:31 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com 8E59F883D9","Date":"Tue, 10 Oct 2017 16:06:28 +0100","From":"\"Daniel P. Berrange\" ","To":"=?utf-8?q?Marc-Andr=C3=A9?= Lureau ","Message-ID":"<20171010150628.GI30015@redhat.com>","References":"<20170911165929.2791-1-marcandre.lureau@redhat.com>\n\t<20170911165929.2791-3-marcandre.lureau@redhat.com>\n\t<20171009110336.GA17824@redhat.com>\n\t<20171009144344.38bbd1e9@nial.brq.redhat.com>\n\t<20171009130218.GK2954@redhat.com>\n\t<20171010003951-mutt-send-email-mst@kernel.org>\n\t<20171010083143.GA30015@redhat.com>\n\t","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","In-Reply-To":"","User-Agent":"Mutt/1.9.0 (2017-09-02)","X-Scanned-By":"MIMEDefang 2.79 on 10.5.11.15","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.26]);\n\tTue, 10 Oct 2017 15:06:36 +0000 (UTC)","Content-Transfer-Encoding":"quoted-printable","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]\n\t[fuzzy]","X-Received-From":"209.132.183.28","Subject":"Re: [Qemu-devel] [PATCH v6 2/7] hw/misc: add vmcoreinfo device","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Reply-To":"\"Daniel P. Berrange\" ","Cc":"Eduardo Habkost ,\n\t\"Michael S. Tsirkin\" , QEMU , \n\tDave Anderson ,\n\tIgor Mammedov , Laszlo Ersek ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1783829,"web_url":"http://patchwork.ozlabs.org/comment/1783829/","msgid":"<20171010181646-mutt-send-email-mst@kernel.org>","list_archive_url":null,"date":"2017-10-10T15:21:00","subject":"Re: [Qemu-devel] [PATCH v6 2/7] hw/misc: add vmcoreinfo device","submitter":{"id":2235,"url":"http://patchwork.ozlabs.org/api/people/2235/","name":"Michael S. Tsirkin","email":"mst@redhat.com"},"content":"On Tue, Oct 10, 2017 at 04:06:28PM +0100, Daniel P. Berrange wrote:\n> On Tue, Oct 10, 2017 at 05:00:18PM +0200, Marc-André Lureau wrote:\n> > Hi\n> > \n> > On Tue, Oct 10, 2017 at 10:31 AM, Daniel P. Berrange\n> > wrote:\n> > > On Tue, Oct 10, 2017 at 12:44:26AM +0300, Michael S. Tsirkin wrote:\n> > >> On Mon, Oct 09, 2017 at 02:02:18PM +0100, Daniel P. Berrange wrote:\n> > >> > On Mon, Oct 09, 2017 at 02:43:44PM +0200, Igor Mammedov wrote:\n> > >> > > On Mon, 9 Oct 2017 12:03:36 +0100\n> > >> > > \"Daniel P. Berrange\" wrote:\n> > >> > >\n> > >> > > > On Mon, Sep 11, 2017 at 06:59:24PM +0200, Marc-André Lureau wrote:\n> > >> > > > > See docs/specs/vmcoreinfo.txt for details.\n> > >> > > > >\n> > >> > > > > \"etc/vmcoreinfo\" fw_cfg entry is added when using \"-device vmcoreinfo\".\n> > >> > > >\n> > >> > > > I'm wondering if you considered just adding the entry to fw_cfg by\n> > >> > > > default, without requiring any -device arg ? Unless I'm misunderstanding,\n> > >> > > > this doesn't feel like a device to me - its just a well known bucket\n> > >> > > > in fw_cfg IIUC ? Obviously its existance would need to be tied to\n> > >> > > > the latest machine type for ABI reasons though. The benefit of this\n> > >> > > > is that it would \"just work\" without us having to plumb it through to\n> > >> > > > all the downstream applications that use QEMU for mgmt guest (OpenStack,\n> > >> > > > oVirt, GNOME Boxes, virt-manager, and countless other mgmt apps).\n> > >> > > it follows model set by pvpanic device, it's easier to manage from migration\n> > >> > > POV, one could use it even for old machine types with new qemu (just by adding\n> > >> > > device, it makes instance not backwards migratable to old qemu but should work\n> > >> > > for forward migration) and if user doesn't need it, device could be just omitted\n> > >> > > from CLI.\n> > >> >\n> > >> > Sure but it means that in effect no one will have this functionality enabled\n> > >> > for several years. pvpanic has been around a long time and I rarely see it\n> > >> > present in configured guests :-(\n> > >> >\n> > >> >\n> > >> > Regards,\n> > >> > Daniel\n> > >>\n> > >> libvirt runs with -nodefaults, right? I'd argue pretty strongly -nodefaults\n> > >> shouldn't add optional devices anyway.\n> > >\n> > > This isn't really adding a device though is it - it is just a well known\n> > > location in fw_cfg to receive data.\n> > \n> > Enabling the device on some configurations by default can be done as a\n> > follow-up patch. Can we get this series reviewed & merged?\n> \n> The problem with the -device approach + turning it on by default is that there\n> is no way to turn it off again if you don't want it. eg there's way to undo\n> an implicit '-device foo' except via -nodefaults, but since libvirt uses that\n> already it would negate the effect of enabling it by default unconditionally.\n> \n> Your previous approach of \"-global fw_cfg.vmcoreinfo=on\" is nicer in this\n> respect, as you can trivially turn it on/off, overriding the default state\n> in both directions.\n> \n> Regards,\n> Daniel\n\n\nInteresting. IIUC you are saying that a property can have on/off/auto\noptions, while -device only has on/off.\n\nSeems like something that's worth looking into generally. I'm not sure\nwhy is should this device be special though.\n\n> -- \n> |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|\n> |: https://libvirt.org -o- https://fstop138.berrange.com :|\n> |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","ext-mx09.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx09.extmail.prod.ext.phx2.redhat.com;\n\tspf=fail smtp.mailfrom=mst@redhat.com"],"Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3yBLSD3r10z9ryQ\n\tfor ;\n\tWed, 11 Oct 2017 02:21:47 +1100 (AEDT)","from localhost ([::1]:35600 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1e1wLp-0000bi-D6\n\tfor incoming@patchwork.ozlabs.org; Tue, 10 Oct 2017 11:21:45 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:40269)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1e1wLG-0000Yx-MM\n\tfor qemu-devel@nongnu.org; Tue, 10 Oct 2017 11:21:14 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1e1wLA-00088R-Nn\n\tfor qemu-devel@nongnu.org; Tue, 10 Oct 2017 11:21:10 -0400","from mx1.redhat.com ([209.132.183.28]:32902)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from ) id 1e1wLA-00087m-DZ\n\tfor qemu-devel@nongnu.org; Tue, 10 Oct 2017 11:21:04 -0400","from smtp.corp.redhat.com\n\t(int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby mx1.redhat.com (Postfix) with ESMTPS id C12A75F2967;\n\tTue, 10 Oct 2017 15:21:02 +0000 (UTC)","from redhat.com (ovpn-124-102.rdu2.redhat.com [10.10.124.102])\n\tby smtp.corp.redhat.com (Postfix) with ESMTP id 305E468736;\n\tTue, 10 Oct 2017 15:21:01 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com C12A75F2967","Date":"Tue, 10 Oct 2017 18:21:00 +0300","From":"\"Michael S. Tsirkin\" ","To":"\"Daniel P. Berrange\" ","Message-ID":"<20171010181646-mutt-send-email-mst@kernel.org>","References":"<20170911165929.2791-1-marcandre.lureau@redhat.com>\n\t<20170911165929.2791-3-marcandre.lureau@redhat.com>\n\t<20171009110336.GA17824@redhat.com>\n\t<20171009144344.38bbd1e9@nial.brq.redhat.com>\n\t<20171009130218.GK2954@redhat.com>\n\t<20171010003951-mutt-send-email-mst@kernel.org>\n\t<20171010083143.GA30015@redhat.com>\n\t\n\t<20171010150628.GI30015@redhat.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=iso-8859-1","Content-Disposition":"inline","In-Reply-To":"<20171010150628.GI30015@redhat.com>","X-Scanned-By":"MIMEDefang 2.79 on 10.5.11.14","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.38]);\n\tTue, 10 Oct 2017 15:21:02 +0000 (UTC)","Content-Transfer-Encoding":"quoted-printable","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]\n\t[fuzzy]","X-Received-From":"209.132.183.28","Subject":"Re: [Qemu-devel] [PATCH v6 2/7] hw/misc: add vmcoreinfo device","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Eduardo Habkost , QEMU ,\n\tDave Anderson , =?iso-8859-1?q?Marc-Andr=E9?=\n\tLureau , Igor Mammedov ,\n\tLaszlo Ersek ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1783997,"web_url":"http://patchwork.ozlabs.org/comment/1783997/","msgid":"<20171010180110.GI3246@localhost.localdomain>","list_archive_url":null,"date":"2017-10-10T18:01:10","subject":"Re: [Qemu-devel] [PATCH v6 2/7] hw/misc: add vmcoreinfo device","submitter":{"id":195,"url":"http://patchwork.ozlabs.org/api/people/195/","name":"Eduardo Habkost","email":"ehabkost@redhat.com"},"content":"On Tue, Oct 10, 2017 at 04:06:28PM +0100, Daniel P. Berrange wrote:\n> On Tue, Oct 10, 2017 at 05:00:18PM +0200, Marc-André Lureau wrote:\n> > Hi\n> > \n> > On Tue, Oct 10, 2017 at 10:31 AM, Daniel P. Berrange\n> > wrote:\n> > > On Tue, Oct 10, 2017 at 12:44:26AM +0300, Michael S. Tsirkin wrote:\n> > >> On Mon, Oct 09, 2017 at 02:02:18PM +0100, Daniel P. Berrange wrote:\n> > >> > On Mon, Oct 09, 2017 at 02:43:44PM +0200, Igor Mammedov wrote:\n> > >> > > On Mon, 9 Oct 2017 12:03:36 +0100\n> > >> > > \"Daniel P. Berrange\" wrote:\n> > >> > >\n> > >> > > > On Mon, Sep 11, 2017 at 06:59:24PM +0200, Marc-André Lureau wrote:\n> > >> > > > > See docs/specs/vmcoreinfo.txt for details.\n> > >> > > > >\n> > >> > > > > \"etc/vmcoreinfo\" fw_cfg entry is added when using \"-device vmcoreinfo\".\n> > >> > > >\n> > >> > > > I'm wondering if you considered just adding the entry to fw_cfg by\n> > >> > > > default, without requiring any -device arg ? Unless I'm misunderstanding,\n> > >> > > > this doesn't feel like a device to me - its just a well known bucket\n> > >> > > > in fw_cfg IIUC ? Obviously its existance would need to be tied to\n> > >> > > > the latest machine type for ABI reasons though. The benefit of this\n> > >> > > > is that it would \"just work\" without us having to plumb it through to\n> > >> > > > all the downstream applications that use QEMU for mgmt guest (OpenStack,\n> > >> > > > oVirt, GNOME Boxes, virt-manager, and countless other mgmt apps).\n> > >> > > it follows model set by pvpanic device, it's easier to manage from migration\n> > >> > > POV, one could use it even for old machine types with new qemu (just by adding\n> > >> > > device, it makes instance not backwards migratable to old qemu but should work\n> > >> > > for forward migration) and if user doesn't need it, device could be just omitted\n> > >> > > from CLI.\n> > >> >\n> > >> > Sure but it means that in effect no one will have this functionality enabled\n> > >> > for several years. pvpanic has been around a long time and I rarely see it\n> > >> > present in configured guests :-(\n> > >> >\n> > >> >\n> > >> > Regards,\n> > >> > Daniel\n> > >>\n> > >> libvirt runs with -nodefaults, right? I'd argue pretty strongly -nodefaults\n> > >> shouldn't add optional devices anyway.\n> > >\n> > > This isn't really adding a device though is it - it is just a well known\n> > > location in fw_cfg to receive data.\n> > \n> > Enabling the device on some configurations by default can be done as a\n> > follow-up patch. Can we get this series reviewed & merged?\n> \n> The problem with the -device approach + turning it on by default is that there\n> is no way to turn it off again if you don't want it. eg there's way to undo\n> an implicit '-device foo' except via -nodefaults, but since libvirt uses that\n> already it would negate the effect of enabling it by default unconditionally.\n\nIt's still possible to add a -machine option that can\nenable/disable automatic creation of the device.\n\nBut I also don't see why it needs to be implemented using -device\nif it's not really a device. A boolean machine or fw_cfg\nproperty is good enough for that.\n\n> \n> Your previous approach of \"-global fw_cfg.vmcoreinfo=on\" is nicer in this\n> respect, as you can trivially turn it on/off, overriding the default state\n> in both directions.\n\nBoth \"-global fw_cfg.vmcoreinfo=on|off\" and\n\"-machine vmcoreinfo=on|off\" sound good enough to me.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","ext-mx01.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx01.extmail.prod.ext.phx2.redhat.com;\n\tspf=fail smtp.mailfrom=ehabkost@redhat.com"],"Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3yBQ0m22nMz9t5R\n\tfor ;\n\tWed, 11 Oct 2017 05:01:44 +1100 (AEDT)","from localhost ([::1]:36484 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1e1yqc-00027Y-F4\n\tfor incoming@patchwork.ozlabs.org; Tue, 10 Oct 2017 14:01:42 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:34436)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1e1yqE-00027Q-Lw\n\tfor qemu-devel@nongnu.org; Tue, 10 Oct 2017 14:01:22 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1e1yqB-0005FH-IE\n\tfor qemu-devel@nongnu.org; Tue, 10 Oct 2017 14:01:18 -0400","from mx1.redhat.com ([209.132.183.28]:36268)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from ) id 1e1yqB-0005F4-9v\n\tfor qemu-devel@nongnu.org; Tue, 10 Oct 2017 14:01:15 -0400","from smtp.corp.redhat.com\n\t(int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby mx1.redhat.com (Postfix) with ESMTPS id 299457F3F0;\n\tTue, 10 Oct 2017 18:01:14 +0000 (UTC)","from localhost (ovpn-116-24.gru2.redhat.com [10.97.116.24])\n\tby smtp.corp.redhat.com (Postfix) with ESMTP id A613E6BC1E;\n\tTue, 10 Oct 2017 18:01:11 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com 299457F3F0","Date":"Tue, 10 Oct 2017 15:01:10 -0300","From":"Eduardo Habkost ","To":"\"Daniel P. Berrange\" ","Message-ID":"<20171010180110.GI3246@localhost.localdomain>","References":"<20170911165929.2791-1-marcandre.lureau@redhat.com>\n\t<20170911165929.2791-3-marcandre.lureau@redhat.com>\n\t<20171009110336.GA17824@redhat.com>\n\t<20171009144344.38bbd1e9@nial.brq.redhat.com>\n\t<20171009130218.GK2954@redhat.com>\n\t<20171010003951-mutt-send-email-mst@kernel.org>\n\t<20171010083143.GA30015@redhat.com>\n\t\n\t<20171010150628.GI30015@redhat.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=iso-8859-1","Content-Disposition":"inline","In-Reply-To":"<20171010150628.GI30015@redhat.com>","X-Fnord":"you can see the fnord","User-Agent":"Mutt/1.9.0 (2017-09-02)","X-Scanned-By":"MIMEDefang 2.79 on 10.5.11.11","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.25]);\n\tTue, 10 Oct 2017 18:01:14 +0000 (UTC)","Content-Transfer-Encoding":"quoted-printable","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]\n\t[fuzzy]","X-Received-From":"209.132.183.28","Subject":"Re: [Qemu-devel] [PATCH v6 2/7] hw/misc: add vmcoreinfo device","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"\"Michael S. Tsirkin\" , QEMU ,\n\tDave Anderson , =?iso-8859-1?q?Marc-Andr=E9?=\n\tLureau , Igor Mammedov ,\n\tLaszlo Ersek ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1784059,"web_url":"http://patchwork.ozlabs.org/comment/1784059/","msgid":"<20171010191502.GA32108@localhost.localdomain>","list_archive_url":null,"date":"2017-10-10T19:15:02","subject":"Re: [Qemu-devel] [PATCH v6 2/7] hw/misc: add vmcoreinfo device","submitter":{"id":195,"url":"http://patchwork.ozlabs.org/api/people/195/","name":"Eduardo Habkost","email":"ehabkost@redhat.com"},"content":"On Tue, Oct 10, 2017 at 12:44:26AM +0300, Michael S. Tsirkin wrote:\n> On Mon, Oct 09, 2017 at 02:02:18PM +0100, Daniel P. Berrange wrote:\n> > On Mon, Oct 09, 2017 at 02:43:44PM +0200, Igor Mammedov wrote:\n> > > On Mon, 9 Oct 2017 12:03:36 +0100\n> > > \"Daniel P. Berrange\" wrote:\n> > > \n> > > > On Mon, Sep 11, 2017 at 06:59:24PM +0200, Marc-André Lureau wrote:\n> > > > > See docs/specs/vmcoreinfo.txt for details.\n> > > > > \n> > > > > \"etc/vmcoreinfo\" fw_cfg entry is added when using \"-device vmcoreinfo\". \n> > > > \n> > > > I'm wondering if you considered just adding the entry to fw_cfg by\n> > > > default, without requiring any -device arg ? Unless I'm misunderstanding,\n> > > > this doesn't feel like a device to me - its just a well known bucket\n> > > > in fw_cfg IIUC ? Obviously its existance would need to be tied to\n> > > > the latest machine type for ABI reasons though. The benefit of this\n> > > > is that it would \"just work\" without us having to plumb it through to\n> > > > all the downstream applications that use QEMU for mgmt guest (OpenStack,\n> > > > oVirt, GNOME Boxes, virt-manager, and countless other mgmt apps).\n> > > it follows model set by pvpanic device, it's easier to manage from migration\n> > > POV, one could use it even for old machine types with new qemu (just by adding\n> > > device, it makes instance not backwards migratable to old qemu but should work\n> > > for forward migration) and if user doesn't need it, device could be just omitted\n> > > from CLI.\n> > \n> > Sure but it means that in effect no one will have this functionality enabled\n> > for several years. pvpanic has been around a long time and I rarely see it\n> > present in configured guests :-(\n> > \n> > \n> > Regards,\n> > Daniel\n> \n> libvirt runs with -nodefaults, right? I'd argue pretty strongly -nodefaults\n> shouldn't add optional devices anyway.\n\nDoes it mean every time we make a PC device configurable, we\nshould make it be disabled by -nodefaults, and require libvirt to\nadapt?\n\nI don't think that would be a good idea. Imagine the hassle the\n\"pc: make .* configurable\" patches[1] would generate for libvirt.\n\n> \n> So it's up to you guys, you can add it to VMs by default if you want to.\n\nTo be honest, I think \"no defaults\" is a misleading name for an\noption. If it really meant \"create no optional device at all\",\nit would eventually become a synonym for \"-machine none\", and I\ndon't think that's its goal.\n\nI expect PC to always have a set of devices/features that are\ndisabled by -nodefaults, and a set of devices/features that are\nnot disabled by -nodefaults. We need good judgement to decide on\nwhich set the device will be, and I believe Daniel exposed good\narguments to put vmcoreinfo in the second set.\n\n[1] https://www.mail-archive.com/qemu-devel@nongnu.org/msg393493.html\n Subject: [RFC PATCH v2 00/12] Guest startup time optimization","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","ext-mx09.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx09.extmail.prod.ext.phx2.redhat.com;\n\tspf=fail smtp.mailfrom=ehabkost@redhat.com"],"Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3yBRfF0fs5z9t3B\n\tfor ;\n\tWed, 11 Oct 2017 06:15:48 +1100 (AEDT)","from localhost ([::1]:36741 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1e200H-0003i9-9D\n\tfor incoming@patchwork.ozlabs.org; Tue, 10 Oct 2017 15:15:45 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:54992)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1e1zzv-0003i4-PQ\n\tfor qemu-devel@nongnu.org; Tue, 10 Oct 2017 15:15:24 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1e1zzs-0007CN-Ik\n\tfor qemu-devel@nongnu.org; Tue, 10 Oct 2017 15:15:23 -0400","from mx1.redhat.com ([209.132.183.28]:59318)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from ) id 1e1zzs-0007Bv-0k\n\tfor qemu-devel@nongnu.org; Tue, 10 Oct 2017 15:15:20 -0400","from smtp.corp.redhat.com\n\t(int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby mx1.redhat.com (Postfix) with ESMTPS id B7F064A702\n\tfor ; Tue, 10 Oct 2017 19:15:18 +0000 (UTC)","from localhost (ovpn-116-24.gru2.redhat.com [10.97.116.24])\n\tby smtp.corp.redhat.com (Postfix) with ESMTP id C0AF368893;\n\tTue, 10 Oct 2017 19:15:04 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com B7F064A702","Date":"Tue, 10 Oct 2017 16:15:02 -0300","From":"Eduardo Habkost ","To":"\"Michael S. Tsirkin\" ","Message-ID":"<20171010191502.GA32108@localhost.localdomain>","References":"<20170911165929.2791-1-marcandre.lureau@redhat.com>\n\t<20170911165929.2791-3-marcandre.lureau@redhat.com>\n\t<20171009110336.GA17824@redhat.com>\n\t<20171009144344.38bbd1e9@nial.brq.redhat.com>\n\t<20171009130218.GK2954@redhat.com>\n\t<20171010003951-mutt-send-email-mst@kernel.org>","MIME-Version":"1.0","Content-Type":"text/plain; charset=iso-8859-1","Content-Disposition":"inline","In-Reply-To":"<20171010003951-mutt-send-email-mst@kernel.org>","X-Fnord":"you can see the fnord","User-Agent":"Mutt/1.9.0 (2017-09-02)","X-Scanned-By":"MIMEDefang 2.79 on 10.5.11.16","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.38]);\n\tTue, 10 Oct 2017 19:15:18 +0000 (UTC)","Content-Transfer-Encoding":"quoted-printable","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]\n\t[fuzzy]","X-Received-From":"209.132.183.28","Subject":"Re: [Qemu-devel] [PATCH v6 2/7] hw/misc: add vmcoreinfo device","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"qemu-devel@nongnu.org, anderson@redhat.com, =?iso-8859-1?q?Marc-Andr?=\n\t=?iso-8859-1?q?=E9?= Lureau ,\n\tIgor Mammedov , lersek@redhat.com","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1786939,"web_url":"http://patchwork.ozlabs.org/comment/1786939/","msgid":"<20171015044800-mutt-send-email-mst@kernel.org>","list_archive_url":null,"date":"2017-10-15T01:56:28","subject":"Re: [Qemu-devel] [PATCH v6 2/7] hw/misc: add vmcoreinfo device","submitter":{"id":2235,"url":"http://patchwork.ozlabs.org/api/people/2235/","name":"Michael S. Tsirkin","email":"mst@redhat.com"},"content":"On Tue, Oct 10, 2017 at 03:01:10PM -0300, Eduardo Habkost wrote:\n> On Tue, Oct 10, 2017 at 04:06:28PM +0100, Daniel P. Berrange wrote:\n> > On Tue, Oct 10, 2017 at 05:00:18PM +0200, Marc-André Lureau wrote:\n> > > Hi\n> > > \n> > > On Tue, Oct 10, 2017 at 10:31 AM, Daniel P. Berrange\n> > > wrote:\n> > > > On Tue, Oct 10, 2017 at 12:44:26AM +0300, Michael S. Tsirkin wrote:\n> > > >> On Mon, Oct 09, 2017 at 02:02:18PM +0100, Daniel P. Berrange wrote:\n> > > >> > On Mon, Oct 09, 2017 at 02:43:44PM +0200, Igor Mammedov wrote:\n> > > >> > > On Mon, 9 Oct 2017 12:03:36 +0100\n> > > >> > > \"Daniel P. Berrange\" wrote:\n> > > >> > >\n> > > >> > > > On Mon, Sep 11, 2017 at 06:59:24PM +0200, Marc-André Lureau wrote:\n> > > >> > > > > See docs/specs/vmcoreinfo.txt for details.\n> > > >> > > > >\n> > > >> > > > > \"etc/vmcoreinfo\" fw_cfg entry is added when using \"-device vmcoreinfo\".\n> > > >> > > >\n> > > >> > > > I'm wondering if you considered just adding the entry to fw_cfg by\n> > > >> > > > default, without requiring any -device arg ? Unless I'm misunderstanding,\n> > > >> > > > this doesn't feel like a device to me - its just a well known bucket\n> > > >> > > > in fw_cfg IIUC ? Obviously its existance would need to be tied to\n> > > >> > > > the latest machine type for ABI reasons though. The benefit of this\n> > > >> > > > is that it would \"just work\" without us having to plumb it through to\n> > > >> > > > all the downstream applications that use QEMU for mgmt guest (OpenStack,\n> > > >> > > > oVirt, GNOME Boxes, virt-manager, and countless other mgmt apps).\n> > > >> > > it follows model set by pvpanic device, it's easier to manage from migration\n> > > >> > > POV, one could use it even for old machine types with new qemu (just by adding\n> > > >> > > device, it makes instance not backwards migratable to old qemu but should work\n> > > >> > > for forward migration) and if user doesn't need it, device could be just omitted\n> > > >> > > from CLI.\n> > > >> >\n> > > >> > Sure but it means that in effect no one will have this functionality enabled\n> > > >> > for several years. pvpanic has been around a long time and I rarely see it\n> > > >> > present in configured guests :-(\n> > > >> >\n> > > >> >\n> > > >> > Regards,\n> > > >> > Daniel\n> > > >>\n> > > >> libvirt runs with -nodefaults, right? I'd argue pretty strongly -nodefaults\n> > > >> shouldn't add optional devices anyway.\n> > > >\n> > > > This isn't really adding a device though is it - it is just a well known\n> > > > location in fw_cfg to receive data.\n> > > \n> > > Enabling the device on some configurations by default can be done as a\n> > > follow-up patch. Can we get this series reviewed & merged?\n> > \n> > The problem with the -device approach + turning it on by default is that there\n> > is no way to turn it off again if you don't want it. eg there's way to undo\n> > an implicit '-device foo' except via -nodefaults, but since libvirt uses that\n> > already it would negate the effect of enabling it by default unconditionally.\n> \n> It's still possible to add a -machine option that can\n> enable/disable automatic creation of the device.\n> \n> But I also don't see why it needs to be implemented using -device\n> if it's not really a device. A boolean machine or fw_cfg\n> property is good enough for that.\n\nIt certainly feels like a device. It has state\n(that needs to be migrated), it has a host/guest interface.\n\n\n> > \n> > Your previous approach of \"-global fw_cfg.vmcoreinfo=on\" is nicer in this\n> > respect, as you can trivially turn it on/off, overriding the default state\n> > in both directions.\n> \n> Both \"-global fw_cfg.vmcoreinfo=on|off\" and\n> \"-machine vmcoreinfo=on|off\" sound good enough to me.\n\n\nCertainly not a fw cfg flag. Can be a machine flag I guess\nbut then we'd have to open-code each such device.\nAnd don't forget auto - this is what Daniel asks for.\n\nI don't necessarily see this device as so special and think a generic\ninterface to control what goes into the machine would be better (e.g.\nlook how you use hacky -global to control fw cfg options, it only works\nif there's a single one), but if everyone thinks otherwise and agrees we\nshould have it in there by default, and a property to disable, fine.\n\nCan be a patch on top though.\n\n\n> -- \n> Eduardo","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","ext-mx10.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx10.extmail.prod.ext.phx2.redhat.com;\n\tspf=fail smtp.mailfrom=mst@redhat.com"],"Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3yF4MR3yTKz9sPt\n\tfor ;\n\tSun, 15 Oct 2017 12:57:01 +1100 (AEDT)","from localhost ([::1]:55775 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1e3YAj-0000d0-V4\n\tfor incoming@patchwork.ozlabs.org; Sat, 14 Oct 2017 21:56:57 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:35423)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1e3YAQ-0000cf-0A\n\tfor qemu-devel@nongnu.org; Sat, 14 Oct 2017 21:56:39 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1e3YAL-0005GI-4F\n\tfor qemu-devel@nongnu.org; Sat, 14 Oct 2017 21:56:38 -0400","from mx1.redhat.com ([209.132.183.28]:60134)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from ) id 1e3YAK-0005G3-QT\n\tfor qemu-devel@nongnu.org; Sat, 14 Oct 2017 21:56:33 -0400","from smtp.corp.redhat.com\n\t(int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby mx1.redhat.com (Postfix) with ESMTPS id 7A84F5AFD9;\n\tSun, 15 Oct 2017 01:56:31 +0000 (UTC)","from redhat.com (ovpn-120-178.rdu2.redhat.com [10.10.120.178])\n\tby smtp.corp.redhat.com (Postfix) with ESMTP id 844A8600CC;\n\tSun, 15 Oct 2017 01:56:28 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com 7A84F5AFD9","Date":"Sun, 15 Oct 2017 04:56:28 +0300","From":"\"Michael S. Tsirkin\" ","To":"Eduardo Habkost ","Message-ID":"<20171015044800-mutt-send-email-mst@kernel.org>","References":"<20170911165929.2791-1-marcandre.lureau@redhat.com>\n\t<20170911165929.2791-3-marcandre.lureau@redhat.com>\n\t<20171009110336.GA17824@redhat.com>\n\t<20171009144344.38bbd1e9@nial.brq.redhat.com>\n\t<20171009130218.GK2954@redhat.com>\n\t<20171010003951-mutt-send-email-mst@kernel.org>\n\t<20171010083143.GA30015@redhat.com>\n\t\n\t<20171010150628.GI30015@redhat.com>\n\t<20171010180110.GI3246@localhost.localdomain>","MIME-Version":"1.0","Content-Type":"text/plain; charset=iso-8859-1","Content-Disposition":"inline","In-Reply-To":"<20171010180110.GI3246@localhost.localdomain>","X-Scanned-By":"MIMEDefang 2.79 on 10.5.11.11","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.39]);\n\tSun, 15 Oct 2017 01:56:31 +0000 (UTC)","Content-Transfer-Encoding":"quoted-printable","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]\n\t[fuzzy]","X-Received-From":"209.132.183.28","Subject":"Re: [Qemu-devel] [PATCH v6 2/7] hw/misc: add vmcoreinfo device","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"QEMU , =?iso-8859-1?q?Marc-Andr=E9?=\n\tLureau , Igor Mammedov ,\n\tLaszlo Ersek , \tDave Anderson ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1786940,"web_url":"http://patchwork.ozlabs.org/comment/1786940/","msgid":"<20171015045801-mutt-send-email-mst@kernel.org>","list_archive_url":null,"date":"2017-10-15T02:02:43","subject":"Re: [Qemu-devel] [PATCH v6 2/7] hw/misc: add vmcoreinfo device","submitter":{"id":2235,"url":"http://patchwork.ozlabs.org/api/people/2235/","name":"Michael S. Tsirkin","email":"mst@redhat.com"},"content":"On Tue, Oct 10, 2017 at 03:01:10PM -0300, Eduardo Habkost wrote:\n> On Tue, Oct 10, 2017 at 04:06:28PM +0100, Daniel P. Berrange wrote:\n> > On Tue, Oct 10, 2017 at 05:00:18PM +0200, Marc-André Lureau wrote:\n> > > Hi\n> > > \n> > > On Tue, Oct 10, 2017 at 10:31 AM, Daniel P. Berrange\n> > > wrote:\n> > > > On Tue, Oct 10, 2017 at 12:44:26AM +0300, Michael S. Tsirkin wrote:\n> > > >> On Mon, Oct 09, 2017 at 02:02:18PM +0100, Daniel P. Berrange wrote:\n> > > >> > On Mon, Oct 09, 2017 at 02:43:44PM +0200, Igor Mammedov wrote:\n> > > >> > > On Mon, 9 Oct 2017 12:03:36 +0100\n> > > >> > > \"Daniel P. Berrange\" wrote:\n> > > >> > >\n> > > >> > > > On Mon, Sep 11, 2017 at 06:59:24PM +0200, Marc-André Lureau wrote:\n> > > >> > > > > See docs/specs/vmcoreinfo.txt for details.\n> > > >> > > > >\n> > > >> > > > > \"etc/vmcoreinfo\" fw_cfg entry is added when using \"-device vmcoreinfo\".\n> > > >> > > >\n> > > >> > > > I'm wondering if you considered just adding the entry to fw_cfg by\n> > > >> > > > default, without requiring any -device arg ? Unless I'm misunderstanding,\n> > > >> > > > this doesn't feel like a device to me - its just a well known bucket\n> > > >> > > > in fw_cfg IIUC ? Obviously its existance would need to be tied to\n> > > >> > > > the latest machine type for ABI reasons though. The benefit of this\n> > > >> > > > is that it would \"just work\" without us having to plumb it through to\n> > > >> > > > all the downstream applications that use QEMU for mgmt guest (OpenStack,\n> > > >> > > > oVirt, GNOME Boxes, virt-manager, and countless other mgmt apps).\n> > > >> > > it follows model set by pvpanic device, it's easier to manage from migration\n> > > >> > > POV, one could use it even for old machine types with new qemu (just by adding\n> > > >> > > device, it makes instance not backwards migratable to old qemu but should work\n> > > >> > > for forward migration) and if user doesn't need it, device could be just omitted\n> > > >> > > from CLI.\n> > > >> >\n> > > >> > Sure but it means that in effect no one will have this functionality enabled\n> > > >> > for several years. pvpanic has been around a long time and I rarely see it\n> > > >> > present in configured guests :-(\n> > > >> >\n> > > >> >\n> > > >> > Regards,\n> > > >> > Daniel\n> > > >>\n> > > >> libvirt runs with -nodefaults, right? I'd argue pretty strongly -nodefaults\n> > > >> shouldn't add optional devices anyway.\n> > > >\n> > > > This isn't really adding a device though is it - it is just a well known\n> > > > location in fw_cfg to receive data.\n> > > \n> > > Enabling the device on some configurations by default can be done as a\n> > > follow-up patch. Can we get this series reviewed & merged?\n> > \n> > The problem with the -device approach + turning it on by default is that there\n> > is no way to turn it off again if you don't want it. eg there's way to undo\n> > an implicit '-device foo' except via -nodefaults, but since libvirt uses that\n> > already it would negate the effect of enabling it by default unconditionally.\n> \n> It's still possible to add a -machine option that can\n> enable/disable automatic creation of the device.\n>\n>\n> But I also don't see why it needs to be implemented using -device\n> if it's not really a device. A boolean machine or fw_cfg\n> property is good enough for that.\n\nDevice imho is a combination of guest/host interface and state.\n\n\n> > \n> > Your previous approach of \"-global fw_cfg.vmcoreinfo=on\" is nicer in this\n> > respect, as you can trivially turn it on/off, overriding the default state\n> > in both directions.\n> \n> Both \"-global fw_cfg.vmcoreinfo=on|off\" and\n> \"-machine vmcoreinfo=on|off\" sound good enough to me.\n\nI can live with the second option if people really want it.\nI'd like to see some way to add these things without\nadding to the mess that is the pc initialization\nbut oh well.\n\n> -- \n> Eduardo","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","ext-mx02.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx02.extmail.prod.ext.phx2.redhat.com;\n\tspf=fail smtp.mailfrom=mst@redhat.com"],"Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3yF4Vc5RRPz9sPt\n\tfor ;\n\tSun, 15 Oct 2017 13:03:16 +1100 (AEDT)","from localhost ([::1]:55785 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1e3YGn-0001aH-PQ\n\tfor incoming@patchwork.ozlabs.org; Sat, 14 Oct 2017 22:03:13 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:36141)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1e3YGR-0001Yp-53\n\tfor qemu-devel@nongnu.org; Sat, 14 Oct 2017 22:02:52 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1e3YGM-0000Ap-A6\n\tfor qemu-devel@nongnu.org; Sat, 14 Oct 2017 22:02:51 -0400","from mx1.redhat.com ([209.132.183.28]:59076)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from ) id 1e3YGM-000083-0V\n\tfor qemu-devel@nongnu.org; Sat, 14 Oct 2017 22:02:46 -0400","from smtp.corp.redhat.com\n\t(int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby mx1.redhat.com (Postfix) with ESMTPS id A4A92883AC;\n\tSun, 15 Oct 2017 02:02:44 +0000 (UTC)","from redhat.com (ovpn-120-178.rdu2.redhat.com [10.10.120.178])\n\tby smtp.corp.redhat.com (Postfix) with ESMTP id C10B05C1A3;\n\tSun, 15 Oct 2017 02:02:43 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com A4A92883AC","Date":"Sun, 15 Oct 2017 05:02:43 +0300","From":"\"Michael S. Tsirkin\" ","To":"Eduardo Habkost ","Message-ID":"<20171015045801-mutt-send-email-mst@kernel.org>","References":"<20170911165929.2791-1-marcandre.lureau@redhat.com>\n\t<20170911165929.2791-3-marcandre.lureau@redhat.com>\n\t<20171009110336.GA17824@redhat.com>\n\t<20171009144344.38bbd1e9@nial.brq.redhat.com>\n\t<20171009130218.GK2954@redhat.com>\n\t<20171010003951-mutt-send-email-mst@kernel.org>\n\t<20171010083143.GA30015@redhat.com>\n\t\n\t<20171010150628.GI30015@redhat.com>\n\t<20171010180110.GI3246@localhost.localdomain>","MIME-Version":"1.0","Content-Type":"text/plain; charset=iso-8859-1","Content-Disposition":"inline","In-Reply-To":"<20171010180110.GI3246@localhost.localdomain>","X-Scanned-By":"MIMEDefang 2.79 on 10.5.11.16","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.26]);\n\tSun, 15 Oct 2017 02:02:44 +0000 (UTC)","Content-Transfer-Encoding":"quoted-printable","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]\n\t[fuzzy]","X-Received-From":"209.132.183.28","Subject":"Re: [Qemu-devel] [PATCH v6 2/7] hw/misc: add vmcoreinfo device","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"QEMU , =?iso-8859-1?q?Marc-Andr=E9?=\n\tLureau , Igor Mammedov ,\n\tLaszlo Ersek , \tDave Anderson ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1791673,"web_url":"http://patchwork.ozlabs.org/comment/1791673/","msgid":"<20171020184820.GP2942@localhost.localdomain>","list_archive_url":null,"date":"2017-10-20T18:48:20","subject":"Re: [Qemu-devel] [PATCH v6 2/7] hw/misc: add vmcoreinfo device","submitter":{"id":195,"url":"http://patchwork.ozlabs.org/api/people/195/","name":"Eduardo Habkost","email":"ehabkost@redhat.com"},"content":"On Sun, Oct 15, 2017 at 04:56:28AM +0300, Michael S. Tsirkin wrote:\n> On Tue, Oct 10, 2017 at 03:01:10PM -0300, Eduardo Habkost wrote:\n> > On Tue, Oct 10, 2017 at 04:06:28PM +0100, Daniel P. Berrange wrote:\n> > > On Tue, Oct 10, 2017 at 05:00:18PM +0200, Marc-André Lureau wrote:\n> > > > Hi\n> > > > \n> > > > On Tue, Oct 10, 2017 at 10:31 AM, Daniel P. Berrange\n> > > > wrote:\n> > > > > On Tue, Oct 10, 2017 at 12:44:26AM +0300, Michael S. Tsirkin wrote:\n> > > > >> On Mon, Oct 09, 2017 at 02:02:18PM +0100, Daniel P. Berrange wrote:\n> > > > >> > On Mon, Oct 09, 2017 at 02:43:44PM +0200, Igor Mammedov wrote:\n> > > > >> > > On Mon, 9 Oct 2017 12:03:36 +0100\n> > > > >> > > \"Daniel P. Berrange\" wrote:\n> > > > >> > >\n> > > > >> > > > On Mon, Sep 11, 2017 at 06:59:24PM +0200, Marc-André Lureau wrote:\n> > > > >> > > > > See docs/specs/vmcoreinfo.txt for details.\n> > > > >> > > > >\n> > > > >> > > > > \"etc/vmcoreinfo\" fw_cfg entry is added when using \"-device vmcoreinfo\".\n> > > > >> > > >\n> > > > >> > > > I'm wondering if you considered just adding the entry to fw_cfg by\n> > > > >> > > > default, without requiring any -device arg ? Unless I'm misunderstanding,\n> > > > >> > > > this doesn't feel like a device to me - its just a well known bucket\n> > > > >> > > > in fw_cfg IIUC ? Obviously its existance would need to be tied to\n> > > > >> > > > the latest machine type for ABI reasons though. The benefit of this\n> > > > >> > > > is that it would \"just work\" without us having to plumb it through to\n> > > > >> > > > all the downstream applications that use QEMU for mgmt guest (OpenStack,\n> > > > >> > > > oVirt, GNOME Boxes, virt-manager, and countless other mgmt apps).\n> > > > >> > > it follows model set by pvpanic device, it's easier to manage from migration\n> > > > >> > > POV, one could use it even for old machine types with new qemu (just by adding\n> > > > >> > > device, it makes instance not backwards migratable to old qemu but should work\n> > > > >> > > for forward migration) and if user doesn't need it, device could be just omitted\n> > > > >> > > from CLI.\n> > > > >> >\n> > > > >> > Sure but it means that in effect no one will have this functionality enabled\n> > > > >> > for several years. pvpanic has been around a long time and I rarely see it\n> > > > >> > present in configured guests :-(\n> > > > >> >\n> > > > >> >\n> > > > >> > Regards,\n> > > > >> > Daniel\n> > > > >>\n> > > > >> libvirt runs with -nodefaults, right? I'd argue pretty strongly -nodefaults\n> > > > >> shouldn't add optional devices anyway.\n> > > > >\n> > > > > This isn't really adding a device though is it - it is just a well known\n> > > > > location in fw_cfg to receive data.\n> > > > \n> > > > Enabling the device on some configurations by default can be done as a\n> > > > follow-up patch. Can we get this series reviewed & merged?\n> > > \n> > > The problem with the -device approach + turning it on by default is that there\n> > > is no way to turn it off again if you don't want it. eg there's way to undo\n> > > an implicit '-device foo' except via -nodefaults, but since libvirt uses that\n> > > already it would negate the effect of enabling it by default unconditionally.\n> > \n> > It's still possible to add a -machine option that can\n> > enable/disable automatic creation of the device.\n> > \n> > But I also don't see why it needs to be implemented using -device\n> > if it's not really a device. A boolean machine or fw_cfg\n> > property is good enough for that.\n> \n> It certainly feels like a device. It has state\n> (that needs to be migrated), it has a host/guest interface.\n\n(Sorry for the late reply)\n\nThat's convincing enough to me. :)\n\n\n> > > \n> > > Your previous approach of \"-global fw_cfg.vmcoreinfo=on\" is nicer in this\n> > > respect, as you can trivially turn it on/off, overriding the default state\n> > > in both directions.\n> > \n> > Both \"-global fw_cfg.vmcoreinfo=on|off\" and\n> > \"-machine vmcoreinfo=on|off\" sound good enough to me.\n> \n> \n> Certainly not a fw cfg flag. Can be a machine flag I guess\n> but then we'd have to open-code each such device.\n> And don't forget auto - this is what Daniel asks for.\n\nI'm not sure Daniel is really asking for \"auto\": he is just\nasking for a way to disable the new default. If \"vmcoreinfo=off\"\nand \"vmcoreinfo=off\" works, there's no need for a user-visible\n\"auto\" value.\n\n(Actually, \"auto\" values makes compatibility code even messier,\nbecause we would need one additional compat property/field to\ntell QEMU what \"auto\" means on each machine)","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","ext-mx07.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx07.extmail.prod.ext.phx2.redhat.com;\n\tspf=fail smtp.mailfrom=ehabkost@redhat.com"],"Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3yJZZb4cgHz9t3x\n\tfor ;\n\tSat, 21 Oct 2017 05:48:54 +1100 (AEDT)","from localhost ([::1]:55279 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1e5cLk-00021y-3M\n\tfor incoming@patchwork.ozlabs.org; Fri, 20 Oct 2017 14:48:52 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:59795)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1e5cLN-00021s-4f\n\tfor qemu-devel@nongnu.org; Fri, 20 Oct 2017 14:48:30 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1e5cLJ-0003KC-WC\n\tfor qemu-devel@nongnu.org; Fri, 20 Oct 2017 14:48:29 -0400","from mx1.redhat.com ([209.132.183.28]:33568)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from ) id 1e5cLJ-0003Jw-NO\n\tfor qemu-devel@nongnu.org; Fri, 20 Oct 2017 14:48:25 -0400","from smtp.corp.redhat.com\n\t(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby mx1.redhat.com (Postfix) with ESMTPS id 90FADC04AC42;\n\tFri, 20 Oct 2017 18:48:24 +0000 (UTC)","from localhost (ovpn-116-9.gru2.redhat.com [10.97.116.9])\n\tby smtp.corp.redhat.com (Postfix) with ESMTP id 0D81F60E37;\n\tFri, 20 Oct 2017 18:48:21 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com 90FADC04AC42","Date":"Fri, 20 Oct 2017 16:48:20 -0200","From":"Eduardo Habkost ","To":"\"Michael S. Tsirkin\" ","Message-ID":"<20171020184820.GP2942@localhost.localdomain>","References":"<20170911165929.2791-3-marcandre.lureau@redhat.com>\n\t<20171009110336.GA17824@redhat.com>\n\t<20171009144344.38bbd1e9@nial.brq.redhat.com>\n\t<20171009130218.GK2954@redhat.com>\n\t<20171010003951-mutt-send-email-mst@kernel.org>\n\t<20171010083143.GA30015@redhat.com>\n\t\n\t<20171010150628.GI30015@redhat.com>\n\t<20171010180110.GI3246@localhost.localdomain>\n\t<20171015044800-mutt-send-email-mst@kernel.org>","MIME-Version":"1.0","Content-Type":"text/plain; charset=iso-8859-1","Content-Disposition":"inline","In-Reply-To":"<20171015044800-mutt-send-email-mst@kernel.org>","X-Fnord":"you can see the fnord","User-Agent":"Mutt/1.9.0 (2017-09-02)","X-Scanned-By":"MIMEDefang 2.79 on 10.5.11.12","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.31]);\n\tFri, 20 Oct 2017 18:48:24 +0000 (UTC)","Content-Transfer-Encoding":"quoted-printable","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]\n\t[fuzzy]","X-Received-From":"209.132.183.28","Subject":"Re: [Qemu-devel] [PATCH v6 2/7] hw/misc: add vmcoreinfo device","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"QEMU , =?iso-8859-1?q?Marc-Andr=E9?=\n\tLureau , Igor Mammedov ,\n\tLaszlo Ersek , \tDave Anderson ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1895102,"web_url":"http://patchwork.ozlabs.org/comment/1895102/","msgid":"","list_archive_url":null,"date":"2018-04-17T19:12:03","subject":"Re: [Qemu-devel] [PATCH v6 2/7] hw/misc: add vmcoreinfo device","submitter":{"id":3411,"url":"http://patchwork.ozlabs.org/api/people/3411/","name":"Cole Robinson","email":"crobinso@redhat.com"},"content":"On 10/20/2017 02:48 PM, Eduardo Habkost wrote:\n> On Sun, Oct 15, 2017 at 04:56:28AM +0300, Michael S. Tsirkin wrote:\n>> On Tue, Oct 10, 2017 at 03:01:10PM -0300, Eduardo Habkost wrote:\n>>> On Tue, Oct 10, 2017 at 04:06:28PM +0100, Daniel P. Berrange wrote:\n>>>> On Tue, Oct 10, 2017 at 05:00:18PM +0200, Marc-André Lureau wrote:\n>>>>> Hi\n>>>>>\n>>>>> On Tue, Oct 10, 2017 at 10:31 AM, Daniel P. Berrange\n>>>>> wrote:\n>>>>>> On Tue, Oct 10, 2017 at 12:44:26AM +0300, Michael S. Tsirkin wrote:\n>>>>>>> On Mon, Oct 09, 2017 at 02:02:18PM +0100, Daniel P. Berrange wrote:\n>>>>>>>> On Mon, Oct 09, 2017 at 02:43:44PM +0200, Igor Mammedov wrote:\n>>>>>>>>> On Mon, 9 Oct 2017 12:03:36 +0100\n>>>>>>>>> \"Daniel P. Berrange\" wrote:\n>>>>>>>>>\n>>>>>>>>>> On Mon, Sep 11, 2017 at 06:59:24PM +0200, Marc-André Lureau wrote:\n>>>>>>>>>>> See docs/specs/vmcoreinfo.txt for details.\n>>>>>>>>>>>\n>>>>>>>>>>> \"etc/vmcoreinfo\" fw_cfg entry is added when using \"-device vmcoreinfo\".\n>>>>>>>>>>\n>>>>>>>>>> I'm wondering if you considered just adding the entry to fw_cfg by\n>>>>>>>>>> default, without requiring any -device arg ? Unless I'm misunderstanding,\n>>>>>>>>>> this doesn't feel like a device to me - its just a well known bucket\n>>>>>>>>>> in fw_cfg IIUC ? Obviously its existance would need to be tied to\n>>>>>>>>>> the latest machine type for ABI reasons though. The benefit of this\n>>>>>>>>>> is that it would \"just work\" without us having to plumb it through to\n>>>>>>>>>> all the downstream applications that use QEMU for mgmt guest (OpenStack,\n>>>>>>>>>> oVirt, GNOME Boxes, virt-manager, and countless other mgmt apps).\n>>>>>>>>> it follows model set by pvpanic device, it's easier to manage from migration\n>>>>>>>>> POV, one could use it even for old machine types with new qemu (just by adding\n>>>>>>>>> device, it makes instance not backwards migratable to old qemu but should work\n>>>>>>>>> for forward migration) and if user doesn't need it, device could be just omitted\n>>>>>>>>> from CLI.\n>>>>>>>>\n>>>>>>>> Sure but it means that in effect no one will have this functionality enabled\n>>>>>>>> for several years. pvpanic has been around a long time and I rarely see it\n>>>>>>>> present in configured guests :-(\n>>>>>>>>\n>>>>>>>>\n>>>>>>>> Regards,\n>>>>>>>> Daniel\n>>>>>>>\n>>>>>>> libvirt runs with -nodefaults, right? I'd argue pretty strongly -nodefaults\n>>>>>>> shouldn't add optional devices anyway.\n>>>>>>\n>>>>>> This isn't really adding a device though is it - it is just a well known\n>>>>>> location in fw_cfg to receive data.\n>>>>>\n>>>>> Enabling the device on some configurations by default can be done as a\n>>>>> follow-up patch. Can we get this series reviewed & merged?\n>>>>\n>>>> The problem with the -device approach + turning it on by default is that there\n>>>> is no way to turn it off again if you don't want it. eg there's way to undo\n>>>> an implicit '-device foo' except via -nodefaults, but since libvirt uses that\n>>>> already it would negate the effect of enabling it by default unconditionally.\n>>>\n>>> It's still possible to add a -machine option that can\n>>> enable/disable automatic creation of the device.\n>>>\n>>> But I also don't see why it needs to be implemented using -device\n>>> if it's not really a device. A boolean machine or fw_cfg\n>>> property is good enough for that.\n>>\n>> It certainly feels like a device. It has state\n>> (that needs to be migrated), it has a host/guest interface.\n> \n> (Sorry for the late reply)\n> \n> That's convincing enough to me. :)\n> \n> \n>>>>\n>>>> Your previous approach of \"-global fw_cfg.vmcoreinfo=on\" is nicer in this\n>>>> respect, as you can trivially turn it on/off, overriding the default state\n>>>> in both directions.\n>>>\n>>> Both \"-global fw_cfg.vmcoreinfo=on|off\" and\n>>> \"-machine vmcoreinfo=on|off\" sound good enough to me.\n>>\n>>\n>> Certainly not a fw cfg flag. Can be a machine flag I guess\n>> but then we'd have to open-code each such device.\n>> And don't forget auto - this is what Daniel asks for.\n> \n> I'm not sure Daniel is really asking for \"auto\": he is just\n> asking for a way to disable the new default. If \"vmcoreinfo=off\"\n> and \"vmcoreinfo=off\" works, there's no need for a user-visible\n> \"auto\" value.\n> \n> (Actually, \"auto\" values makes compatibility code even messier,\n> because we would need one additional compat property/field to\n> tell QEMU what \"auto\" means on each machine)\n> \n\nReviving this... did any follow up changes happen?\n\nMarc-André patched virt-manager a few months back to enable -device\nvmcoreinfo for new VMs:\n\nhttps://www.redhat.com/archives/virt-tools-list/2018-February/msg00020.html\n\nAnd I see there's at least a bug tracking adding this to openstack for\nnew VMs:\n\nhttps://bugzilla.redhat.com/show_bug.cgi?id=1555276\n\nIf this feature doesn't really have any downsides, it would be nice to\nget this tied to new machine types. Saves a lot of churn for higher\nlevels of the stack\n\nThanks,\nCole","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","ozlabs.org;\n\tdmarc=fail (p=none dis=none) header.from=redhat.com"],"Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 40QZgX6Q74z9s1d\n\tfor ;\n\tWed, 18 Apr 2018 05:14:32 +1000 (AEST)","from localhost ([::1]:57116 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1f8W3i-0000T7-V3\n\tfor incoming@patchwork.ozlabs.org; Tue, 17 Apr 2018 15:14:31 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:60204)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1f8W1T-0007Yj-Qr\n\tfor qemu-devel@nongnu.org; Tue, 17 Apr 2018 15:12:13 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1f8W1Q-0004il-Gr\n\tfor qemu-devel@nongnu.org; Tue, 17 Apr 2018 15:12:11 -0400","from mx3-rdu2.redhat.com ([66.187.233.73]:51346\n\thelo=mx1.redhat.com)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from ) id 1f8W1Q-0004iV-Ac\n\tfor qemu-devel@nongnu.org; Tue, 17 Apr 2018 15:12:08 -0400","from smtp.corp.redhat.com\n\t(int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby mx1.redhat.com (Postfix) with ESMTPS id 539FC4070214;\n\tTue, 17 Apr 2018 19:12:07 +0000 (UTC)","from [10.18.17.157] (dhcp-17-157.bos.redhat.com [10.18.17.157])\n\tby smtp.corp.redhat.com (Postfix) with ESMTP id AE5227C52;\n\tTue, 17 Apr 2018 19:12:04 +0000 (UTC)"],"To":"Eduardo Habkost , \"Michael S. Tsirkin\"\n\t","References":"<20170911165929.2791-3-marcandre.lureau@redhat.com>\n\t<20171009110336.GA17824@redhat.com>\n\t<20171009144344.38bbd1e9@nial.brq.redhat.com>\n\t<20171009130218.GK2954@redhat.com>\n\t<20171010003951-mutt-send-email-mst@kernel.org>\n\t<20171010083143.GA30015@redhat.com>\n\t\n\t<20171010150628.GI30015@redhat.com>\n\t<20171010180110.GI3246@localhost.localdomain>\n\t<20171015044800-mutt-send-email-mst@kernel.org>\n\t<20171020184820.GP2942@localhost.localdomain>","From":"Cole Robinson ","Message-ID":"","Date":"Tue, 17 Apr 2018 15:12:03 -0400","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.7.0","MIME-Version":"1.0","In-Reply-To":"<20171020184820.GP2942@localhost.localdomain>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","X-Scanned-By":"MIMEDefang 2.79 on 10.11.54.5","X-Greylist":["Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.11.55.5]);\n\tTue, 17 Apr 2018 19:12:07 +0000 (UTC)","inspected by milter-greylist-4.5.16 (mx1.redhat.com\n\t[10.11.55.5]); \n\tTue, 17 Apr 2018 19:12:07 +0000 (UTC) for IP:'10.11.54.5'\n\tDOMAIN:'int-mx05.intmail.prod.int.rdu2.redhat.com'\n\tHELO:'smtp.corp.redhat.com' FROM:'crobinso@redhat.com' RCPT:''"],"Content-Transfer-Encoding":"quoted-printable","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]\n\t[fuzzy]","X-Received-From":"66.187.233.73","Subject":"Re: [Qemu-devel] [PATCH v6 2/7] hw/misc: add vmcoreinfo device","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Igor Mammedov , Dave Anderson ,\n\t=?utf-8?q?Marc-Andr=C3=A9_Lureau?= ,\n\tQEMU , Laszlo Ersek ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1895193,"web_url":"http://patchwork.ozlabs.org/comment/1895193/","msgid":"<20180417211126.GD29865@localhost.localdomain>","list_archive_url":null,"date":"2018-04-17T21:11:26","subject":"Re: [Qemu-devel] [PATCH v6 2/7] hw/misc: add vmcoreinfo device","submitter":{"id":195,"url":"http://patchwork.ozlabs.org/api/people/195/","name":"Eduardo Habkost","email":"ehabkost@redhat.com"},"content":"On Tue, Apr 17, 2018 at 03:12:03PM -0400, Cole Robinson wrote:\n[...]\n> Reviving this... did any follow up changes happen?\n> \n> Marc-André patched virt-manager a few months back to enable -device\n> vmcoreinfo for new VMs:\n> \n> https://www.redhat.com/archives/virt-tools-list/2018-February/msg00020.html\n> \n> And I see there's at least a bug tracking adding this to openstack for\n> new VMs:\n> \n> https://bugzilla.redhat.com/show_bug.cgi?id=1555276\n> \n> If this feature doesn't really have any downsides, it would be nice to\n> get this tied to new machine types. Saves a lot of churn for higher\n> levels of the stack\n\nI understand this would be nice to have considering the existing\nstacks, but at the same time I would like the rest of the\nstack(s) to really try to not depend on QEMU machine-types to\ndefine policy/defaults.\n\nEvery feature that is hidden behind an opaque machine-type name\nand not visible in the domain XML and QEMU command-line increases\nthe risk of migration and compatibility bugs.\n\nThis was being discussed in a mail thread at:\nhttps://www.mail-archive.com/ovirt-devel@redhat.com/msg01196.html\n\nQuoting Daniel, on that thread:\n\n] Another case is the pvpanic device - while in theory that could\n] have been enabled by default for all guests, by QEMU or a config\n] generator library, doing so is not useful on its own. The hard\n] bit of the work is adding code to the mgmt app to choose the\n] action for when pvpanic triggers, and code to handle the results\n] of that action.\n\nFrom that comment, I understand that simply making QEMU create a\npvpanic device by default on pc-2.13+ won't be useful at all?","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","ozlabs.org;\n\tdmarc=fail (p=none dis=none) header.from=redhat.com"],"Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 40QdP10RFLz9rxx\n\tfor ;\n\tWed, 18 Apr 2018 07:17:09 +1000 (AEST)","from localhost ([::1]:35098 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1f8XyN-0000lt-2n\n\tfor incoming@patchwork.ozlabs.org; Tue, 17 Apr 2018 17:17:07 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:40302)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1f8Xt5-0005Az-SV\n\tfor qemu-devel@nongnu.org; Tue, 17 Apr 2018 17:11:41 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1f8Xt2-0006me-Cg\n\tfor qemu-devel@nongnu.org; Tue, 17 Apr 2018 17:11:39 -0400","from mx1.redhat.com ([209.132.183.28]:46078)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from ) id 1f8Xt2-0006dt-3C\n\tfor qemu-devel@nongnu.org; Tue, 17 Apr 2018 17:11:36 -0400","from smtp.corp.redhat.com\n\t(int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby mx1.redhat.com (Postfix) with ESMTPS id 463FC3133E80;\n\tTue, 17 Apr 2018 21:11:35 +0000 (UTC)","from localhost (ovpn-116-12.gru2.redhat.com [10.97.116.12])\n\tby smtp.corp.redhat.com (Postfix) with ESMTP id 52C817ED78;\n\tTue, 17 Apr 2018 21:11:27 +0000 (UTC)"],"Date":"Tue, 17 Apr 2018 18:11:26 -0300","From":"Eduardo Habkost ","To":"Cole Robinson ","Message-ID":"<20180417211126.GD29865@localhost.localdomain>","References":"<20171009144344.38bbd1e9@nial.brq.redhat.com>\n\t<20171009130218.GK2954@redhat.com>\n\t<20171010003951-mutt-send-email-mst@kernel.org>\n\t<20171010083143.GA30015@redhat.com>\n\t\n\t<20171010150628.GI30015@redhat.com>\n\t<20171010180110.GI3246@localhost.localdomain>\n\t<20171015044800-mutt-send-email-mst@kernel.org>\n\t<20171020184820.GP2942@localhost.localdomain>\n\t","MIME-Version":"1.0","Content-Type":"text/plain; charset=iso-8859-1","Content-Disposition":"inline","In-Reply-To":"","X-Fnord":"you can see the fnord","User-Agent":"Mutt/1.9.2 (2017-12-15)","X-Scanned-By":"MIMEDefang 2.79 on 10.5.11.15","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.46]);\n\tTue, 17 Apr 2018 21:11:35 +0000 (UTC)","Content-Transfer-Encoding":"quoted-printable","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]\n\t[fuzzy]","X-Received-From":"209.132.183.28","Subject":"Re: [Qemu-devel] [PATCH v6 2/7] hw/misc: add vmcoreinfo device","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"\"Michael S. Tsirkin\" , QEMU ,\n\tDave Anderson , =?iso-8859-1?q?Marc-Andr=E9?=\n\tLureau , Martin Kletzander\n\t, Igor Mammedov ,\n\tLaszlo Ersek ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1895234,"web_url":"http://patchwork.ozlabs.org/comment/1895234/","msgid":"","list_archive_url":null,"date":"2018-04-17T22:31:57","subject":"Re: [Qemu-devel] [PATCH v6 2/7] hw/misc: add vmcoreinfo device","submitter":{"id":3411,"url":"http://patchwork.ozlabs.org/api/people/3411/","name":"Cole Robinson","email":"crobinso@redhat.com"},"content":"On 04/17/2018 05:11 PM, Eduardo Habkost wrote:\n> On Tue, Apr 17, 2018 at 03:12:03PM -0400, Cole Robinson wrote:\n> [...]\n>> Reviving this... did any follow up changes happen?\n>>\n>> Marc-André patched virt-manager a few months back to enable -device\n>> vmcoreinfo for new VMs:\n>>\n>> https://www.redhat.com/archives/virt-tools-list/2018-February/msg00020.html\n>>\n>> And I see there's at least a bug tracking adding this to openstack for\n>> new VMs:\n>>\n>> https://bugzilla.redhat.com/show_bug.cgi?id=1555276\n>>\n>> If this feature doesn't really have any downsides, it would be nice to\n>> get this tied to new machine types. Saves a lot of churn for higher\n>> levels of the stack\n> \n> I understand this would be nice to have considering the existing\n> stacks, but at the same time I would like the rest of the\n> stack(s) to really try to not depend on QEMU machine-types to\n> define policy/defaults.\n> \n> Every feature that is hidden behind an opaque machine-type name\n> and not visible in the domain XML and QEMU command-line increases\n> the risk of migration and compatibility bugs.\n> \n\nWhat exactly is the migration compatibility issue with turning on the\nequivalent of -device vmcoreinfo for -M *-2.13+ ? Possibly prevents\nbackwards migration to older qemu but is that even a goal?\n\n> This was being discussed in a mail thread at:\n> https://www.mail-archive.com/ovirt-devel@redhat.com/msg01196.html\n> \n> Quoting Daniel, on that thread:\n> \n> ] Another case is the pvpanic device - while in theory that could\n> ] have been enabled by default for all guests, by QEMU or a config\n> ] generator library, doing so is not useful on its own. The hard\n> ] bit of the work is adding code to the mgmt app to choose the\n> ] action for when pvpanic triggers, and code to handle the results\n> ] of that action.\n> \n> From that comment, I understand that simply making QEMU create a\n> pvpanic device by default on pc-2.13+ won't be useful at all?\n> \n\nThis qemu-devel thread was about -device vmcoreinfo though, not pvpanic.\nvmcoreinfo doesn't need anything else to work AFAICT and shouldn't need\nany explicit config, heck it doesn't even have any -device properties.\n\nLike Dan says pvpanic isn't a 'just works' thing, and I know for windows\nVMs it shows up in device manager which has considerations for things\nlike SVVP. I think vmcoreinfo doesn't have the same impact\n\nThere are some guest visible things that we have turned on for new\nmachine types in the past, pveoi and x2apic comes to mind.\n\nThanks,\nCole","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","ozlabs.org;\n\tdmarc=fail (p=none dis=none) header.from=redhat.com"],"Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 40Qg4D6vn1z9s1d\n\tfor ;\n\tWed, 18 Apr 2018 08:32:43 +1000 (AEST)","from localhost ([::1]:39194 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1f8Z9V-0006Il-7W\n\tfor incoming@patchwork.ozlabs.org; Tue, 17 Apr 2018 18:32:41 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:53702)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1f8Z90-0006Hs-1x\n\tfor qemu-devel@nongnu.org; Tue, 17 Apr 2018 18:32:12 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1f8Z8v-0004zG-7H\n\tfor qemu-devel@nongnu.org; Tue, 17 Apr 2018 18:32:10 -0400","from mx3-rdu2.redhat.com ([66.187.233.73]:42770\n\thelo=mx1.redhat.com)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from ) id 1f8Z8v-0004xP-2K\n\tfor qemu-devel@nongnu.org; Tue, 17 Apr 2018 18:32:05 -0400","from smtp.corp.redhat.com\n\t(int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby mx1.redhat.com (Postfix) with ESMTPS id B76AB406E8B9;\n\tTue, 17 Apr 2018 22:32:02 +0000 (UTC)","from [10.18.17.157] (dhcp-17-157.bos.redhat.com [10.18.17.157])\n\tby smtp.corp.redhat.com (Postfix) with ESMTP id 844971C70F;\n\tTue, 17 Apr 2018 22:31:57 +0000 (UTC)"],"To":"Eduardo Habkost ","References":"<20171009144344.38bbd1e9@nial.brq.redhat.com>\n\t<20171009130218.GK2954@redhat.com>\n\t<20171010003951-mutt-send-email-mst@kernel.org>\n\t<20171010083143.GA30015@redhat.com>\n\t\n\t<20171010150628.GI30015@redhat.com>\n\t<20171010180110.GI3246@localhost.localdomain>\n\t<20171015044800-mutt-send-email-mst@kernel.org>\n\t<20171020184820.GP2942@localhost.localdomain>\n\t\n\t<20180417211126.GD29865@localhost.localdomain>","From":"Cole Robinson ","Message-ID":"","Date":"Tue, 17 Apr 2018 18:31:57 -0400","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.7.0","MIME-Version":"1.0","In-Reply-To":"<20180417211126.GD29865@localhost.localdomain>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","X-Scanned-By":"MIMEDefang 2.79 on 10.11.54.5","X-Greylist":["Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.11.55.7]);\n\tTue, 17 Apr 2018 22:32:02 +0000 (UTC)","inspected by milter-greylist-4.5.16 (mx1.redhat.com\n\t[10.11.55.7]); \n\tTue, 17 Apr 2018 22:32:02 +0000 (UTC) for IP:'10.11.54.5'\n\tDOMAIN:'int-mx05.intmail.prod.int.rdu2.redhat.com'\n\tHELO:'smtp.corp.redhat.com' FROM:'crobinso@redhat.com' RCPT:''"],"Content-Transfer-Encoding":"quoted-printable","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]\n\t[fuzzy]","X-Received-From":"66.187.233.73","Subject":"Re: [Qemu-devel] [PATCH v6 2/7] hw/misc: add vmcoreinfo device","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"\"Michael S. Tsirkin\" , Laszlo Ersek , \n\tQEMU , =?utf-8?q?Marc-Andr=C3=A9_Lureau?=\n\t, \tMartin Kletzander ,\n\tIgor Mammedov , Dave Anderson ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1895244,"web_url":"http://patchwork.ozlabs.org/comment/1895244/","msgid":"<20180417225354.GI29865@localhost.localdomain>","list_archive_url":null,"date":"2018-04-17T22:53:54","subject":"Re: [Qemu-devel] [PATCH v6 2/7] hw/misc: add vmcoreinfo device","submitter":{"id":195,"url":"http://patchwork.ozlabs.org/api/people/195/","name":"Eduardo Habkost","email":"ehabkost@redhat.com"},"content":"On Tue, Apr 17, 2018 at 06:31:57PM -0400, Cole Robinson wrote:\n> On 04/17/2018 05:11 PM, Eduardo Habkost wrote:\n> > On Tue, Apr 17, 2018 at 03:12:03PM -0400, Cole Robinson wrote:\n> > [...]\n> >> Reviving this... did any follow up changes happen?\n> >>\n> >> Marc-André patched virt-manager a few months back to enable -device\n> >> vmcoreinfo for new VMs:\n> >>\n> >> https://www.redhat.com/archives/virt-tools-list/2018-February/msg00020.html\n> >>\n> >> And I see there's at least a bug tracking adding this to openstack for\n> >> new VMs:\n> >>\n> >> https://bugzilla.redhat.com/show_bug.cgi?id=1555276\n> >>\n> >> If this feature doesn't really have any downsides, it would be nice to\n> >> get this tied to new machine types. Saves a lot of churn for higher\n> >> levels of the stack\n> > \n> > I understand this would be nice to have considering the existing\n> > stacks, but at the same time I would like the rest of the\n> > stack(s) to really try to not depend on QEMU machine-types to\n> > define policy/defaults.\n> > \n> > Every feature that is hidden behind an opaque machine-type name\n> > and not visible in the domain XML and QEMU command-line increases\n> > the risk of migration and compatibility bugs.\n> > \n> \n> What exactly is the migration compatibility issue with turning on the\n> equivalent of -device vmcoreinfo for -M *-2.13+ ? Possibly prevents\n> backwards migration to older qemu but is that even a goal?\n\nI mean the extra migration compatibility code that needs to be\nmaintained on older machine-types. It's extra maintenance burden\non both upstream and downstream QEMU trees.\n\n\n> \n> > This was being discussed in a mail thread at:\n> > https://www.mail-archive.com/ovirt-devel@redhat.com/msg01196.html\n> > \n> > Quoting Daniel, on that thread:\n> > \n> > ] Another case is the pvpanic device - while in theory that could\n> > ] have been enabled by default for all guests, by QEMU or a config\n> > ] generator library, doing so is not useful on its own. The hard\n> > ] bit of the work is adding code to the mgmt app to choose the\n> > ] action for when pvpanic triggers, and code to handle the results\n> > ] of that action.\n> > \n> > From that comment, I understand that simply making QEMU create a\n> > pvpanic device by default on pc-2.13+ won't be useful at all?\n> > \n> \n> This qemu-devel thread was about -device vmcoreinfo though, not pvpanic.\n> vmcoreinfo doesn't need anything else to work AFAICT and shouldn't need\n> any explicit config, heck it doesn't even have any -device properties.\n> \n> Like Dan says pvpanic isn't a 'just works' thing, and I know for windows\n> VMs it shows up in device manager which has considerations for things\n> like SVVP. I think vmcoreinfo doesn't have the same impact\n> \n\nOops, nevermind. I confused both.\n\n\n> There are some guest visible things that we have turned on for new\n> machine types in the past, pveoi and x2apic comes to mind.\n\nYes, we have tons of guest-visible things that we tie to the\nmachine-type. What I'm looking for is a solution to make this\nless frequent in the future.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","ozlabs.org;\n\tdmarc=fail (p=none dis=none) header.from=redhat.com"],"Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 40QgYM4FFgz9s19\n\tfor ;\n\tWed, 18 Apr 2018 08:54:30 +1000 (AEST)","from localhost ([::1]:40304 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1f8ZUa-0006Ae-Fz\n\tfor incoming@patchwork.ozlabs.org; Tue, 17 Apr 2018 18:54:28 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:35333)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1f8ZUD-00069R-3M\n\tfor qemu-devel@nongnu.org; Tue, 17 Apr 2018 18:54:06 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1f8ZU9-0006SX-64\n\tfor qemu-devel@nongnu.org; Tue, 17 Apr 2018 18:54:05 -0400","from mx1.redhat.com ([209.132.183.28]:50744)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from ) id 1f8ZU8-0006Qh-SU\n\tfor qemu-devel@nongnu.org; Tue, 17 Apr 2018 18:54:01 -0400","from smtp.corp.redhat.com\n\t(int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby mx1.redhat.com (Postfix) with ESMTPS id BF00E5D697;\n\tTue, 17 Apr 2018 22:53:59 +0000 (UTC)","from localhost (ovpn-116-12.gru2.redhat.com [10.97.116.12])\n\tby smtp.corp.redhat.com (Postfix) with ESMTP id 3D1987BE41;\n\tTue, 17 Apr 2018 22:53:56 +0000 (UTC)"],"Date":"Tue, 17 Apr 2018 19:53:54 -0300","From":"Eduardo Habkost ","To":"Cole Robinson ","Message-ID":"<20180417225354.GI29865@localhost.localdomain>","References":"<20171010003951-mutt-send-email-mst@kernel.org>\n\t<20171010083143.GA30015@redhat.com>\n\t\n\t<20171010150628.GI30015@redhat.com>\n\t<20171010180110.GI3246@localhost.localdomain>\n\t<20171015044800-mutt-send-email-mst@kernel.org>\n\t<20171020184820.GP2942@localhost.localdomain>\n\t\n\t<20180417211126.GD29865@localhost.localdomain>\n\t","MIME-Version":"1.0","Content-Type":"text/plain; charset=iso-8859-1","Content-Disposition":"inline","In-Reply-To":"","X-Fnord":"you can see the fnord","User-Agent":"Mutt/1.9.2 (2017-12-15)","X-Scanned-By":"MIMEDefang 2.79 on 10.5.11.13","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.39]);\n\tTue, 17 Apr 2018 22:53:59 +0000 (UTC)","Content-Transfer-Encoding":"quoted-printable","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]\n\t[fuzzy]","X-Received-From":"209.132.183.28","Subject":"Re: [Qemu-devel] [PATCH v6 2/7] hw/misc: add vmcoreinfo device","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"\"Michael S. Tsirkin\" , Laszlo Ersek , \n\tQEMU , =?iso-8859-1?q?Marc-Andr=E9?=\n\tLureau , Martin Kletzander\n\t, Igor Mammedov ,\n\tDave Anderson ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}}]