From: Halil Pasic <pasic@linux.vnet.ibm.com>
To: "Gonglei (Arei)" <arei.gonglei@huawei.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Cc: "mst@redhat.com" <mst@redhat.com>,
"Huangweidong (C)" <weidong.huang@huawei.com>,
"stefanha@redhat.com" <stefanha@redhat.com>,
Luonengjun <luonengjun@huawei.com>,
"cornelia.huck@de.ibm.com" <cornelia.huck@de.ibm.com>,
Linqiangmin <linqiangmin@huawei.com>,
"xin.zeng@intel.com" <xin.zeng@intel.com>,
"Wubin (H)" <wu.wubin@huawei.com>
Subject: Re: [Qemu-devel] [RFC v1 6/9] virtio-crypto: rework virtio_crypto_handle_request
Date: Wed, 17 May 2017 11:51:01 +0200 [thread overview]
Message-ID: <a8b185ca-4b8d-e913-cfb3-454d61dbce78@linux.vnet.ibm.com> (raw)
In-Reply-To: <33183CC9F5247A488A2544077AF19020DA29B209@DGGEMA505-MBS.china.huawei.com>
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
>
next prev parent reply other threads:[~2017-05-17 9:51 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-08 11:38 [Qemu-devel] [RFC v1 0/9] virtio-crypto: add stateless mode support Gonglei
2017-05-08 11:38 ` [Qemu-devel] [RFC v1 1/9] cryptodev: introduce stateless sym operation stuff Gonglei
2017-05-08 11:38 ` [Qemu-devel] [RFC v1 2/9] cryptodev: extract one util function Gonglei
2017-05-08 11:38 ` [Qemu-devel] [RFC v1 3/9] cryptodev: add missing op_code for symmertric crypto Gonglei
2017-05-08 11:38 ` [Qemu-devel] [RFC v1 4/9] cryptodev-builtin: realize stateless operation function Gonglei
2017-05-08 11:38 ` [Qemu-devel] [RFC v1 5/9] virtio-crypto: update header file Gonglei
2017-05-16 15:43 ` Stefan Hajnoczi
2017-05-17 8:48 ` Gonglei (Arei)
2017-05-08 11:38 ` [Qemu-devel] [RFC v1 6/9] virtio-crypto: rework virtio_crypto_handle_request Gonglei
2017-05-12 11:02 ` Halil Pasic
2017-05-13 1:16 ` Gonglei (Arei)
2017-05-15 16:15 ` Halil Pasic
2017-05-16 2:52 ` Gonglei (Arei)
2017-05-16 22:18 ` Halil Pasic
2017-05-17 9:12 ` Gonglei (Arei)
2017-05-17 9:51 ` Halil Pasic [this message]
2017-05-17 10:13 ` Gonglei (Arei)
2017-05-17 10:33 ` Halil Pasic
2017-05-17 11:10 ` Cornelia Huck
2017-05-17 13:04 ` Halil Pasic
2017-05-18 12:07 ` Halil Pasic
2017-05-18 13:21 ` Gonglei (Arei)
2017-05-29 14:07 ` Halil Pasic
2017-05-08 11:38 ` [Qemu-devel] [RFC v1 7/9] virtio-crypto: add stateless crypto request handler Gonglei
2017-05-08 11:38 ` [Qemu-devel] [RFC v1 8/9] virtio-crypto: add host feature bits support Gonglei
2017-05-11 15:05 ` Cornelia Huck
2017-05-12 0:55 ` Gonglei (Arei)
2017-05-12 11:21 ` Cornelia Huck
2017-05-13 1:21 ` Gonglei (Arei)
2017-05-08 11:38 ` [Qemu-devel] [RFC v1 9/9] qtest: emulate virtio crypto as a legacy device for experiment Gonglei
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=a8b185ca-4b8d-e913-cfb3-454d61dbce78@linux.vnet.ibm.com \
--to=pasic@linux.vnet.ibm.com \
--cc=arei.gonglei@huawei.com \
--cc=cornelia.huck@de.ibm.com \
--cc=linqiangmin@huawei.com \
--cc=luonengjun@huawei.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
--cc=weidong.huang@huawei.com \
--cc=wu.wubin@huawei.com \
--cc=xin.zeng@intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).