From: Eugenio Perez Martin <eperezma@redhat.com>
To: Sahil <icegambit91@gmail.com>
Cc: Stefano Garzarella <sgarzare@redhat.com>,
qemu-level <qemu-devel@nongnu.org>
Subject: Re: Intention to work on GSoC project
Date: Wed, 20 Mar 2024 17:29:30 +0100 [thread overview]
Message-ID: <CAJaqyWdhsXUXdP+3GN81hw9tqccy6+3=WVvigxu2yU-8F=x04A@mail.gmail.com> (raw)
In-Reply-To: <3291749.44csPzL39Z@valdaarhun>
On Mon, Mar 18, 2024 at 8:47 PM Sahil <icegambit91@gmail.com> wrote:
>
> 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?
>
struct virtq_avail has two members: uint16_t idx and ring[]. To be in
the first position of the avail ring means to be in ring[0] there.
Idx and ring[] are just headers in the figure, not actual positions.
Same as Avail. Now that you mention maybe there is a better way to
represent that, yes.
Let me know if I didn't explain it well.
> 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?
>
It is the position in ring[] where the device needs to stop looking
for descriptors. It starts at 0, and when the device sees 1 it means
ring[0] has a descriptor to process.
Now you need to apply a "modulo virtqueue size" to that index. So if
the virtqueue is 256, avail_idx 257 means the last valid descriptor is
at 0. This happens naturally when the driver keeps adding descriptors
and wraps the queue.
The authoritative source of this is the VirtQueues section of the
virtio standard [1], feel free to check it in case it clarifies
something better.
> 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.
>
avail_idx is an uin16_t, so ((uint16_t)-1) + 1 == 0.
> 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?
>
That's a limitation in the standard, but I'm not sure where it comes
from beyond being computationally easier to calculate ring position
with a mask than with a remainder of a random non-power-of-two number.
Packed virtqueue removes that limitation.
> 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?
>
For PCI devices, as long as it detects a device with vendor == Red
Hat, Inc. (0x1AF4) and device ID 0x1000 through 0x107F inclusive, yes.
You can also load and unload manually with modprobe as other drivers.
Let me know if you have more doubts. Thanks!
[1] https://docs.oasis-open.org/virtio/virtio/v1.3/virtio-v1.3.html
> Thanks,
> Sahil
>
> [1] https://www.redhat.com/en/blog/virtqueues-and-virtio-ring-how-data-travels
>
>
>
>
next prev parent reply other threads:[~2024-03-20 16:30 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-25 21:38 Intention to work on GSoC project Sahil
2024-02-29 8:32 ` Stefano Garzarella
2024-02-29 19:02 ` Sahil
2024-03-01 7:40 ` Eugenio Perez Martin
2024-03-01 18:29 ` Sahil
2024-03-14 15:09 ` Eugenio Perez Martin
2024-03-15 7:14 ` Sahil
2024-03-15 11:27 ` Eugenio Perez Martin
2024-03-16 20:26 ` Sahil
2024-03-18 19:47 ` Sahil
2024-03-20 16:29 ` Eugenio Perez Martin [this message]
2024-03-25 13:20 ` Sahil
2024-04-01 18:23 ` daleyoung4242
2024-04-02 4:58 ` Sahil
2024-04-02 11:38 ` Eugenio Perez Martin
2024-04-03 14:36 ` Sahil
2024-04-03 18:37 ` Eugenio Perez Martin
2024-04-04 19:06 ` Sahil
2024-04-14 18:52 ` Sahil
2024-04-15 8:57 ` Eugenio Perez Martin
2024-04-15 19:42 ` Sahil
2024-04-16 8:41 ` Eugenio Perez Martin
2024-04-17 4:23 ` Sahil
2024-05-06 19:00 ` Sahil
2024-05-07 7:14 ` Eugenio Perez Martin
2024-05-08 3:23 ` Sahil
2024-05-13 13:49 ` Sahil
2024-05-13 14:23 ` Eugenio Perez Martin
2024-05-13 18:04 ` Sahil
2024-03-20 15:57 ` Eugenio Perez Martin
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='CAJaqyWdhsXUXdP+3GN81hw9tqccy6+3=WVvigxu2yU-8F=x04A@mail.gmail.com' \
--to=eperezma@redhat.com \
--cc=icegambit91@gmail.com \
--cc=qemu-devel@nongnu.org \
--cc=sgarzare@redhat.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 read-only IMAP folder(s) and NNTP newsgroup(s).