From: Sasha Levin <levinsasha928@gmail.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Krishna Kumar <krkumar2@in.ibm.com>,
kvm@vger.kernel.org, Pawel Moll <pawel.moll@arm.com>,
Wang Sheng-Hui <shhuiw@gmail.com>,
Alexey Kardashevskiy <aik@ozlabs.ru>,
lkml - Kernel Mailing List <linux-kernel@vger.kernel.org>,
virtualization@lists.linux-foundation.org, penberg@kernel.org,
Christian Borntraeger <borntraeger@de.ibm.com>,
avi@redhat.com, Amit Shah <amit.shah@redhat.com>
Subject: Re: [PATCHv2 RFC] virtio-spec: flexible configuration layout
Date: Wed, 09 Nov 2011 22:57:28 +0200 [thread overview]
Message-ID: <1320872248.3730.11.camel@lappy> (raw)
In-Reply-To: <20111109205208.GA28599@redhat.com>
On Wed, 2011-11-09 at 22:52 +0200, Michael S. Tsirkin wrote:
> On Wed, Nov 09, 2011 at 10:24:47PM +0200, Sasha Levin wrote:
> > On Wed, 2011-11-09 at 21:59 +0200, Michael S. Tsirkin wrote:
> >
> > [snip]
> >
> > > +\begin_layout Enumerate
> > > +Reset the device.
> > > + This is not required on initial start up.
> > > +\end_layout
> > > +
> > > +\begin_layout Enumerate
> > > +The ACKNOWLEDGE status bit is set: we have noticed the device.
> > > +\end_layout
> > > +
> > > +\begin_layout Enumerate
> > > +The DRIVER status bit is set: we know how to drive the device.
> > > +\end_layout
> > > +
> > > +\begin_layout Enumerate
> > > +
> > > +\change_inserted 1986246365 1320838089
> > > +PCI capability list scan, detecting virtio configuration layout using Virtio
> > > + Structure PCI capabilities.
> >
> > Does the legacy space always gets mapped from BAR0?
> >
> > If yes,
>
> Yes and this is repeated in several places. Not clear? How can this
> be made clearer?
Do you mean comments such as "For backwards compatibility, devices
should also present legacy configuration space in the first I/O region
of the PCI device"? What I understood from it is that the device should
have a legacy config in case it's used with an older guest, but I didn't
understand from it that the legacy config will be used even if new
layout is present.
> > It'll be a bit harder deprecating it in the future.
>
> Harder than ... what ?
Harder than allowing devices not to present it at all if new layout
config is used. Right now the simple implementation is to use MMIO for
config and device specific, and let it fallback to legacy for ISR and
notifications (and therefore, this is probably how everybody will
implement it), which means that when you do want to deprecate legacy,
there will be extra work to be done then, instead of doing it now.
> IMO there's no way to put legacy anywhere except the first BAR
> without breaking existing guests.
It's not about where we put legacy, it's about how easy it is to drop
legacy entirely.
--
Sasha.
next prev parent reply other threads:[~2011-11-09 20:57 UTC|newest]
Thread overview: 68+ 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
[not found] ` <8739e7uy87.fsf@rustcorp.com.au>
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-08 21:41 ` Michael S. Tsirkin
2011-11-09 10:21 ` Avi Kivity
2011-11-09 8:46 ` Sasha Levin
2011-11-09 9:55 ` Sasha Levin
[not found] ` <1320832502.31056.22.camel@lappy>
2011-11-09 10:18 ` Michael S. Tsirkin
2011-11-09 10:20 ` Sasha Levin
2011-11-09 10:47 ` Pawel Moll
[not found] ` <1320835653.3259.138.camel@hornet.cambridge.arm.com>
2011-11-09 10:55 ` Sasha Levin
2011-11-09 11:06 ` Pawel Moll
[not found] ` <1320836793.3259.151.camel@hornet.cambridge.arm.com>
2011-11-09 11:39 ` Peter Maydell
2011-11-09 12:07 ` Sasha Levin
[not found] ` <1320828366.31056.16.camel@lappy>
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
[not found] ` <alpine.LFD.2.02.1111091421570.4936@tux.localdomain>
2011-11-09 12:28 ` Sasha Levin
2011-11-09 12:36 ` Pekka Enberg
[not found] ` <alpine.LFD.2.02.1111091434230.4936@tux.localdomain>
2011-11-09 15:33 ` Michael S. Tsirkin
2012-06-18 11:54 ` Michael S. Tsirkin
2012-06-18 12:05 ` Sasha Levin
[not found] ` <1340021117.22848.3.camel@lappy>
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-09 15:51 ` Michael S. Tsirkin
[not found] ` <20111109151954.GA25329@redhat.com>
2011-11-13 14:07 ` Ronen Hod
2011-11-13 20:40 ` Vadim Rozenfeld
2011-11-09 19:59 ` [PATCHv2 " Michael S. Tsirkin
2011-11-09 20:00 ` 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 [this message]
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
[not found] ` <87aa83qoao.fsf@rustcorp.com.au>
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=1320872248.3730.11.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=penberg@kernel.org \
--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;
as well as URLs for NNTP newsgroup(s).