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? _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
