From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52781) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xr2EZ-00033D-KL for qemu-devel@nongnu.org; Wed, 19 Nov 2014 05:11:41 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xr2ET-0001wk-Eu for qemu-devel@nongnu.org; Wed, 19 Nov 2014 05:11:35 -0500 Received: from mx1.redhat.com ([209.132.183.28]:59976) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xr2ET-0001wT-7Y for qemu-devel@nongnu.org; Wed, 19 Nov 2014 05:11:29 -0500 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAJABSkv007956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 19 Nov 2014 05:11:28 -0500 From: Juan Quintela In-Reply-To: <20141119093320.GA26119@redhat.com> (Michael S. Tsirkin's message of "Wed, 19 Nov 2014 11:33:20 +0200") 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> Date: Wed, 19 Nov 2014 11:11:26 +0100 Message-ID: <87d28jo5yp.fsf@elfo.elfo> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH 2/5] exec: qemu_ram_alloc_device, qemu_ram_resize Reply-To: quintela@redhat.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Paolo Bonzini , qemu-devel@nongnu.org, dgilbert@redhat.com "Michael S. Tsirkin" wrote: > On Wed, Nov 19, 2014 at 10:19:22AM +0100, Juan Quintela wrote: >> >> I very much prefer to have >> >> user-controlled ACPI information (coming from the command-line) >> >> byte-for-byte identical for a given machine type. Patches for that have >> >> been on the list for almost two months, and it's not nice. >> >> >> >> Paolo >> > >> > I guess we just disagree on whether these patches will effectively achieve >> > this goal. For example, some people want to rewrite iasl bits, >> > generating everything in C. This will affect static bits too. >> > I don't want to make every single change in code conditional >> > on a machine type. >> >> You can't migrate with a different BIOS on destination, period. > > This claim is very wrong. > This would make is impossible to change BIOS bus without breaking > migration. Look at history of qemu, we change BIOS every release. And we should do: qemu -M pc-2.0 -L BIOS-2.0.bin And that way for every version and every bios. If they are the same, a symlink does. If they are not, different file. And we would not have this problems. I fully agree that we have problems with BIOS every relase. What we don't agree is _what_ is the best way to fix the issue. >> IMHO, b) is just asking for trouble. Being able to go from random >> changes to random changes look strange. > > Yes, it is hard to support. > But it's a required feature, and in fact, it's an existing one. >> Just think about it for a second. We are sending more data for some >> regions that it was allocated. And we just grow the regions and expect >> that everything is going to be ok. It is me, or this goes against every >> security discipline that I can think of? >> >> Later, Juan. > > We have many devices that just get N from stream, do malloc(N), then read > data from stream into it. > You think it's unsafe? Go ahead and fix them all. I am sure it is unsafe. Fixing them requires incompatible changes, that is the whole point :-( > However, my patch does address your concern: callers specify the upper > limit on the region size. > Trying to migrate in a 1Gbyte region Yes and no. You are assuming that a guest launched with a device ram size of 256KB receives a 512KB section and it knows what to do with it. It knows what to do with the 256KB section, with the 512KB answer is always a "perhaps". It depends of what is on the extra space. My solution would be that RAM/ROM sizes are always the same for migration, so destination would always understand it. It just forbids migrating between different machine types. And I think that is good, not bad. Later, Juan.