From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:38379)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1cCljs-00065G-7Y
	for qemu-devel@nongnu.org; Fri, 02 Dec 2016 06:10:49 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1cCljn-0003mW-8x
	for qemu-devel@nongnu.org; Fri, 02 Dec 2016 06:10:48 -0500
Received: from mx1.redhat.com ([209.132.183.28]:40450)
	by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)
	(Exim 4.71) (envelope-from <kraxel@redhat.com>) id 1cCljn-0003m4-3n
	for qemu-devel@nongnu.org; Fri, 02 Dec 2016 06:10:43 -0500
Message-ID: <1480677038.13905.9.camel@redhat.com>
From: Gerd Hoffmann <kraxel@redhat.com>
Date: Fri, 02 Dec 2016 12:10:38 +0100
In-Reply-To: <20161201170624.26496-3-lersek@redhat.com>
References: <20161201170624.26496-1-lersek@redhat.com>
	<20161201170624.26496-3-lersek@redhat.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH v4 2/7] fw-cfg: turn FW_CFG_FILE_SLOTS into
 a device property
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel/>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Laszlo Ersek <lersek@redhat.com>
Cc: qemu devel list <qemu-devel@nongnu.org>, "Gabriel L. Somlo" <somlo@cmu.edu>, "Michael S. Tsirkin" <mst@redhat.com>, Igor Mammedov <imammedo@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>

On Do, 2016-12-01 at 18:06 +0100, Laszlo Ersek wrote:
> We'd like to raise the value of FW_CFG_FILE_SLOTS. Doing it naively could
> lead to problems with backward migration: a more recent QEMU (running an
> older machine type) would allow the guest, in fw_cfg_select(), to select =
a
> high key value that is unavailable in the same machine type implemented b=
y
> the older (target) QEMU.

I don't think we need this.  fw_cfg changes are guest-visible so they
must not happen for a given machine type.  So if current machine types
don't hit the limit that should continue to be the case even if we
simply raise FW_CFG_FILE_SLOTS.

But we have to take care that new files show up on new machine types
only.

cheers,
  Gerd