From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56771) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vo7wp-0006R7-Oq for qemu-devel@nongnu.org; Wed, 04 Dec 2013 03:36:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vo7wj-00005p-OX for qemu-devel@nongnu.org; Wed, 04 Dec 2013 03:36:43 -0500 Date: Wed, 4 Dec 2013 10:40:04 +0200 From: "Michael S. Tsirkin" Message-ID: <20131204084004.GA8344@redhat.com> References: <1386087086-3691-1-git-send-email-mst@redhat.com> <1386087086-3691-8-git-send-email-mst@redhat.com> <20131203204139.GA5670@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH 07/23] hw/pci/pcie_aer.c: fix buffer overruns on invalid state load List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: QEMU Developers , Anthony Liguori , qemu-stable On Tue, Dec 03, 2013 at 08:59:52PM +0000, Peter Maydell wrote: > On 3 December 2013 20:41, Michael S. Tsirkin wrote: > > On Tue, Dec 03, 2013 at 06:30:46PM +0000, Peter Maydell wrote: > >> On 3 December 2013 16:28, Michael S. Tsirkin wrote: > >> > const VMStateDescription vmstate_pcie_aer_log = { > >> > .name = "PCIE_AER_ERROR_LOG", > >> > .version_id = 1, > >> > .minimum_version_id = 1, > >> > .minimum_version_id_old = 1, > >> > + .post_load = pcie_aer_state_post_load, > >> > .fields = (VMStateField[]) { > >> > VMSTATE_UINT16(log_num, PCIEAERLog), > >> > - VMSTATE_UINT16(log_max, PCIEAERLog), > >> > - VMSTATE_STRUCT_VARRAY_POINTER_UINT16(log, PCIEAERLog, log_num, > >> > + VMSTATE_UINT16_EQUAL(log_max, PCIEAERLog), > >> > + VMSTATE_STRUCT_VARRAY_POINTER_UINT16(log, PCIEAERLog, log_max, > >> > vmstate_pcie_aer_err, PCIEAERErr), > >> > VMSTATE_END_OF_LIST() > >> > } > >> > >> Isn't this a migration compability break? > > > > How is it a break? > > If a QEMU with this patch sends data to a QEMU without it, then the > receiving end will think it should expect log_num array entries but the > sending end is going to send log_max of them. Conversely, an old->new > migration is going to send fewer array entries than the destination > expects. Or have I misinterpreted how the VARRAY entries work? > > thanks > -- PMM Ah, got it. You are right, good catch. I think we need VMSTATE_UINT16_LE, this will make sure log_num <= log_max without changing VMSTATE_STRUCT_VARRAY size.