[Qemu-devel] [virtio] virtqueue allocation and thread-safety

[Qemu-devel] [virtio] virtqueue allocation and thread-safety

[Vasile Catalin-B50542]

Hi,

I'm trying to make a new virtio device.
I got it running (I made a functional dummy device & guest driver).
Now I'm trying to build some communication between the device and guest 
driver.
I can't seem to find where the actual allocation of virtqueues are made.
I've looked inside virtio_init(), but it just allocates the vq 
structures and I don't see
any pointers inside that structure that might give and idea of something 
dynamically
allocated. There is a member of that structure named "vector", but it's 
type is uint16_t.
I've also looked inside the virtio_add_queue(), and it just makes some 
constant assignments.
Where are the vqs buffer space actually allocated?
One more thing. Are the virtqueue functions thread safe, from both point 
of views
(qemu and guest driver API's view)?
Also I don't see any dynamic allocations/freeing when pushing and 
popping, either.

Cătă

Re: [Qemu-devel] [virtio] virtqueue allocation and thread-safety

[Fam Zheng]

On Wed, 01/14 14:01, Vasile Catalin-B50542 wrote:
> Hi,
> 
> I'm trying to make a new virtio device.
> I got it running (I made a functional dummy device & guest driver).
> Now I'm trying to build some communication between the device and guest
> driver.
> I can't seem to find where the actual allocation of virtqueues are made.
> I've looked inside virtio_init(), but it just allocates the vq structures
> and I don't see
> any pointers inside that structure that might give and idea of something
> dynamically
> allocated. There is a member of that structure named "vector", but it's type
> is uint16_t.
> I've also looked inside the virtio_add_queue(), and it just makes some
> constant assignments.
> Where are the vqs buffer space actually allocated?

The guest memory is prepared by guest. See the virtio spec "Virtual I/O Device
(VIRTIO) Version 1.0" section "3.2.1 Supplying Buffers to The Device":

<quote>

The driver offers buffers to one of the device’s virtqueues as follows:

1. The driver places the buffer into free descriptor(s) in the descriptor
table, chaining as necessary (see 2.4.5 The Virtqueue Descriptor Table).

2. The driver places the index of the head of the descriptor chain into the
next ring entry of the available ring.

3. Steps 1 and 2 MAY be performed repeatedly if batching is possible.

4. The driver performs suitable a memory barrier to ensure the device sees the
updated descriptor table and available ring before the next step.

5. The available idx is increased by the number of descriptor chain heads added
to the available ring.

6. The driver performs a suitable memory barrier to ensure that it updates the
idx field before checking for notification suppression.

7. If notifications are not suppressed, the driver notifies the device of the
new available buffers.

</unquote>

Fam

> One more thing. Are the virtqueue functions thread safe, from both point of
> views
> (qemu and guest driver API's view)?
> Also I don't see any dynamic allocations/freeing when pushing and popping,
> either.
> 
> Cătă
> 

Re: [Qemu-devel] [virtio] virtqueue allocation and thread-safety

[Vasile Catalin-B50542]

[-- Attachment #1: Type: text/plain, Size: 2699 bytes --]

Does the guest memory allocation include the descriptor tables allocation?
Which part of the structures is the descriptor tables?

On 15.01.2015 03:41, Fam Zheng wrote:
> On Wed, 01/14 14:01, Vasile Catalin-B50542 wrote:
>> Hi,
>>
>> I'm trying to make a new virtio device.
>> I got it running (I made a functional dummy device & guest driver).
>> Now I'm trying to build some communication between the device and guest
>> driver.
>> I can't seem to find where the actual allocation of virtqueues are made.
>> I've looked inside virtio_init(), but it just allocates the vq structures
>> and I don't see
>> any pointers inside that structure that might give and idea of something
>> dynamically
>> allocated. There is a member of that structure named "vector", but it's type
>> is uint16_t.
>> I've also looked inside the virtio_add_queue(), and it just makes some
>> constant assignments.
>> Where are the vqs buffer space actually allocated?
> The guest memory is prepared by guest. See the virtio spec "Virtual I/O Device
> (VIRTIO) Version 1.0" section "3.2.1 Supplying Buffers to The Device":
>
> <quote>
>
> The driver offers buffers to one of the device’s virtqueues as follows:
>
> 1. The driver places the buffer into free descriptor(s) in the descriptor
> table, chaining as necessary (see 2.4.5 The Virtqueue Descriptor Table).
>
> 2. The driver places the index of the head of the descriptor chain into the
> next ring entry of the available ring.
>
> 3. Steps 1 and 2 MAY be performed repeatedly if batching is possible.
>
> 4. The driver performs suitable a memory barrier to ensure the device sees the
> updated descriptor table and available ring before the next step.
>
> 5. The available idx is increased by the number of descriptor chain heads added
> to the available ring.
>
> 6. The driver performs a suitable memory barrier to ensure that it updates the
> idx field before checking for notification suppression.
>
> 7. If notifications are not suppressed, the driver notifies the device of the
> new available buffers.
>
> </unquote>
>
> Fam
>
>> One more thing. Are the virtqueue functions thread safe, from both point of
>> views
>> (qemu and guest driver API's view)?
>> Also I don't see any dynamic allocations/freeing when pushing and popping,
>> either.
>>
>> Cătă
>>

-- 

CatalinVasile

Intern, DN-Software

FreescaleSemiconductor, Inc.

www.freescale.com

phone: 073-021-1938

e-mail: catalin.vasile@freescale.com <mailto:your.name@freescale.com>

*Freescale_Logo-nosemi_Lh_4c***

This e-mail, and any associated attachments have been classified as:

[ ] Public

[ ] Freescale Semiconductor Internal Use Only

[ ] Freescale Semiconductor Confidential Proprietary


[-- Attachment #2.1: Type: text/html, Size: 30865 bytes --]

[-- Attachment #2.2: image002.gif --]
[-- Type: image/gif, Size: 1979 bytes --]