All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
Cc: Alexey Kardashevskiy <aik@ozlabs.ru>,
	qemu-ppc@nongnu.org, Alexander Graf <agraf@suse.de>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] spapr-vscsi: Adding VSCSI capabilities
Date: Mon, 26 Aug 2013 15:42:33 +0200	[thread overview]
Message-ID: <521B5B49.9080001@redhat.com> (raw)
In-Reply-To: <87li3ozura.fsf@linux.vnet.ibm.com>

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.

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.

Paolo

  reply	other threads:[~2013-08-26 13:43 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-23  9:22 [Qemu-devel] [PATCH] spapr-vscsi: Adding VSCSI capabilities Alexey Kardashevskiy
2013-08-25 16:41 ` Alexander Graf
2013-08-25 20:51   ` Benjamin Herrenschmidt
2013-08-26 13:37     ` Paolo Bonzini
2013-08-27  0:45       ` Benjamin Herrenschmidt
2013-08-25 22:10   ` Benjamin Herrenschmidt
2013-08-26  4:32     ` Nikunj A Dadhania
2013-08-26  5:44       ` Alexander Graf
2013-08-26  6:22         ` Benjamin Herrenschmidt
2013-08-26  8:43           ` Alexander Graf
2013-08-26  9:08             ` Nikunj A Dadhania
2013-08-26  9:52               ` Alexander Graf
2013-08-26 10:03             ` Benjamin Herrenschmidt
2013-08-26 10:47         ` Nikunj A Dadhania
2013-08-26 10:58         ` Nikunj A Dadhania
2013-08-26 11:17           ` Alexander Graf
2013-08-26 11:46             ` Nikunj A Dadhania
2013-08-26 11:49               ` Alexander Graf
2013-08-27  5:14                 ` Nikunj A Dadhania
2013-08-27  5:43                 ` Nikunj A Dadhania
2013-08-27  8:45                   ` Alexander Graf
2013-08-27  9:27                     ` Nikunj A Dadhania
2013-08-26  6:19       ` Benjamin Herrenschmidt
2013-08-26  9:06         ` Nikunj A Dadhania
2013-08-26 13:42           ` Paolo Bonzini [this message]
2013-08-27  5:11             ` Nikunj A Dadhania

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=521B5B49.9080001@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=agraf@suse.de \
    --cc=aik@ozlabs.ru \
    --cc=nikunj@linux.vnet.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.