Re: [Qemu-devel] [iGVT-g] [PATCH v2] vfio/igd: handle q35 machine type

[Tian, Kevin]

> 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