Re: [Qemu-devel] [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Jul 02, 2014 at 12:05:27PM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Jul 02, 2014 at 05:08:43PM +0300, Michael S. Tsirkin wrote:
> > On Wed, Jul 02, 2014 at 10:00:33AM -0400, Konrad Rzeszutek Wilk wrote:
> > > On Wed, Jul 02, 2014 at 01:33:09PM +0200, Paolo Bonzini wrote:
> > > > Il 01/07/2014 19:39, Ross Philipson ha scritto:
> > > > >
> > > > >We do IGD pass-through in our project (XenClient). The patches
> > > > >originally came from our project. We surface the same ISA bridge and
> > > > >have never had activation issues on any version of Widows from XP to
> > > > >Win8. We do not normally run server platforms so I can't say for sure
> > > > >there.
> > > > 
> > > > The problem is not activation, the problem is that the patches are making
> > > > assumptions on the driver and the firmware that might work today but are
> > > > IMHO just not sane.
> > > > 
> > > > I would have no problem with a clean patchset that adds a new machine type
> > > > and doesn't touch code in "-M pc", but it looks like mst disagrees.
> > > > Ultimately, if a patchset is too hacky for upstream, you can include it in
> > > > your downstream XenClient (and XenServer) QEMU branch.  It happens.
> > > 
> > > And then this discussion will come back again in a year when folks
> > > rebase and ask: Why hasn't this been done upstream.
> > > 
> > > Then the discussion resumes ..
> > > 
> > > With this long thread I lost a bit context about the challenges
> > > that exists. But let me try summarizing it here - which will hopefully
> > > get some consensus.
> > 
> > Before I answer could you clarify please:
> > by Southbridge do you mean the PCH at slot 1f or the MCH at slot 0 or both?
> 
> MCH slot. We read/write from this (see intel_setup_mchbar) from couple of
> registers (0x44 and 0x48 if gen >= 4, otherwise 0x54). It is hard-coded
> in the i915_get_bridge_dev (see ec2a4c3fdc8e82fe82a25d800e85c1ea06b74372)
> as 0:0.0 BDF.
> 
> The PCH (does not matter where it sits) we only use the model:vendor id
> to figure out the pch_type (see intel_detect_pch).
> 
> I don't see why that model:vendor_id can't be exposed via checking the
> type of device:vendor_id of the IGD itself. CC-ing some Intel i915 authors.
> 
> So for the discussion here, when I say Southbridge I mean MCH.

OK so PIIX spec says:

0x10-4F reserved.

So far so good, it is likely harmless to stick something at 0x44 and
0x48 most guests will very likely just keep ticking.

0x54-0x57 deal with RAM though.

Maybe we can just stick to emulating gen >= 4 for now:
detect it on host and fail assignment.
How old is gen 4?





> > 
> > > 1). Fix IGD hardware to not use Southbridge magic addresses.
> > >     We can moan and moan but I doubt it is going to change.
> > > 
> > > 2). Since we need the Southbridge magic addresses, we can expose
> > >     an bridge. [I think everybody agrees that we need to do
> > >     that since 1) is no go).
> > > 
> > > 3). What kind of bridge. We can do:
> > > 
> > >      a) Two bridges - one 'passthrough' and the legacy ISA bridge
> > >         that QEMU emulates. Both Linux and Windows are OK with
> > >         two bridges (even thought it is pretty weird).
> > > 
> > >      b) One bridge - the one that QEMU emulates - and lets emulate
> > >         more of the registers (by emulate - I mean for some get the
> > >         data from the real hardware).
> > > 
> > >            b1). We can't use the legacy because the registers are
> > >                 above 256 (is that correct? Did I miss something?)
> > > 
> > >            b2)  We would need to use the Q35.
> > >                 b2a). If we need Q35, that needs to be exposed in
> > >                       for Xen guests. That means exposing the 
> > >                       MMCONFIG and restructing the E820 to fit that
> > >                       in.
> > >                       Problem:
> > >                         - Migration is not working with Q35.
> > >                           (But for v1 you wouldn't migrate, however
> > >                            later hardware will surely have SR-IOV so
> > >                            we will need to migrate).
> > > 
> > >                         - There are no developers who have an OK
> > >                           from their management to focus on this.
> > >                            (Potential solution: Poke Intel management to see
> > >                             if they can get more developers on it)
> > >                           
> > > 
> > > 4). Code does a bit of sysfs that could use some refacturing with
> > >     the KVM code.
> > >     Problem: More time needed to do the code restructing.
> > > 
> > > 
> > > Is that about correct?
> > > 
> > > What are folks timezones and the best days next week to talk about
> > > this on either Google Hangout or the phone?