[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH V14 2/3] pc: add a Virtual Machine Generation ID
From: |
David Gibson |
Subject: |
Re: [Qemu-devel] [PATCH V14 2/3] pc: add a Virtual Machine Generation ID device |
Date: |
Fri, 20 Mar 2015 15:58:16 +1100 |
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
- Re: [Qemu-devel] [PATCH V14 2/3] pc: add a Virtual Machine Generation ID device, (continued)
- Re: [Qemu-devel] [PATCH V14 2/3] pc: add a Virtual Machine Generation ID device, Michael S. Tsirkin, 2015/03/04
- Re: [Qemu-devel] [PATCH V14 2/3] pc: add a Virtual Machine Generation ID device, Andreas Färber, 2015/03/04
- Re: [Qemu-devel] [PATCH V14 2/3] pc: add a Virtual Machine Generation ID device, Igor Mammedov, 2015/03/04
- Re: [Qemu-devel] [PATCH V14 2/3] pc: add a Virtual Machine Generation ID device, Michael S. Tsirkin, 2015/03/04
- Re: [Qemu-devel] [PATCH V14 2/3] pc: add a Virtual Machine Generation ID device, Igor Mammedov, 2015/03/04
- Re: [Qemu-devel] [PATCH V14 2/3] pc: add a Virtual Machine Generation ID device, Michael S. Tsirkin, 2015/03/04
- Re: [Qemu-devel] [PATCH V14 2/3] pc: add a Virtual Machine Generation ID device, Igor Mammedov, 2015/03/05
- Re: [Qemu-devel] [PATCH V14 2/3] pc: add a Virtual Machine Generation ID device, David Gibson, 2015/03/11
- Re: [Qemu-devel] [PATCH V14 2/3] pc: add a Virtual Machine Generation ID device, Michael S. Tsirkin, 2015/03/19
- Re: [Qemu-devel] [PATCH V14 2/3] pc: add a Virtual Machine Generation ID device, Gal Hammer, 2015/03/19
- Re: [Qemu-devel] [PATCH V14 2/3] pc: add a Virtual Machine Generation ID device,
David Gibson <=
[Qemu-devel] [PATCH V14 1/3] docs: vm generation id device's description, Igor Mammedov, 2015/03/03