From: Sasha Levin <levinsasha928@gmail.com>
To: Rusty Russell <rusty@rustcorp.com.au>,
"Michael S. Tsirkin" <mst@redhat.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
kvm <kvm@vger.kernel.org>,
virtualization <virtualization@lists.linux-foundation.org>
Subject: virtio-pci new configuration proposal
Date: Wed, 02 Nov 2011 20:49:27 +0200 [thread overview]
Message-ID: <1320259767.22582.2.camel@lappy> (raw)
This is a proposal for a new layout of the virtio-pci config space.
We will separate the current configuration into two: A virtio-pci common
configuration and a device specific configuration. This allows more flexibility
with adding features and makes usage easier, specifically in cases like the
ones in virtio-net where device specific configurations depend on device
specific features.
The preferred location of the configuration will be a MMIO BAR, therefore
several size optimizations such as the queue selector which were useful
on a PIO BAR were removed and linked lists were introduced to add
flexibility to existing structures in attempt to keep their size and
offsets constant and not dependent on features.
While this is not a complete specification, it describes all the main
structures and should be enough to make sure the idea is solid before
going into implementation specifics.
A new virtio-pci capability structure will be introduced. This structure
will be used to describe the basics of a virtio-pci device. The
structure is actually a PCI capability structure which wraps the new virtio-pci
capability structure:
+------------++------------+------------+------------+--------------+-----------------
| Bits || 8 | 8 | 8 | 8 | Cap specific
+------------++------------+------------+------------+--------------+-----------------
| Read/Write || R | R | R | R | Cap specific
+------------++------------+------------+------------+--------------+-----------------
| Purpose || Capability | Capability | virtio-pci | virtio-pci | Cap specific
| || ID | Next PTR | Cap ID | Next Cap PTR |
+------------++------------+------------+------------+--------------+-----------------
Currently, only one virtio-pci capability is defined, and is the one that defines
the layout of the virtio-pci config space.
VIRTIO_PCI_C_LAYOUT:
+------------++---------------+---------------+-----------------+-----------------+
| Bits || 29 | 3 | 29 | 3 |
+------------++---------------+---------------+-----------------+-----------------+
| Read/Write || R | R | R | R |
+------------++---------------+---------------+-----------------+-----------------+
| Purpose || Common config | Common config | Device specific | Device specific |
| || Offset | BIR | Offset | BIR |
+------------++---------------+---------------+-----------------+-----------------+
The combination of the offset and the BIR will point to the common and device
specific configuration spaces. These spaces may be pointed to by the same, or
by different BARs and may sit in the same or different MMIO regions.
The BIR is a PCI concept which describes which BAR should be used:
"Indicates which one of a function’s Base Address registers, located beginning
at 10h in Configuration space, is used to map the function’s MSI-X Table into
memory space.
BIR Value Base Address register
0 10h
1 14h
2 18h
3 1Ch
4 20h
5 24h
6 Reserved
7 Reserved"
While the offset will provide a 32-bit aligned offset into the memory region
and will point to the appropriate config space.
First, we will look at the virtio-pci configuration space, which has been
simplified from the original.
virtio-pci header:
+------------++---------+--------+--------------+--------------+
| Bits || 8 | 8 | 16 | 16 |
+------------++---------+--------+--------------+--------------+
| Read/Write || R+W | R | R | R |
+------------++---------+--------+--------------+--------------+
| Purpose || Device | ISR | Queue | virtio-pci |
| || Status | Status | Table Ptr | Features Ptr |
+------------++---------+--------+--------------+--------------+
Device and ISR status are the same as in the original, and two new fields
have been added. Queue table ptr is an offset from the beginning of the
config space to a table which describes all virtio queues, and is defined
below.
Virtio-pci features ptr will point to virtio-pci features, such features
will be placed in a virtio-pci feature struct which is defined as follows:
virtio-pci features:
+------------++------------+------------+-------------------
| Bits || 8 | 16 | Feature specific
+------------++------------+------------+-------------------
| Read/Write || R | R | Feature specific
+------------++------------+------------+-------------------
| Purpose || Feature | Feature | Feature specific
| || ID | Next PTR |
+------------++------------+------------+-------------------
For example, the virtio-pci MSI-X feature will look as follows:
VIRTIO_PCI_F_MSIX:
+------------++----------------+
| Bits || 16 |
+------------++----------------+
| Read/Write || R+W |
+------------++----------------+
| Purpose || Configuration |
| || Vector |
+------------++----------------+
The queue table is the table which will hold the definition of all virtio
queues. The virtio queue selector has been dropped and instead the queues
are listed in a simple list:
Queue table:
+------------++-------------------+--------+---------+--------------+--------------
| Bits || 8 | 32 | 16 | 16 | 16 | More queues
+------------++-------------------+--------+---------+--------------+--------------
| Read/Write || R | R+W | R | R+W | R | More queues
+------------++-------------------+--------+---------+--------------+--------------
| Purpose || Queue | Queue | Queue | Queue | Queue | More queues
| || Count | Address | Size | Notify | Features Ptr |
+------------++-------------------+--------+---------+--------------+--------------
Besides the usual fields, each virtio queue will also have a feature ptr which
points to queue specific features. These features may be shared between queues
therefore it is not required to define a feature struct for each queue.
Queue features:
+------------++------------+------------+-------------------
| Bits || 8 | 16 | Feature specific
+------------++------------+------------+-------------------
| Read/Write || R | R | Feature specific
+------------++------------+------------+-------------------
| Purpose || Feature | Feature | Feature specific
| || ID | Next PTR |
+------------++------------+------------+-------------------
For example, the virtio queue MSI-X feature will look as follows and may be
shared between all virtio queues if we only have one vector for all queues.
VIRTIO_QUEUE_F_MSIX:
+------------++--------+
| Bits || 16 |
+------------++--------+
| Read/Write || R+W |
+------------++--------+
| Purpose || Queue |
| (MSI-X) || Vector |
+------------++--------+
The second part is the device specific configuration space. This is
basically a linked list of features which may be activated or
deactivated by setting the active flag in each feature.
Device specific features:
+------------++------------+------------+----------+---------
| Bits || 8 | 16 | 8 | Feature specific
+------------++------------+------------+----------+---------
| Read/Write || R | R | R+W | Feature specific
+------------++------------+------------+----------+---------
| Purpose || Feature | Feature | Feature | Feature specific
| || ID | Next PTR | Active |
+------------++------------+------------+----------+---------
For example, the virtio-net MAC feature will look as follows:
VIRTIO_NET_F_MAC:
+------------++------------+
| Bits || 48 |
+------------++------------+
| Read/Write || R |
+------------++------------+
| Purpose || virtio-net |
| || MAC |
+------------++------------+
--
Sasha.
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
next reply other threads:[~2011-11-02 18:49 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-02 18:49 Sasha Levin [this message]
2011-11-02 19:08 ` virtio-pci new configuration proposal Michael S. Tsirkin
2011-11-02 19:07 ` Sasha Levin
2011-11-02 19:14 ` Michael S. Tsirkin
2011-11-03 1:58 ` Rusty Russell
[not found] ` <8762j2t19l.fsf@rustcorp.com.au>
2011-11-03 8:33 ` Sasha Levin
2011-11-03 12:46 ` Michael S. Tsirkin
2011-11-03 13:19 ` Sasha Levin
2011-11-03 13:48 ` Michael S. Tsirkin
2011-11-04 9:44 ` Rusty Russell
[not found] ` <87lirwrzlg.fsf@rustcorp.com.au>
2011-11-04 11:40 ` Michael S. Tsirkin
[not found] ` <20111104114033.GA21308@redhat.com>
2011-11-04 12:32 ` Sasha Levin
2011-11-04 13:51 ` Michael S. Tsirkin
[not found] ` <20111104135113.GA24452@redhat.com>
2011-11-04 13:53 ` Sasha Levin
[not found] ` <1320414804.3334.13.camel@lappy>
2011-11-04 14:23 ` Michael S. Tsirkin
[not found] ` <20111104142338.GB24452@redhat.com>
2011-11-04 14:53 ` Sasha Levin
2011-11-06 7:30 ` Michael S. Tsirkin
2011-11-06 20:24 ` Sasha Levin
2011-11-06 21:38 ` Michael S. Tsirkin
2011-11-07 5:16 ` Rusty Russell
2011-11-07 21:14 ` Michael S. Tsirkin
2011-11-07 23:53 ` Rusty Russell
2011-11-08 6:32 ` Michael S. Tsirkin
2011-11-08 10:21 ` Rusty Russell
2011-11-08 21:31 ` Michael S. Tsirkin
2011-11-08 14:15 ` Sasha Levin
2011-11-03 11:03 ` Michael S. Tsirkin
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=1320259767.22582.2.camel@lappy \
--to=levinsasha928@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--cc=rusty@rustcorp.com.au \
--cc=virtualization@lists.linux-foundation.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).