From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36364) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VEBZi-0005Cl-40 for qemu-devel@nongnu.org; Tue, 27 Aug 2013 01:12:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VEBZW-0000Q1-Th for qemu-devel@nongnu.org; Tue, 27 Aug 2013 01:12:18 -0400 Received: from e23smtp08.au.ibm.com ([202.81.31.141]:34776) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VEBZW-0000Pb-Aj for qemu-devel@nongnu.org; Tue, 27 Aug 2013 01:12:06 -0400 Received: from /spool/local by e23smtp08.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 27 Aug 2013 15:08:46 +1000 From: Nikunj A Dadhania In-Reply-To: <521B5B49.9080001@redhat.com> References: <1377249737-12570-1-git-send-email-aik@ozlabs.ru> <24C2B209-2082-4AF8-A8FB-1FF8A8B7751B@suse.de> <1377468637.3819.27.camel@pasglop> <87vc2tysur.fsf@linux.vnet.ibm.com> <1377497959.3819.36.camel@pasglop> <87li3ozura.fsf@linux.vnet.ibm.com> <521B5B49.9080001@redhat.com> Date: Tue, 27 Aug 2013 10:41:47 +0530 Message-ID: <8761urbtv0.fsf@abhimanyu.in.ibm.com> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH] spapr-vscsi: Adding VSCSI capabilities List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Alexey Kardashevskiy , qemu-ppc@nongnu.org, Alexander Graf , qemu-devel@nongnu.org Paolo Bonzini writes: > Il 26/08/2013 11:06, Nikunj A Dadhania ha scritto: >>>> + fprintf(stderr, "vscsi_send_capabilities: size out of bound !\n"); >>>> + goto error_out; >>>> + } >>> >>> I am not 100% familiar with the protocol, could it be that we should >>> just read sizeof(cap) instead of erroring out or is there no way it >>> can be correct and have a len too long ? >> >> If the length is incorrect, can we trust whether cap is correct or is of >> the type we are expecting? > > We shouldn't care, it'd be a guest bug. Then we can do a warning on the size and set only the parts supported. This is a kind of negotiating capabilities, where the guest says that I can support following vscsi capabilities, hypervisor if it has implemented them should return back with affirmative for the capabilities supported. If not, tell the guest that hypervisor cannot support. > > If the guest is asking for say 1024 bytes, we do not have to fill all of > them. It is in principle possible that a subsequent revision of vscsi > will make the struct larger; perhaps a bit in the first part of the > struct will tell the guest if the second part has been filled. > > Unless the spec explicitly say the opposite, I would just zero the bytes > between sizeof(cap) and len. Makes sense. I will change the patch accordingly. Regards Nikunj