On Wed, Nov 17, 2010 at 11:03:14AM +0900, Isaku Yamahata wrote:
> On Tue, Nov 16, 2010 at 12:50:19PM +0200, Michael S. Tsirkin wrote:
> > On Tue, Nov 16, 2010 at 05:26:05PM +0900, Isaku Yamahata wrote:
> > > This patch cleans up command register initialization with
> > > comments. It also fixes the initialization of io/memory bit of command
> > > register.
> > > Those bits for type 1 device is RW.
> > > Those bits for type 0 device is
> > > RO = 0 if it has no io/memory BAR
> > > RW if it has io/memory BAR
> > >
> > > Signed-off-by: Isaku Yamahata <yamah...@valinux.co.jp>
> >
> > There's a bug here: you can not assume that device that has
> > no io BAR claims no io transactions.
>
> Which device are you mentioning?
Look at appendix D in PCI spec. There are many programming
classes like display controllers that claim specific
addresses without using a BAR. We could code it all
up with a huge table. But what we have is much simpler
and works well AFAIK.
> Such device should set the bit by itself, not by pci generic layer.
Since this is PCI spec specified behaviour, I think it's better
to have it in a common place. Devices are sure to get it wrong.
> > Another bug is that migrating from qemu where a bit is writeable to one
> > where it's RO creates a situation where a RW bit becomes RO, or the
> > reverse, which might confuse guests. So we will need a compatibility
> > flag and set it for old machine types.
>
> We needs to keep compatibility. Which way do you prefer?
>
> - don't care: no way
>
> - introduce global property to indicate compat qemu version or flags
> something like if (compat version <= 0.13) old behaviour...
> or if (flags & ...)
>
> - introduce global-pci property
>
> - introduce pci bus property
> Users needs to specify this property for all pci devices.
>
> - Don't change common code(pci.c), and provide a helper function.
> Each device which needs new behavior like pcie calls it.
> Probably each device may provide property to specify compat behavior
>
> - any other?
- Don't change behaviour at all.
What is the motivation for the change? Why do we bother? What we have
is spec compliant, I think, so it's hard for me to believe pcie *needs*
the new behaviour.
