From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49695) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xr8Ya-0007fC-OD for qemu-devel@nongnu.org; Wed, 19 Nov 2014 11:56:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xr8YR-0004S4-MN for qemu-devel@nongnu.org; Wed, 19 Nov 2014 11:56:40 -0500 Received: from mail-wi0-x229.google.com ([2a00:1450:400c:c05::229]:53436) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xr8YR-0004Rt-Eq for qemu-devel@nongnu.org; Wed, 19 Nov 2014 11:56:31 -0500 Received: by mail-wi0-f169.google.com with SMTP id r20so9532239wiv.2 for ; Wed, 19 Nov 2014 08:56:30 -0800 (PST) Sender: Paolo Bonzini Message-ID: <546CCBBB.4040000@redhat.com> Date: Wed, 19 Nov 2014 17:56:27 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1416254843-16859-1-git-send-email-mst@redhat.com> <1416254843-16859-3-git-send-email-mst@redhat.com> <546AE14E.7060606@redhat.com> <20141118074904.GA19745@redhat.com> <87y4r7o8dh.fsf@elfo.elfo> <20141119093320.GA26119@redhat.com> <87d28jo5yp.fsf@elfo.elfo> <20141119102136.GC26395@redhat.com> <878uj7o4ec.fsf@elfo.elfo> <20141119132851.GA27435@redhat.com> <546C9EC0.5000105@redhat.com> <87ioibmgx6.fsf@elfo.elfo> <546CA726.4090502@redhat.com> <87k32rkuu9.fsf@elfo.elfo> In-Reply-To: <87k32rkuu9.fsf@elfo.elfo> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH 2/5] exec: qemu_ram_alloc_device, qemu_ram_resize List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: quintela@redhat.com Cc: "Michael S. Tsirkin" , qemu-devel@nongnu.org, dgilbert@redhat.com On 19/11/2014 17:39, Juan Quintela wrote: > Paolo Bonzini wrote: >> On 19/11/2014 14:57, Juan Quintela wrote: >>>> Shipping a separate BIOS for different machine types is unrealistic and >>>> pointless. It would also be a good terrain for bug reports, unless you >>>> also do things like "forbid creating -device megasas-gen2 on 2.1 because >>>> it was introduced in 2.2". >>> >>> And I agree with that. If it got introduced on 2.2, it should not be >>> allowed on pc-2.1. It just makes things more complicated. >> >> Weird, I have bought this USB device last month and I plugged it into a >> two-year-old laptop. >> >> QEMU version = when did I last update firmware / buy hardware >> Machine type = when did I buy the computer > > It is not the same, and you know it. > It is the equivalent: I have this aging pc with PCI and I have bought > this PCI-EXpress card, if I use enough force, perhaps it could work. Hmm, no. My example is megasas-gen2. You can certainly say "I have bought this PCI HBA last month and I plugged it into a two-year-old desktop". It's irrelevant that we model most PCIe devices we emulate as PCI, just because our main machine type is PCI. It's irrelevant because it's the same for a pc-2.2 machine type, it doesn't depend on the machine type. There's nothing in an external device that affects the stability of machine types. > Enough force here would mean put some soldering here and there, new > chips, blah, blah, blah. While the machine is running. So you've moved the goal post to hotplug after migration from 2.1 to 2.2? No problem, I can certainly hotplug a new PCI HBA into a two-year-old running server, if the server supports hotplug. > It is not that I am not giving you one option to fix the problem, it is > a different solution. Mine don't require changing anything, just forbid > something that now it is allowed, and that we have found difficult to > support. Sorry, I think this is not true. It's hard, yes. But life is hard. There's nothing in this that we have found difficult to support. It's just code that someone has to write. Paolo