[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [v22 1/2] virtio-crypto: Add virtio crypto device speci
From: |
Halil Pasic |
Subject: |
Re: [Qemu-devel] [v22 1/2] virtio-crypto: Add virtio crypto device specification |
Date: |
Mon, 11 Dec 2017 16:41:59 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 |
On 12/11/2017 03:09 PM, Michael S. Tsirkin wrote:
> On Mon, Dec 11, 2017 at 02:54:25PM +0100, Halil Pasic wrote:
>> * I assume one request is supposed to correspond to one descriptor chain.
>> Right? If yes, could you tell me, where is this expressed in the spec.
>>
>> Halil
>
> That's always the default for all virtio devices, exceptions have to
> be noted in spec.
>
Grew to think this myself. But I could not derive it form the virtio spec.
Could you give me a pointer or a quote that _specifies_ that that's always
the default, and that exceptions have to be noted in the spec (I guess
in the corresponding device specific normative section)?
What I've found (maybe) showing in this direction is:
"""
2.4.4 Message Framing
The framing of messages with descriptors is independent of the contents of the
buffers. For example, a network transmit buffer consists of a 12 byte header
followed by the network packet. This could be most simply placed in the
descriptor table as a 12 byte output descriptor followed by a 1514 byte output
descriptor, but it could also consist of a single 1526 byte output descriptor
in the case where the header and packet are adjacent, or even three or more
descriptors (possibly with loss of efficiency in that case).
Note that, some device implementations have large-but-reasonable restrictions
on total descriptor size (such as based on IOV_MAX in the host OS). This has
not been a problem in practice: little sympathy will be given to drivers which
create unreasonably-sized descriptors such as by dividing a network packet into
1500 single-byte descriptors!
"""
This however talks about buffers and messages which (seem to be used as
synonyms here BTW), and about how no assumptions should be made about
how many descriptors are used in the descriptor chain (to transfer
the same in guest memory maximal buffer elements -- maximal in a sense
that no guest physically contiguous piece of memory is represented by
two adjacent elements).
Most of the devices don't talk about messages (but rather specify
requests). So it's hard to relate the requests/packets to messages
which are framed as buffers.
I find the whole terminology a bit hard to understand (and sometimes
ambiguous).
Please help me understand this aspect of the specification.
Regards,
Halil
- [Qemu-devel] [v22 0/2] virtio-crypto: virtio crypto device specification, Longpeng(Mike), 2017/12/06
- [Qemu-devel] [v22 1/2] virtio-crypto: Add virtio crypto device specification, Longpeng(Mike), 2017/12/06
- Re: [Qemu-devel] [v22 1/2] virtio-crypto: Add virtio crypto device specification, Halil Pasic, 2017/12/06
- Re: [Qemu-devel] [virtio-dev] Re: [v22 1/2] virtio-crypto: Add virtio crypto device specification, Longpeng (Mike), 2017/12/18
- Re: [Qemu-devel] [virtio-dev] Re: [v22 1/2] virtio-crypto: Add virtio crypto device specification, Halil Pasic, 2017/12/18
- Re: [Qemu-devel] [virtio-dev] Re: [v22 1/2] virtio-crypto: Add virtio crypto device specification, Michael S. Tsirkin, 2017/12/18
- Re: [Qemu-devel] [virtio-dev] Re: [v22 1/2] virtio-crypto: Add virtio crypto device specification, Halil Pasic, 2017/12/18
- Re: [Qemu-devel] [virtio-dev] Re: [virtio-dev] Re: [v22 1/2] virtio-crypto: Add virtio crypto device specification, Longpeng (Mike), 2017/12/23
Re: [Qemu-devel] [v22 1/2] virtio-crypto: Add virtio crypto device specification, Halil Pasic, 2017/12/20
[Qemu-devel] [v22 2/2] virtio-crypto: Add conformance clauses, Longpeng(Mike), 2017/12/06