linux-kernel - Re: [PATCHv2 RFC] virtio-spec: flexible configuration layout

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 9 Nov 2011 23:14:46 +0200
From:	"Michael S. Tsirkin" <mst@...hat.com>
To:	Sasha Levin <levinsasha928@...il.com>
Cc:	Rusty Russell <rusty@...tcorp.com.au>,
	lkml - Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Alexey Kardashevskiy <aik@...abs.ru>,
	Amit Shah <amit.shah@...hat.com>,
	Christian Borntraeger <borntraeger@...ibm.com>,
	Krishna Kumar <krkumar2@...ibm.com>,
	Pawel Moll <pawel.moll@....com>,
	Wang Sheng-Hui <shhuiw@...il.com>,
	virtualization@...ts.linux-foundation.org, kvm@...r.kernel.org,
	avi@...hat.com, penberg@...nel.org
Subject: Re: [PATCHv2 RFC] virtio-spec: flexible configuration layout

On Wed, Nov 09, 2011 at 10:57:28PM +0200, Sasha Levin wrote:
> 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.

Yes, this is what I meant. New guest is required to use the new space
and not the legacy one. So you dont need a legacy space for the at all.
But practically, we'll need to support old guests for a long while.

> > > 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.

Yes, it's allowed if you know you have a new guest. It says
explicitly that drivers are required to use new capabilities
is they are there.

> 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.

If hypervisors don't implement the new layout then drivers will
have to keep supporting the old one. I don't think we can do
much about that.

> > 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.

We can only do this after all guests and hypervisors are updated. When
they are, we can drop legacy from drivers and hypervisors, and
I don't see a way to make it easier.

> -- 
> 
> Sasha.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/