[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC v1 6/9] virtio-crypto: rework virtio_crypto_handle
From: |
Halil Pasic |
Subject: |
Re: [Qemu-devel] [RFC v1 6/9] virtio-crypto: rework virtio_crypto_handle_request |
Date: |
Wed, 17 May 2017 11:51:01 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 |
On 05/17/2017 11:12 AM, Gonglei (Arei) wrote:
>>>> By the way, I'm having a hard time understing how is the requirement form
>>>>
>> http://docs.oasis-open.org/virtio/virtio/v1.0/cs04/virtio-v1.0-cs04.html#x1-260
>>>> 004
>>>> (2.4.4 Message Framing) satisfied by this code. Could you explain this
>>>> to me please?
>>>>
>>> Sorry for my bad English,
>>> I don't know which normative formulation the code violates?
>> I'm not sure it's actually violated, but I'm concerned about the following
>> normative statement: "The device MUST NOT make assumptions about the
>> particular
>> arrangement of descriptors. The device MAY have a reasonable limit of
>> descriptors it will allow in a chain."
>>
>> Please also read the explanatory part I've linked, because the normative
>> statement is pretty abstract.
>>
>> In my understanding, the spec says, that e.g. the virti-crypto device
>> should not fail if a single request is split up into let's say two chunks
>> and transmitted by the means of two top level descriptors.
>>
>> Do you agree with my reading of the spec?
>>
> Yes, I agree. But what's the relationship about the request here?
> We don't assume the request have to use one desc entity, it can
> use scatter-gather list for one request header.
> The device can cover the situation in the QEMU.
>
>> What does the virtio-crypto device do if it encounters such a situation?
>>
> This isn't a problem. Pls see blow code segment:
>
> virtio_crypto_handle_request()
> {...
> if (unlikely(iov_to_buf(out_iov, out_num, 0, &req, sizeof(req))
> != sizeof(req))) {
> virtio_error(vdev, "virtio-crypto request outhdr too short");
> return -1;
> }
> iov_discard_front(&out_iov, &out_num, sizeof(req));
> ...
>
Thats exactly what worries me. I see a call to virtio_error there...
void GCC_FMT_ATTR(2, 3) virtio_error(VirtIODevice *vdev, const char *fmt, ...)
{
va_list ap;
va_start(ap, fmt);
error_vreport(fmt, ap);
va_end(ap);
vdev->broken = true;
if (virtio_vdev_has_feature(vdev, VIRTIO_F_VERSION_1)) {
virtio_set_status(vdev, vdev->status | VIRTIO_CONFIG_S_NEEDS_RESET);
virtio_notify_config(vdev);
}
}
This however seems to make the device 'broken'. Or am I missing something?
Halil
>
> Thanks,
> -Gonglei
>
- [Qemu-devel] [RFC v1 0/9] virtio-crypto: add stateless mode support, Gonglei, 2017/05/08
- [Qemu-devel] [RFC v1 6/9] virtio-crypto: rework virtio_crypto_handle_request, Gonglei, 2017/05/08
- Re: [Qemu-devel] [RFC v1 6/9] virtio-crypto: rework virtio_crypto_handle_request, Halil Pasic, 2017/05/12
- Re: [Qemu-devel] [RFC v1 6/9] virtio-crypto: rework virtio_crypto_handle_request, Gonglei (Arei), 2017/05/12
- Re: [Qemu-devel] [RFC v1 6/9] virtio-crypto: rework virtio_crypto_handle_request, Halil Pasic, 2017/05/15
- Re: [Qemu-devel] [RFC v1 6/9] virtio-crypto: rework virtio_crypto_handle_request, Gonglei (Arei), 2017/05/15
- Re: [Qemu-devel] [RFC v1 6/9] virtio-crypto: rework virtio_crypto_handle_request, Halil Pasic, 2017/05/16
- Re: [Qemu-devel] [RFC v1 6/9] virtio-crypto: rework virtio_crypto_handle_request, Gonglei (Arei), 2017/05/17
- Re: [Qemu-devel] [RFC v1 6/9] virtio-crypto: rework virtio_crypto_handle_request,
Halil Pasic <=
- Re: [Qemu-devel] [RFC v1 6/9] virtio-crypto: rework virtio_crypto_handle_request, Gonglei (Arei), 2017/05/17
- Re: [Qemu-devel] [RFC v1 6/9] virtio-crypto: rework virtio_crypto_handle_request, Halil Pasic, 2017/05/17
- Re: [Qemu-devel] [RFC v1 6/9] virtio-crypto: rework virtio_crypto_handle_request, Cornelia Huck, 2017/05/17
- Re: [Qemu-devel] [RFC v1 6/9] virtio-crypto: rework virtio_crypto_handle_request, Halil Pasic, 2017/05/17
- Re: [Qemu-devel] [RFC v1 6/9] virtio-crypto: rework virtio_crypto_handle_request, Halil Pasic, 2017/05/18
- Re: [Qemu-devel] [RFC v1 6/9] virtio-crypto: rework virtio_crypto_handle_request, Gonglei (Arei), 2017/05/18
- Re: [Qemu-devel] [RFC v1 6/9] virtio-crypto: rework virtio_crypto_handle_request, Halil Pasic, 2017/05/29
[Qemu-devel] [RFC v1 5/9] virtio-crypto: update header file, Gonglei, 2017/05/08