Re: [PATCH RFC 10/15] hw/virtio/vhost-shadow-virtqueue: range boundary in translation

[Hanna Czenczek <hreitz@redhat.com>]

On 08.08.26 07:52, Connor Kite wrote:
> On Mon, Aug 3, 2026 at 5:56 AM Hanna Czenczek <hreitz@redhat.com> wrote:
>>
>> It’s not immediately obvious what is ensuring that `iov_len` can never
>> be 0. Sure, it would be wrong and makes no sense, but that is why I
>> think an `assert(iovec[i].iov_len > 0)` would be appropriate.
>>
>> (Looks like `virtqueue_map_desc()` is what rejects zero length, but that
>> is not really local to this code path, so not immediately obvious.)
>>
>> Hanna
>>
>  From the QEMU Coding Style guidelines on error-handling it looks like
> errors that
> could be initiated by a malfunctioning guest should not cause Qemu to
> exit. Would it be
> more appropriate to return false when zero-length is detected?  That follows
> the existing error path returning up to vhost_handle_guest_kick, which
> renders the svq
> unresponsive to future kicks.

Sure, but it’s necessary only *if* a malfunctioning guest could cause 
this. As I said, it looks like `virtqueue_map_desc()` already rejects 
zero-length descriptors, so an assert should be sufficient.

Then again, if you can handle it benignly either way (without an 
assert), that’s always a good option.

Hanna