linux-kernel - RE: [Intel-gfx] [RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead of check class type

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 10 Jul 2014 21:08:24 +0000
From:	"Tian, Kevin" <kevin.tian@...el.com>
To:	Daniel Vetter <daniel@...ll.ch>,
	Paolo Bonzini <pbonzini@...hat.com>
CC:	"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>,
	"airlied@...ux.ie" <airlied@...ux.ie>,
	"intel-gfx@...ts.freedesktop.org" <intel-gfx@...ts.freedesktop.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"qemu-devel@...gnu.org" <qemu-devel@...gnu.org>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	"Chen, Tiejun" <tiejun.chen@...el.com>,
	"Kay, Allen M" <allen.m.kay@...el.com>
Subject: RE: [Intel-gfx] [RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to
 check devfn instead of check class type

> From: Daniel Vetter
> Sent: Monday, July 07, 2014 11:40 AM
> 
> On Mon, Jul 07, 2014 at 07:58:30PM +0200, Paolo Bonzini wrote:
> > Il 07/07/2014 19:54, Daniel Vetter ha scritto:
> > >On Mon, Jul 07, 2014 at 04:57:45PM +0200, Paolo Bonzini wrote:
> > >>Il 07/07/2014 16:49, Daniel Vetter ha scritto:
> > >>>So the correct fix to forward intel gpus to guests is indeed to somehow
> > >>>fake the pch pci ids since the driver really needs them. Gross design, but
> > >>>that's how the hardware works.
> > >>
> > >>A way that could work for virtualization is this: if you find the card has a
> > >>magic subsystem vendor id, fetch the subsystem device id and use _that_
> as
> > >>the PCH device id.
> > >>
> > >>Would that work for you?
> > >
> > >I guess for quemu it also depends upon what windows does since we can't
> > >change that. If we care about that part. Another consideration is
> > >supporting older kernels, if that's possible at all.
> >
> > Yes, but right now it's more important to get something that's not too gross
> > for the future, for both Linux and Windows.  Hacks for existing guests can
> > be done separately, especially since they might differ between Linux (check
> > ISA bridge) and Windows (check 1f.0).
> 
> Well old Linux also checked 1f.0, so kinda the same really. As long as
> 1f.0 is an isa bridge. Wrt Windows I don't really expect them to change
> this (they're probably more focuesed on the windows hypervisor or whatever).

discussion is also on-going with Windows driver folks. Add Allen here.

> 
> In the end if the approach is ok for quemu and isn't much worse than what
> we currently have I don't mind at all about the i915.ko code. I just want
> to avoid flip-flopping around on the hack du jour like we seem to do just
> now.
> -Daniel

actually I'm curious whether it's still necessary to __detect__ PCH. Could
we assume a 1:1 mapping between GPU and PCH, e.g. BDW already hard
code the knowledge:

              } else if (IS_BROADWELL(dev)) {
                      dev_priv->pch_type = PCH_LPT;
                      dev_priv->pch_id =
                              INTEL_PCH_LPT_LP_DEVICE_ID_TYPE;
                      DRM_DEBUG_KMS("This is Broadwell, assuming "
                                    "LynxPoint LP PCH\n");

Or if there is real usage on non-fixed mapping (not majority), could it be a 
better option to have fixed mapping as a fallback instead of leaving as 
PCH_NONE? Then even when Qemu doesn't provide a special tweaked PCH,
the majority case just works.

Thanks
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/