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

[Gal Hammer <ghammer@redhat.com>]

On 19/03/2015 11:50, Michael S. Tsirkin 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.
>
> 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.

I think it is wrong to have a fake PCI device just to avoid the fact 
that Windows will show the device in the devices tree. If the device 
doesn't implement the required interface, then it should impersonate to 
be one.

The PCI device implementation might be a simpler/cleaner solution but it 
can cause more problems if an application or a driver will try to access 
the device and get might get an access to the GUID memory region.

     Gal.

>> --
>> David Gibson <dgibson@redhat.com>
>> Senior Software Engineer, Virtualization, Red Hat
>
>