From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36736) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0WKs-00047W-8M for qemu-devel@nongnu.org; Tue, 07 Jan 2014 08:04:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W0WKm-0002h8-69 for qemu-devel@nongnu.org; Tue, 07 Jan 2014 08:04:46 -0500 Received: from cantor2.suse.de ([195.135.220.15]:42372 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0WKl-0002h2-R3 for qemu-devel@nongnu.org; Tue, 07 Jan 2014 08:04:40 -0500 Message-ID: <52CBFB63.6000706@suse.de> Date: Tue, 07 Jan 2014 14:04:35 +0100 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <1385718225-26379-1-git-send-email-armbru@redhat.com> <1385718225-26379-2-git-send-email-armbru@redhat.com> <52AE1752.2080605@suse.de> <87k3f5mb9x.fsf@blackfin.pond.sub.org> <52CBF412.2030806@suse.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 1/2] hw: cannot_instantiate_with_device_add_yet due to pointer props List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Marcel Apfelbaum , "Michael S. Tsirkin" , QEMU Developers , Fabien Chouteau , Markus Armbruster , Blue Swirl , Gerd Hoffmann , Anthony Liguori , "Edgar E. Iglesias" Am 07.01.2014 13:43, schrieb Peter Maydell: > On 7 January 2014 12:33, Andreas F=C3=A4rber wrote: >> Am 16.12.2013 10:33, schrieb Peter Maydell: >>> Anyway, I don't actively object to this series. I just think >>> Anthony's going in the wrong direction which is why I haven't >>> been particularly eager to actively mark it as reviewed-by me >>> either... >> >> Sorry for not taking the time to reply to these concerns earlier. I >> thought it was self-speaking that the enterprise Linux distributors >> among us want a safeguard to avoid customers from crashing a >> long-running VM with some avoidable device_add. >=20 > Sure. I think the right way to do that is to only allow > them to plug in devices that are truly pluggable (ie which > are on some pluggable bus like PCI or USB), rather than > this way round, which is trying to blacklist devices rather > than whitelist bus types. >=20 > In short, we shouldn't be trying to cram all of "hotplug", > "I want an extra PCI card in my VM" and "I want to do > complete from-scratch construction of a machine model > including wiring up all the interrupts and defining the > memory map" into the same interface, because the flexibility > you need for the last one of these is going to cause endless > user errors when attempting the first two. Agreed that there may be better solutions. But in qemu.git we do have a lengthy, inconsistent blacklist, which is only partially honored. Markus refactored the blacklist to be less inconsistent, less lengthy. In particular I like that the previous/base series makes it clear not to mark individual PHBs as no_user, something that has come up in my PReP review. Your ARM device patches have also benefited, I believe. Like I said, this doesn't rule out switching to a whitelist later. His patchset has been on the list for quite a while and no one has actually submitted code for a different solution, yourself included. So if I get to choose between an acceptable sparrow on-list and the pigeon on the roof ... ;) That said, I have been sprouting the idea of, e.g., QOM'ifying qemu_irq in-place (rather than waiting for Pin concept), which would tackle half of the SysBus problem. QOM'ifying MemoryRegions would be the other half. Volunteers welcome, I am still not done with QOM realize and CPUState. Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg