From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53013) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YShrC-00011B-4H for qemu-devel@nongnu.org; Tue, 03 Mar 2015 03:07:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YShr8-0003t9-0Z for qemu-devel@nongnu.org; Tue, 03 Mar 2015 03:07:10 -0500 Received: from mx1.redhat.com ([209.132.183.28]:56146) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YShr7-0003sn-OI for qemu-devel@nongnu.org; Tue, 03 Mar 2015 03:07:05 -0500 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t23875MV020818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Tue, 3 Mar 2015 03:07:05 -0500 Date: Tue, 3 Mar 2015 09:07:02 +0100 From: "Michael S. Tsirkin" Message-ID: <20150303080702.GA16187@redhat.com> References: <1424884133-323-1-git-send-email-imammedo@redhat.com> <1424884133-323-4-git-send-email-imammedo@redhat.com> <20150301150933.GA27190@redhat.com> <20150302180543.2b19cae4@nial.brq.redhat.com> <20150302210622.GA5028@redhat.com> <20150303120326.4c9e7298@voom.fritz.box> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150303120326.4c9e7298@voom.fritz.box> Subject: Re: [Qemu-devel] [PATCH V13 3/4] pc: add a Virtual Machine Generation ID device List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Gibson Cc: ghammer@redhat.com, Igor Mammedov , Laszlo , qemu-devel@nongnu.org On Tue, Mar 03, 2015 at 12:03:26PM +1100, David Gibson wrote: > On Mon, 2 Mar 2015 22:06:22 +0100 > "Michael S. Tsirkin" wrote: > > > On Mon, Mar 02, 2015 at 06:05:43PM +0100, Igor Mammedov wrote: > > > On Sun, 1 Mar 2015 16:09:33 +0100 > > > "Michael S. Tsirkin" wrote: > > > > > > > On Wed, Feb 25, 2015 at 05:08:52PM +0000, Igor Mammedov wrote: > > > > > Based on Microsoft's sepecifications (paper can be dowloaded from > > > > > http://go.microsoft.com/fwlink/?LinkId=260709), add a device > > > > > description to the SSDT ACPI table and its implementation. > > > > > > > > > > The GUID is set using "vmgenid.uuid" property. > > > > > > > > > > Example of using vmgenid device: > > > > > -device vmgenid,id=FOO,uuid="324e6eaf-d1d1-4bf6-bf41-b9bb6c91fb87" > > > > > > > > If you do this, doesn't windows then prompt for a driver? > > > it doesn't since PCI_CLASS_MEMORY_RAM is displayed as driver less > > > "PCI standard RAM Controller" binding in device manager. > > > > > > There was an issue with > > > virtio balloon device + pseries firmware + kernel bug > > > http://lists.gnu.org/archive/html/qemu-devel/2012-03/msg04704.html > > > but it shouldn't be an issue for x86 targets with which device is > > > supposed to be used. > > > CCing David and Laszlo in case UEFI might do some crazy stuff like > > > pseries firmware. > > > > I have to say, if it's not RAM, using PCI_CLASS_MEMORY_RAM seems > > wrong. Can't we tag it in ACPI in some way? > > I agree. PCI_CLASS_MEMORY_RAM means something quite specific, and this > device isn't it. AFAICT, this would break pseries guests exactly like > the balloon device did before we removed the bogus class code. > > I'm lacking context to see what the purpose of this device is, and > whether we could ever want something similar on ppc64. > > > I guess I can somewhat buy 0580 "other memory controller". > > > > I think we also want some space for future expansion > > in this device. > > How about we reserve first 4K, and set bit 0 to mean > > "has uuid"? > > > > -- > > MST > > > -- > David Gibson > Senior Software Engineer, Virtualization, Red Hat it just exposes a unique id as part of its BAR.