From: Sasha Levin <levinsasha928@gmail.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>,
lkml - Kernel Mailing List <linux-kernel@vger.kernel.org>,
Alexey Kardashevskiy <aik@ozlabs.ru>,
Amit Shah <amit.shah@redhat.com>,
Christian Borntraeger <borntraeger@de.ibm.com>,
Krishna Kumar <krkumar2@in.ibm.com>,
Pawel Moll <pawel.moll@arm.com>,
Wang Sheng-Hui <shhuiw@gmail.com>,
virtualization@lists.linux-foundation.org, kvm@vger.kernel.org,
avi@redhat.com
Subject: Re: [PATCH RFC] virtio-spec: flexible configuration layout
Date: Wed, 09 Nov 2011 10:46:06 +0200 [thread overview]
Message-ID: <1320828366.31056.16.camel@lappy> (raw)
In-Reply-To: <20111108214021.GA4538@redhat.com>
On Tue, 2011-11-08 at 23:40 +0200, Michael S. Tsirkin wrote:
> Here's a spec change documenting what my C patch does
> (almost - I tweaked the layout a bit, but the idea is the same).
> Some more cleanups are needed but I thought I'd send it
> for early flames/comments.
>
> The idea is simple: we split functionally unrelated
> register groups to independent structures, and let
> the device place is anywhere using a capability
> in PCI configuration space.
>
> It can then go into MMIO space which is cheaper than PIO.
>
> A legacy portion of the configuration is mirrored
> in the first BAR, to keep legacy drivers working.
> Any new fields can be added in existing structures
> at the end, so they won't affect legacy.
If newer specs add more structures at the end of the config space, and
use the same config space for legacy, that space now becomes device
specific config space and not new-shiny-feature space, so we must
remember to handle those cases.
> Alternatively we can add new structures with new
> structure IDs, pointed to from PCI configuration space.
>
> As we don't yet have devices or drivers with 64 bit features,
> I decided we don't need high feature bits in legacy space.
> This also frees up feature bit 31 as we don't need it
> to enable high feature bits anymore.
KVM tool actually has support for 64bit features, we can probably remove
that when Pekka isn't looking :)
>
> As this solves the dynamic placement of MSIX vectors
> and high feature bits,
> I thought it's easier to just reserve space for that
> programming than give it a separate structure. This
> can be changed by a patch on top.
>
> Note that data path is split from configuration.
>
> PDF will follow.
> ----
>
The device initialization sequence might use an update as well. Maybe
also a description of how device handles missing structure IDs.
[snip]
> +
> +\begin_layout Standard
> +
> +\change_inserted 1986246365 1320781133
> +These registers are specified using vendor-specific PCI capability located
> + on capability list in PCI configuration space of the device.
> + This virtio structure capability uses little-endian format; all bits are
> + read-only:
> +\end_layout
> +
> +\begin_layout Standard
> +
> +\change_inserted 1986246365 1320772579
> +\begin_inset Tabular
Just a note, these tables are way too wide to work properly in PDFs :)
> +<lyxtabular version="3" rows="4" columns="34">
> +<features tabularvalignment="middle">
> +<column alignment="center" valignment="top" width="0pt">
> +<column alignment="center" valignment="top" width="0">
> +<column alignment="center" valignment="top" width="0">
> +<column alignment="center" valignment="top" width="0">
> +<column alignment="center" valignment="top" width="0">
> +<column alignment="center" valignment="top" width="0">
> +<column alignment="center" valignment="top" width="0">
> +<column alignment="center" valignment="top" width="0">
> +<column alignment="center" valignment="top" width="0">
> +<column alignment="center" valignment="top" width="0">
> +<column alignment="center" valignment="top" width="0">
> +<column alignment="center" valignment="top" width="0">
> +<column alignment="center" valignment="top" width="0">
> +<column alignment="center" valignment="top" width="0">
> +<column alignment="center" valignment="top" width="0">
> +<column alignment="center" valignment="top" width="0">
> +<column alignment="center" valignment="top" width="0">
> +<column alignment="center" valignment="top" width="0">
> +<column alignment="center" valignment="top" width="0">
> +<column alignment="center" valignment="top" width="0">
> +<column alignment="center" valignment="top" width="0">
> +<column alignment="center" valignment="top" width="0">
> +<column alignment="center" valignment="top" width="0">
> +<column alignment="center" valignment="top" width="0">
> +<column alignment="center" valignment="top" width="0">
> +<column alignment="center" valignment="top" width="0">
> +<column alignment="center" valignment="top" width="0">
> +<column alignment="center" valignment="top" width="0">
> +<column alignment="center" valignment="top" width="0">
> +<column alignment="center" valignment="top" width="0">
> +<column alignment="center" valignment="top" width="0">
> +<column alignment="center" valignment="top" width="0">
> +<column alignment="center" valignment="top" width="0">
> +<column alignment="center" valignment="top" width="0pt">
> +<row>
[snip]
> +
> +\begin_layout Standard
> +
> +\change_inserted 1986246365 1320779667
> +Purpose:
> +\end_layout
> +
> +\begin_layout Standard
> +
> +\change_inserted 1986246365 1320780912
> +
> +\emph on
> +Capability ID
> +\emph default
> +,
> +\emph on
> +Next Capability Pointer
> +\emph default
> +,
> +\emph on
> +Capability Length
> +\emph default
> + - these fields are specified by PCI local bus specification, Rev 3.0
I'm not sure what capability length is, can't find it in the spec
either.
[snip]
> +\begin_layout Plain Layout
> +ie.
> + once you enable MSI-X on the device, the other fields move.
> + If you turn it off again, they move back!
Is it still true? We're talking about the new layout here (there are
several of this footnote, this one is located right *before* the section
which talks about legacy config space.
[snip]
> +
> +\change_deleted 1986246365 1320784929
> +If more than 31 feature bits are supported, the device indicates so by setting
> + feature bit 31 (see
The bit numbers below this text should be corrected as well.
--
Sasha.
next prev parent reply other threads:[~2011-11-09 8:48 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <87wrbkvh3v.fsf@rustcorp.com.au>
2011-11-01 11:45 ` [PULL] virtio Michael S. Tsirkin
2011-11-01 12:33 ` Sasha Levin
2011-11-01 12:42 ` Michael S. Tsirkin
2011-11-01 12:45 ` Sasha Levin
2011-11-02 1:09 ` Rusty Russell
2011-11-02 4:52 ` Sasha Levin
2011-11-02 22:07 ` Rusty Russell
2011-11-02 23:31 ` [PATCH RFC] virtio-pci: flexible configuration layout Michael S. Tsirkin
2011-11-03 0:19 ` Sasha Levin
2011-11-03 10:33 ` Michael S. Tsirkin
2011-11-03 11:09 ` Sasha Levin
2011-11-03 11:36 ` Michael S. Tsirkin
2011-11-03 13:30 ` Michael S. Tsirkin
2011-11-03 10:37 ` Avi Kivity
2011-11-03 12:11 ` Michael S. Tsirkin
2011-11-03 13:37 ` Avi Kivity
2011-11-03 13:53 ` Michael S. Tsirkin
2011-11-03 14:59 ` Jesse Barnes
2011-11-08 21:40 ` [PATCH RFC] virtio-spec: " Michael S. Tsirkin
2011-11-09 8:46 ` Sasha Levin [this message]
2011-11-09 10:13 ` Michael S. Tsirkin
2011-11-09 10:26 ` Sasha Levin
2011-11-09 10:49 ` Michael S. Tsirkin
2011-11-09 12:25 ` Pekka Enberg
2011-11-09 12:28 ` Sasha Levin
2011-11-09 12:36 ` Pekka Enberg
2011-11-09 15:33 ` Michael S. Tsirkin
2012-06-18 11:54 ` Michael S. Tsirkin
2012-06-18 12:05 ` Sasha Levin
2012-06-18 12:07 ` Michael S. Tsirkin
2011-11-09 12:38 ` Avi Kivity
2011-11-09 12:48 ` Sasha Levin
2011-11-09 15:19 ` Michael S. Tsirkin
2011-11-13 14:07 ` Ronen Hod
2011-11-09 15:51 ` Michael S. Tsirkin
2011-11-13 20:40 ` Vadim Rozenfeld
2011-11-09 9:55 ` Sasha Levin
2011-11-09 10:18 ` Michael S. Tsirkin
2011-11-09 10:20 ` Sasha Levin
2011-11-09 10:47 ` Pawel Moll
2011-11-09 10:55 ` Sasha Levin
2011-11-09 11:06 ` Pawel Moll
2011-11-09 11:39 ` Peter Maydell
2011-11-09 12:07 ` Sasha Levin
2011-11-09 19:59 ` [PATCHv2 " Michael S. Tsirkin
2011-11-09 20:24 ` Sasha Levin
2011-11-09 20:52 ` Michael S. Tsirkin
2011-11-09 20:57 ` Sasha Levin
2011-11-09 21:14 ` Michael S. Tsirkin
2011-11-09 21:13 ` Sasha Levin
2011-11-10 8:55 ` Michael S. Tsirkin
2011-11-11 4:24 ` Rusty Russell
2011-11-11 7:39 ` Sasha Levin
2011-11-11 12:59 ` Michael S. Tsirkin
2011-11-11 13:06 ` Pawel Moll
2011-11-15 23:58 ` Rusty Russell
2011-11-16 7:21 ` Michael S. Tsirkin
2011-11-16 8:17 ` Sasha Levin
2011-11-16 9:09 ` Michael S. Tsirkin
2011-11-11 13:03 ` Michael S. Tsirkin
2011-11-13 15:14 ` Michael S. Tsirkin
2011-11-14 6:59 ` Michael S. Tsirkin
2011-11-15 23:58 ` Rusty Russell
2011-11-16 7:03 ` Michael S. Tsirkin
2011-11-10 12:24 ` [PATCHv3 " 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=1320828366.31056.16.camel@lappy \
--to=levinsasha928@gmail.com \
--cc=aik@ozlabs.ru \
--cc=amit.shah@redhat.com \
--cc=avi@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=krkumar2@in.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--cc=pawel.moll@arm.com \
--cc=rusty@rustcorp.com.au \
--cc=shhuiw@gmail.com \
--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