From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1N8LTB-0002WX-P0
	for qemu-devel@nongnu.org; Wed, 11 Nov 2009 17:15:17 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1N8LT6-0002OH-TV
	for qemu-devel@nongnu.org; Wed, 11 Nov 2009 17:15:17 -0500
Received: from [199.232.76.173] (port=50562 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1N8LT6-0002O1-Ib
	for qemu-devel@nongnu.org; Wed, 11 Nov 2009 17:15:12 -0500
Received: from cantor.suse.de ([195.135.220.2]:54134 helo=mx1.suse.de)
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60)
	(envelope-from <agraf@suse.de>) id 1N8LT6-0005uj-7l
	for qemu-devel@nongnu.org; Wed, 11 Nov 2009 17:15:12 -0500
Message-ID: <4AFB376D.2020106@suse.de>
Date: Wed, 11 Nov 2009 23:15:09 +0100
From: Alexander Graf <agraf@suse.de>
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>
In-Reply-To: <4AFB324E.7020607@codemonkey.ws>
Content-Type: text/plain; charset=ISO-8859-1
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: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: glommer@redhat.com, qemu-devel@nongnu.org, avi@redhat.com

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 <agraf@suse.de>
>> ---
>>  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?


Alex