From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42873) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XC2Mu-0005eU-MZ for qemu-devel@nongnu.org; Tue, 29 Jul 2014 04:02:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XC2Mo-0001vS-2Y for qemu-devel@nongnu.org; Tue, 29 Jul 2014 04:02:44 -0400 Received: from mx1.redhat.com ([209.132.183.28]:25638) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XC2Mn-0001vM-RO for qemu-devel@nongnu.org; Tue, 29 Jul 2014 04:02:37 -0400 Date: Tue, 29 Jul 2014 09:02:28 +0100 From: "Dr. David Alan Gilbert" Message-ID: <20140729080227.GB2495@work-vm> References: <1406561650-29995-1-git-send-email-mst@redhat.com> <20140728165227.GH2420@work-vm> <20140728190757.GA31576@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140728190757.GA31576@redhat.com> Subject: Re: [Qemu-devel] [PATCH 1/3] loader: add support for resizeable blobs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Alexander Graf , quintela@redhat.com, Alexey Kardashevskiy , Markus Armbruster , qemu-devel@nongnu.org, Gerd Hoffmann , pbonzini@redhat.com, imammedo@redhat.com, Laszlo Ersek , =?us-ascii?B?PT9VVEYtOD9xP0FuZHJlYXM9MjBGPUMzPUE0cmJlcj89?= * Michael S. Tsirkin (mst@redhat.com) wrote: > On Mon, Jul 28, 2014 at 05:52:27PM +0100, Dr. David Alan Gilbert wrote: > > * Michael S. Tsirkin (mst@redhat.com) wrote: > > > Support resizeable blobs: we allocate more memory than currently > > > available in the blob, which can later be filled in. > > > > > > Signed-off-by: Michael S. Tsirkin > > > --- > > > include/hw/loader.h | 14 +++++++-- > > > include/hw/nvram/fw_cfg.h | 2 +- > > > hw/core/loader.c | 15 +++++---- > > > hw/nvram/fw_cfg.c | 79 ++++++++++++++++++++++++++++++++++++++++++++--- > > > 4 files changed, 96 insertions(+), 14 deletions(-) > > > > > > > > > > +static bool fw_cfg_len_needed(void *opaque, int version_id) > > > +{ > > > + FWCfgState *s = FW_CFG(opaque); > > > + int i, j; > > > + > > > + for (i = 0; i < ARRAY_SIZE(s->entries); ++i) { > > > + for (j = 0; j < ARRAY_SIZE(s->entries[0]); ++j) { > > > + if (s->entries[i][j].len != s->entries[i][j].max_len) { > > > + return true; > > > + } > > > + } > > > + } > > > + > > > + return false; > > > +} > > > > This feels a bit delicate; it means that increasing the 'max_len' changes > > the expected migration stream, which seems odd for a parameter whose > > job is to make things easier to migrate. > > > > Dave > > It's an API issue - so you are more comfortable with > an explicit flag? Yes, if it was something that was just switched on with new machine types I wouldn't worry as much. Dave > > > > + > > > static const VMStateDescription vmstate_fw_cfg = { > > > .name = "fw_cfg", > > > .version_id = 2, > > > .minimum_version_id = 1, > > > + .post_load = fw_cfg_post_load, > > > + .pre_save = fw_cfg_pre_save, > > > .fields = (VMStateField[]) { > > > VMSTATE_UINT16(cur_entry, FWCfgState), > > > VMSTATE_UINT16_HACK(cur_offset, FWCfgState, is_version_1), > > > VMSTATE_UINT32_V(cur_offset, FWCfgState, 2), > > > + VMSTATE_ARRAY_TEST(len, FWCfgState, FW_CFG_LEN_ENTRIES, > > > + fw_cfg_len_needed, > > > + vmstate_info_uint32, uint32_t), > > > VMSTATE_END_OF_LIST() > > > } > > > }; > > > @@ -388,23 +449,28 @@ static const VMStateDescription vmstate_fw_cfg = { > > > static void fw_cfg_add_bytes_read_callback(FWCfgState *s, uint16_t key, > > > FWCfgReadCallback callback, > > > void *callback_opaque, > > > - void *data, size_t len) > > > + void *data, size_t len, > > > + size_t max_len) > > > { > > > int arch = !!(key & FW_CFG_ARCH_LOCAL); > > > > > > + assert(len <= max_len); > > > + > > > key &= FW_CFG_ENTRY_MASK; > > > > > > assert(key < FW_CFG_MAX_ENTRY && len < UINT32_MAX); > > > > > > s->entries[arch][key].data = data; > > > s->entries[arch][key].len = (uint32_t)len; > > > + s->entries[arch][key].reset_len = (uint32_t)len; > > > + s->entries[arch][key].max_len = (uint32_t)max_len; > > > s->entries[arch][key].read_callback = callback; > > > s->entries[arch][key].callback_opaque = callback_opaque; > > > } > > > > > > void fw_cfg_add_bytes(FWCfgState *s, uint16_t key, void *data, size_t len) > > > { > > > - fw_cfg_add_bytes_read_callback(s, key, NULL, NULL, data, len); > > > + fw_cfg_add_bytes_read_callback(s, key, NULL, NULL, data, len, len); > > > } > > > > > > void fw_cfg_add_string(FWCfgState *s, uint16_t key, const char *value) > > > @@ -454,13 +520,15 @@ void fw_cfg_add_callback(FWCfgState *s, uint16_t key, FWCfgCallback callback, > > > > > > s->entries[arch][key].data = data; > > > s->entries[arch][key].len = (uint32_t)len; > > > + s->entries[arch][key].reset_len = (uint32_t)len; > > > + s->entries[arch][key].max_len = (uint32_t)len; > > > s->entries[arch][key].callback_opaque = callback_opaque; > > > s->entries[arch][key].callback = callback; > > > } > > > > > > void fw_cfg_add_file_callback(FWCfgState *s, const char *filename, > > > FWCfgReadCallback callback, void *callback_opaque, > > > - void *data, size_t len) > > > + void *data, size_t len, size_t max_len) > > > { > > > int i, index; > > > size_t dsize; > > > @@ -475,7 +543,8 @@ void fw_cfg_add_file_callback(FWCfgState *s, const char *filename, > > > assert(index < FW_CFG_FILE_SLOTS); > > > > > > fw_cfg_add_bytes_read_callback(s, FW_CFG_FILE_FIRST + index, > > > - callback, callback_opaque, data, len); > > > + callback, callback_opaque, data, len, > > > + max_len); > > > > > > pstrcpy(s->files->f[index].name, sizeof(s->files->f[index].name), > > > filename); > > > @@ -496,7 +565,7 @@ void fw_cfg_add_file_callback(FWCfgState *s, const char *filename, > > > void fw_cfg_add_file(FWCfgState *s, const char *filename, > > > void *data, size_t len) > > > { > > > - fw_cfg_add_file_callback(s, filename, NULL, NULL, data, len); > > > + fw_cfg_add_file_callback(s, filename, NULL, NULL, data, len, len); > > > } > > > > > > static void fw_cfg_machine_ready(struct Notifier *n, void *data) > > > -- > > > MST > > > > > > > > -- > > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK