[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [iGVT-g] [PATCH v2] vfio/igd: handle q35 machine type
From: |
Tian, Kevin |
Subject: |
Re: [Qemu-devel] [iGVT-g] [PATCH v2] vfio/igd: handle q35 machine type |
Date: |
Thu, 10 Mar 2016 05:49:22 +0000 |
> 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