From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N8Laf-0005J9-5M for qemu-devel@nongnu.org; Wed, 11 Nov 2009 17:23:01 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N8Laa-0005Bw-7v for qemu-devel@nongnu.org; Wed, 11 Nov 2009 17:23:00 -0500 Received: from [199.232.76.173] (port=35582 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N8LaZ-0005Bg-U5 for qemu-devel@nongnu.org; Wed, 11 Nov 2009 17:22:56 -0500 Received: from mail-qy0-f194.google.com ([209.85.221.194]:39978) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N8LaZ-0006y3-Ke for qemu-devel@nongnu.org; Wed, 11 Nov 2009 17:22:55 -0500 Received: by qyk32 with SMTP id 32so758177qyk.4 for ; Wed, 11 Nov 2009 14:22:54 -0800 (PST) Message-ID: <4AFB393B.4020200@codemonkey.ws> Date: Wed, 11 Nov 2009 16:22:51 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <1257962966-22902-1-git-send-email-agraf@suse.de> <1257962966-22902-2-git-send-email-agraf@suse.de> <4AFB324E.7020607@codemonkey.ws> <4AFB376D.2020106@suse.de> In-Reply-To: <4AFB376D.2020106@suse.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 1/6] Make fw_cfg interface 32-bit aware List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: glommer@redhat.com, Juan Quintela , qemu-devel@nongnu.org, avi@redhat.com Alexander Graf wrote: > Anthony Liguori wrote: > >> Alexander Graf wrote: >> >>> The fw_cfg interface can only handle up to 16 bits of data for its >>> streams. >>> While that isn't too much of a problem when handling integers, we would >>> like to stream full kernel images over that interface! >>> >>> So let's extend it to 32 bit length variables. >>> >>> Signed-off-by: Alexander Graf >>> --- >>> hw/fw_cfg.c | 8 ++++---- >>> hw/fw_cfg.h | 2 +- >>> 2 files changed, 5 insertions(+), 5 deletions(-) >>> >>> diff --git a/hw/fw_cfg.c b/hw/fw_cfg.c >>> index a6d811b..3a3f694 100644 >>> --- a/hw/fw_cfg.c >>> +++ b/hw/fw_cfg.c >>> @@ -39,7 +39,7 @@ >>> #define FW_CFG_SIZE 2 >>> >>> typedef struct _FWCfgEntry { >>> - uint16_t len; >>> + uint32_t len; >>> uint8_t *data; >>> void *callback_opaque; >>> FWCfgCallback callback; >>> @@ -48,7 +48,7 @@ typedef struct _FWCfgEntry { >>> typedef struct _FWCfgState { >>> FWCfgEntry entries[2][FW_CFG_MAX_ENTRY]; >>> uint16_t cur_entry; >>> - uint16_t cur_offset; >>> + uint32_t cur_offset; >>> } FWCfgState; >>> >>> static void fw_cfg_write(FWCfgState *s, uint8_t value) >>> @@ -171,12 +171,12 @@ static const VMStateDescription vmstate_fw_cfg = { >>> .minimum_version_id_old = 1, >>> .fields = (VMStateField []) { >>> VMSTATE_UINT16(cur_entry, FWCfgState), >>> - VMSTATE_UINT16(cur_offset, FWCfgState), >>> + VMSTATE_UINT32(cur_offset, FWCfgState), >>> VMSTATE_END_OF_LIST() >>> } >>> }; >>> >>> -int fw_cfg_add_bytes(void *opaque, uint16_t key, uint8_t *data, >>> uint16_t len) >>> +int fw_cfg_add_bytes(void *opaque, uint16_t key, uint8_t *data, >>> uint32_t len) >>> { >>> FWCfgState *s = opaque; >>> int arch = !!(key & FW_CFG_ARCH_LOCAL); >>> >>> >> We need to bump a version here. >> > > Sure - which one? > The version_id field in vmstate_fw_cfg. You also have to try to support older versions which means you may want to either split cur_offset into a high and low or ask Juan what the appropriate vodoo would be. Regards, Anthony Liguori > Alex >