From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43601) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WG30M-0004T4-G1 for qemu-devel@nongnu.org; Wed, 19 Feb 2014 03:59:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WG30F-0001Oq-S8 for qemu-devel@nongnu.org; Wed, 19 Feb 2014 03:59:46 -0500 Received: from mx1.redhat.com ([209.132.183.28]:10711) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WG30F-0001OW-IN for qemu-devel@nongnu.org; Wed, 19 Feb 2014 03:59:39 -0500 Date: Wed, 19 Feb 2014 09:59:34 +0100 From: Igor Mammedov Message-ID: <20140219095934.6b63a947@nial.usersys.redhat.com> In-Reply-To: <5303D8DD.6080101@redhat.com> References: <1391777496-3882-1-git-send-email-imammedo@redhat.com> <20140216155345.GH30056@redhat.com> <1392625955.26953.12.camel@nilsson.home.kraxel.org> <20140218173644.78ecd8c1@nial.usersys.redhat.com> <5303D8DD.6080101@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC 0/9] generate dynamic _CRS for motherboard resources List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laszlo Ersek Cc: "Michael S. Tsirkin" , Gerd Hoffmann , anthony@codemonkey.ws, qemu-devel@nongnu.org On Tue, 18 Feb 2014 23:04:13 +0100 Laszlo Ersek wrote: > On 02/18/14 17:36, Igor Mammedov wrote: > > On Mon, 17 Feb 2014 09:32:35 +0100 > > Gerd Hoffmann wrote: > > > >> On So, 2014-02-16 at 17:53 +0200, Michael S. Tsirkin wrote: > >>> On Fri, Feb 07, 2014 at 01:51:27PM +0100, Igor Mammedov wrote: > >>>> Since introduction of PCIHP, it became problematic to > >>>> punch hole in PCI0._CRS statically since PCI hotplug > >>>> region size became runtime changeable. > >>> > >>> What makes it runtime changeable? > >> > >> machine type. q35 / piix map them at different locations. > >> > >> Also we might want to this also for devices which are > >> runtime-configurable (isa-debugcon, pvpanic, ...). > > I'd convert simple devices that conditionally enabled at > > startup time, from static definition + patching into > > completely dynamically generated when device present. > > For example pvpanic falls in to this category. > > > > That would result in smaller ACPI tables guest has to deal with. > > I could be mistaken, but AFAIR this caused the windows device manager to > pop up in windows? Ie. if you have a windows guest and cold-boot it > twice, once with the device present (generated into ACPI) and once with > the device absent (not generated into ACPI), then you get hardware > changes. Whereas, if the device is always present and you only patch > _STA, then windows doesn't perceive it as a hw change. Is is irrelevant whether device is statically or dynamically created, user will face the same issue and has a choice to install driver or tell windows to ignore device forever. > Do I recall it right?... Device manager pop-ups only once when new device is added to install driver. If later, the device in the same location with the same id appears/disappears, Device manager handles it silently. > > You could argue that "a new device indeed warrants a device manager > popup", but esp. for isa-debugcon and pvpanic, you might want to enable > those opportunistically, without triggering a new hw dialog. Pvpanic > triggering the device manager was exactly what drew frowns, for its > original implementation. IIRC. the above applies to these cases as well, i.e. if you install driver for it then there won't be any pop-ups later. If there is no driver (which is the case) one needs to tell to Device manager to ignore this device, and then there shouldn't be an additional pop-ups later. > Anyway pls. feel free to ignore this comment, it just crossed my mind. > (And of course it's not related to your series.) > > Thanks > Laszlo >