Re: Intention to work on GSoC project

[Sahil]

Hi,

I was reading the "Virtqueues and virtio ring: How the data travels"
article [1]. There are a few things that I have not understood in the
"avail rings" section.

Q1.
Step 2 in the "Process to make a buffer available" diagram depicts
how the virtio driver writes the descriptor index in the avail ring.
In the example, the descriptor index #0 is written in the first entry.
But in figure 2, the number 0 is in the 4th position in the avail ring.
Is the avail ring queue an array of "struct virtq_avail" which maintains
metadata such as the number of descriptor indexes in the header?

Also, in the second position, the number changes from 0 (figure 1) to
1 (figure 2). I haven't understood what idx, 0 (later 1) and ring[] represent
in the figures. Does this number represent the number of descriptors
that are currently in the avail ring?

Q2.

There's this paragraph in the article right below the above mentioned
diagram:

> The avail ring must be able to hold the same number of descriptors
> as the descriptor area, and the descriptor area must have a size power
> of two, so idx wraps naturally at some point. For example, if the ring
> size is 256 entries, idx 1 references the same descriptor as idx 257, 513...
> And it will wrap at a 16 bit boundary. This way, neither side needs to
> worry about processing an invalid idx: They are all valid.

I haven't really understood this. I have understood that idx is calculated
as idx mod queue_length. But I haven't understood the "16 bit boundary"
part.

I am also not very clear on how a queue length that is not a power of 2
might cause trouble. Could you please expand on this?

Q3.
I have started going through the source code in "drivers/virtio/virtio_ring.c".
I have understood that the virtio driver runs in the guest's kernel. Does that
mean the drivers in "drivers/virtio/*" are enabled when linux is being run in
a guest VM?

Thanks,
Sahil

[1] https://www.redhat.com/en/blog/virtqueues-and-virtio-ring-how-data-travels