> From: Gerd Hoffmann > Sent: Wednesday, March 09, 2016 11:01 PM > > Hi, > > [ context for igvt list: how do we deal with the ich9 lpc emulated by > q35 machine type best, when pci-assigning a igd? ] > > > > It seems > > > quite limiting of igd assignment on q35 VMs if we're going to remove > > > collateral device modification. Should we only claim "legacy" igd > > > support on 440FX and support only universal passthrough on q35? Thanks, > > > > I'll go test this a bit more. Possibly we can drop the whole lpc > > tweaking. At least when looking at the linux driver code it doesn't > > seem to be very important. > > Ok, we can't, it's actually checked in quite a few places. The checks > are hidden in a macro though which I initially didn't spot. The bios is > unhappy too if the lpc @ 1f.0 goes away. > > But just copying over the pci ids doesn't work either, it breaks > firmware q35 initialization. Which in turn breaks acpi (partly), so > some things like poweroff stop working. And I have some irq routing > errors in the kernel log too. > > So, q35 works (without lpc tweaks) with 4.5-rc6+ guest kernel (should be > 4.4.5+ soon) and bios rom disabled. That is at least a start. > > To get the bios and older kernels working we have to fiddle with the > lpc. Copying from the host looks bad to me, we have to maintain tons of > pci ids in the firmware then. At least the intel driver only needs to > know which pch generation is used, so we might be able to get away with > one pch per igd generation, and hopefully can stop doing that long term, > when intel untangles igd and pch in hardware. >
Yes, in the future we can expect sort of default PCH generation based on PCIID, when no lpc is exposed. Thanks Kevin