Re: [Qemu-devel] [PATCH V14 2/3] pc: add a Virtual Machine Generation ID device

[David Gibson]

On Thu, 19 Mar 2015 10:50:49 +0100
"Michael S. Tsirkin" <address@hidden> wrote:

> On Wed, Mar 11, 2015 at 04:35:41PM +1100, David Gibson wrote:
> > > > > So it boils down to the fact that windows thinks it's RAM,
> > > > It thinks it's PCI Standard RAM Controller not RAM itself.
> > > > 
> > > > > so it binds a generic driver to it, but then we get
> > > > According to device manager no driver is bound to it and neither needed.
> > > > 
> > > > > lucky and it does not try to use it as RAM.
> > > > Video cards also use a bunch of "PCI Standard RAM Controller"
> > > > devices I guess to expose additional VRAM,
> > > > That doesn't mean that BARs are to be used by OS as conventional RAM
> > > > it's rather for usage by vendor's driver.
> > > > Same goes for ivshmem which is also expose RAM bar and has the same 
> > > > CLASS ID,
> > > > BAR's RAM is used only by means of ivshmem driver.
> > > > 
> > > > But yes we get lucky that Windows has stub device description.
> > > 
> > > OK. So if you are going to rely on this,
> > > I think it's a good idea to get ack from David to confirm
> > > this is solvable for pseries.
> > 
> > I've looked into this a bit more.  We've confirmed it's definitely a
> > bug in SLOF - but fixing it is a bit more subtle than I thought.
> > 
> > Basically, SLOF is setting the device_type property for all PCI devices
> > based on the PCI class code - it's device_type = "memory" that causes
> > the kernel to erroneously pick up the PCI device as regular RAM.
> > 
> > In fact, device_type is supposed to indicate the capabilities of the OF
> > driver attached to the device, so it should only be set by an actual OF
> > driver binding to the device, not generically in the PCI code.
> > 
> > The catch is whether we'll break any existing SLOF supported devices is
> > we remove setting of the device_type.  This will need some testing.
> 
> I guess we can look for some other IDs to use, as well.
> Host pci bridge class binds to NO_DRV too:
> class 0x0604.  So that's one other option.

Fwiw, some further investigation suggests that removing the bogus
device_type setting should be safer than we initially feared.  I am
planning to merge the SLOF change downstream just as soon as I get a
chance.

So, pseries shouldn't be a barrier to this.

> There are also many devices for which windows won't require a driver.
> For example, Intel, taken at random:
> 2620  E8500/E8501 eXternal Memory Bridge
> 277c  82975X Memory Controller Hub
> 3600  7300 Chipset Memory Controller Hub
> Are we more, or less likely to see problems
> with one of these?
> 
> It seems hard to decide, either way.

The current class 0x0500 device does have the advantage of sorts that
there isn't really a specification of what precisely it's supposed to
do (i.e. what the programming interface is).  If any of those other
examples *do* require a specific programming interface, then
advertising as one without implementing that interface would be worse
than the current class 0x0500 approach.

-- 
David Gibson <address@hidden>
Senior Software Engineer, Virtualization, Red Hat

pgpuw1nVCeKrq.pgp
Description: OpenPGP digital signature