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