From: Fam Zheng <famz@redhat.com>
To: Vasile Catalin-B50542 <catalin.vasile@freescale.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [virtio] virtqueue allocation and thread-safety
Date: Thu, 15 Jan 2015 09:41:31 +0800 [thread overview]
Message-ID: <20150115014131.GA8720@ad.nay.redhat.com> (raw)
In-Reply-To: <54B65A8B.3000801@freescale.com>
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ă
>
next prev parent reply other threads:[~2015-01-15 1:41 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-14 12:01 [Qemu-devel] [virtio] virtqueue allocation and thread-safety Vasile Catalin-B50542
2015-01-15 1:41 ` Fam Zheng [this message]
2015-01-16 9:15 ` Vasile Catalin-B50542
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=20150115014131.GA8720@ad.nay.redhat.com \
--to=famz@redhat.com \
--cc=catalin.vasile@freescale.com \
--cc=qemu-devel@nongnu.org \
/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 NNTP newsgroup(s).