On Thu, 19 Mar 2015 10:50:49 +0100 "Michael S. Tsirkin" <m...@redhat.com> 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 <dgib...@redhat.com> Senior Software Engineer, Virtualization, Red Hat
pgpXo_MDeqCs_.pgp
Description: OpenPGP digital signature
