From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40718) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YYp06-0001aS-9H for qemu-devel@nongnu.org; Fri, 20 Mar 2015 00:57:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YYp01-0007VR-9t for qemu-devel@nongnu.org; Fri, 20 Mar 2015 00:57:38 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35891) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YYp01-0007Uu-37 for qemu-devel@nongnu.org; Fri, 20 Mar 2015 00:57:33 -0400 Date: Fri, 20 Mar 2015 15:58:16 +1100 From: David Gibson Message-ID: <20150320155816.7d3279d0@voom.fritz.box> In-Reply-To: <20150319091051-mutt-send-email-mst@redhat.com> References: <20150303173539.GA21824@redhat.com> <20150303213351.43e8333e@igors-macbook-pro.local> <20150304121148.GA27667@redhat.com> <20150304141232.0ab69867@nial.brq.redhat.com> <20150304134900.GA29478@redhat.com> <20150304161444.46407c29@nial.brq.redhat.com> <20150304153139.GA4020@redhat.com> <20150304173342.681ca7f8@nial.brq.redhat.com> <20150304191231.GB7092@redhat.com> <20150311163541.6ec72541@voom.fritz.box> <20150319091051-mutt-send-email-mst@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/ATwbrAe8uVc8dIklJpSd_5y"; protocol="application/pgp-signature" Subject: Re: [Qemu-devel] [PATCH V14 2/3] pc: add a Virtual Machine Generation ID device List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: ghammer@redhat.com, Igor Mammedov , qemu-devel@nongnu.org, afaerber@suse.de --Sig_/ATwbrAe8uVc8dIklJpSd_5y Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Thu, 19 Mar 2015 10:50:49 +0100 "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. > > > >=20 > > > > > so it binds a generic driver to it, but then we get > > > > According to device manager no driver is bound to it and neither ne= eded. > > > >=20 > > > > > 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. > > > >=20 > > > > But yes we get lucky that Windows has stub device description. > > >=20 > > > 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. > >=20 > > 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. > >=20 > > Basically, SLOF is setting the device_type property for all PCI devices > > based on the PCI class code - it's device_type =3D "memory" that causes > > the kernel to erroneously pick up the PCI device as regular RAM. > >=20 > > 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. > >=20 > > 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. >=20 > 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? >=20 > 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. --=20 David Gibson Senior Software Engineer, Virtualization, Red Hat --Sig_/ATwbrAe8uVc8dIklJpSd_5y Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVC6joAAoJEGw4ysog2bOSIc8P/R9LoMO/XRrrPpz6ylv95GEC AbA24JaeNSfAcb9aKkQ1Mf3aO+zf8yUexxGhrG7j5MVhGKFexV3DommF9kJyHpsK w4QNm8wngJN/PnCmtEcQ358e4tT/2+ZtDeVFYAMsDCe2CAoc5T/855t7EDp3+xJH +8BuD02eeiUI7F5XfcSc5tKY5UL1WSnI7OkwVM3RBBE/PILxAsixPHnEzSxbhxmr wySsVKGPVe0BCTbQYmy/0QXfIhQh0Nz1qDgIm0AbPJjfKfLO52c5319IcqdcniEj OHASTw10ldL4cpy010fdgUDU0EFTJhzcNJrX6smSmqZNuTFVEXFLa3ey4BCuBBWV l0wLtlSULuhG0nU/AQWm2l8z+IgZW9bS7WOPooVbk34zv7XCWfIpt1yNvddCcah0 Tsj7PymQ2ku2xTWPDuhxlZF3nRmoczzogfEvUnnhYUB7Dx1qQMihGUWF8UXQG9Qh SYhKKfC3kK1+638A82ufcGnpPGZ1SlYCJDXwQedAVSgqiUbg0VcfHA1qvZbOjBcm 8BECVxLTcekTJQm0Fv88+lFENIwlsYcCx0RzKY7KU9xO4D1DKLBgvpYWiUiCXayi +uhzN9bb2kap8hVivV61TwLGLWSreeKHrRTlDGVOL0+MheRo1b2Q5SVrsGHW9psD 0szPHipw2pDrqbsIKr5p =zB+u -----END PGP SIGNATURE----- --Sig_/ATwbrAe8uVc8dIklJpSd_5y--