qemu-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]