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

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

[Konrad Rzeszutek Wilk]

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.
> 
> > 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?

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

[Michael S. Tsirkin]

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?

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

[Konrad Rzeszutek Wilk]

On Wed, Jul 02, 2014 at 06:29:23PM +0200, Paolo Bonzini wrote:
> Il 02/07/2014 17:27, Michael S. Tsirkin ha scritto:
> > At some level, maybe Paolo is right.  Ignore existing drivers and ask
> > intel developers to update their drivers to do something sane on
> > hypervisors, even if they do ugly things on real hardware.
> > 
> > A simple proposal since what I wrote earlier though apparently wasn't
> > very clear:
> > 
> >   Detect Xen subsystem vendor id on vga card.
> >   If there, avoid poking at chipset. Instead
> > 	- use subsystem device # for card type
> 
> You mean for PCH type (aka PCH device id).
> 
> > 	- use second half of BAR0 of device
> > 	- instead of access to pci host
> > 
> > hypervisors will simply take BAR0 and double it in size,
> > make second part map to what would be the pci host.
> 
> Nice.  Detecting the backdoor via the subsystem vendor id
> is clever.
> 
> I'm not sure if it's possible to just double the size of BAR0 
> or not, but my laptop has:
> 
> 	Region 0: Memory at d0000000 (64-bit, non-prefetchable) [size=4M]
> 	Region 2: Memory at c0000000 (64-bit, prefetchable) [size=256M]
> 	Region 4: I/O ports at 5000 [size=64]
> 
> and I hope we can reserve a few KB for hypervisors within those
> 4M, or 8 bytes for an address/data pair (like cf8/cfc) within BAR4's
> 64 bytes (or grow BAR4 to 128 bytes, or something like that).
> 
> Xen can still add the hacky machine type if they want for existing 
> hosts, but this would be a nice way forward.

It would be good to understand first why i915 in the first place
needs to setup the bridge MBAR if it has not been set. As in, why
is this region needed? Is it needed to flush the pipeline (as in
you need to write there?) or .. 

Perhaps it is not needed anymore with the current hardware and
what can be done is put a stake in the ground saying that only
genX or later will be supported.

The commit ids allude to power managament and the earlier commits
did poke there - but I don't see it on the latest tree.
> 
> Paolo
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel