[Intel-gfx] [PATCH] drm/i915: Detect virtual south bridge

Daniel Vetter daniel at ffwll.ch
Sun Sep 27 23:46:34 PDT 2015


On Fri, Sep 25, 2015 at 09:52:48AM -0700, Jesse Barnes wrote:
> On 09/25/2015 08:31 AM, Jesse Barnes wrote:
> > On 09/24/2015 08:41 PM, Tian, Kevin wrote:
> >>> From: Jesse Barnes [mailto:jbarnes at virtuousgeek.org]
> >>> Sent: Friday, September 25, 2015 12:41 AM
> >>>
> >>> On 08/28/2015 05:10 AM, robert.beckett at intel.com wrote:
> >>>> From: Robert Beckett <robert.beckett at intel.com>
> >>>>
> >>>> Virtualized systems often use a virtual P2X4 south bridge.
> >>>> Detect this in intel_detect_pch and make a best guess as to which PCH
> >>>> we should be using.
> >>>>
> >>>> This was seen on vmware esxi hypervisor. When passing the graphics device
> >>>> through to a guest, it can not pass through the PCH. Instead it simulates
> >>>> a P2X4 southbridge.
> >>>>
> >>>> Signed-off-by: Robert Beckett <robert.beckett at intel.com>
> >>>> ---
> >>>>  drivers/gpu/drm/i915/i915_drv.c |   30
> >>> ++++++++++++++++++++++++++++++
> >>>>  drivers/gpu/drm/i915/i915_drv.h |    1 +
> >>>>  2 files changed, 31 insertions(+)
> >>>>
> >>>> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> >>>> index ce3bd0c..8e158b3 100644
> >>>> --- a/drivers/gpu/drm/i915/i915_drv.c
> >>>> +++ b/drivers/gpu/drm/i915/i915_drv.c
> >>>> @@ -443,6 +443,34 @@ static const struct pci_device_id pciidlist[] = {		/* aka
> >>> */
> >>>>
> >>>>  MODULE_DEVICE_TABLE(pci, pciidlist);
> >>>>
> >>>> +static enum intel_pch intel_virt_detect_pch(struct drm_device *dev)
> >>>> +{
> >>>> +	enum intel_pch ret = PCH_NOP;
> >>>> +
> >>>> +	/*
> >>>> +	 * In a virtualized passthrough environment we can be in a
> >>>> +	 * setup where the ISA bridge is not able to be passed through.
> >>>> +	 * In this case, a south bridge can be emulated and we have to
> >>>> +	 * make an educated guess as to which PCH is really there.
> >>>> +	 */
> >>>> +
> >>>> +	if (IS_GEN5(dev)) {
> >>>> +		ret = PCH_IBX;
> >>>> +		DRM_DEBUG_KMS("Assuming Ibex Peak PCH\n");
> >>>> +	} else if (IS_GEN6(dev) || IS_IVYBRIDGE(dev)) {
> >>>> +		ret = PCH_CPT;
> >>>> +		DRM_DEBUG_KMS("Assuming CouarPoint PCH\n");
> >>>> +	} else if (IS_HASWELL(dev) || IS_BROADWELL(dev)) {
> >>>> +		ret = PCH_LPT;
> >>>> +		DRM_DEBUG_KMS("Assuming LynxPoint PCH\n");
> >>>> +	} else if (IS_SKYLAKE(dev)) {
> >>>> +		ret = PCH_SPT;
> >>>> +		DRM_DEBUG_KMS("Assuming SunrisePoint PCH\n");
> >>>> +	}
> >>>> +
> >>>> +	return ret;
> >>>> +}
> >>>> +
> >>>>  void intel_detect_pch(struct drm_device *dev)
> >>>>  {
> >>>>  	struct drm_i915_private *dev_priv = dev->dev_private;
> >>>> @@ -503,6 +531,8 @@ void intel_detect_pch(struct drm_device *dev)
> >>>>  				dev_priv->pch_type = PCH_SPT;
> >>>>  				DRM_DEBUG_KMS("Found SunrisePoint LP PCH\n");
> >>>>  				WARN_ON(!IS_SKYLAKE(dev));
> >>>> +			} else if (id == INTEL_PCH_P2X_DEVICE_ID_TYPE) {
> >>>> +				dev_priv->pch_type = intel_virt_detect_pch(dev);
> >>>>  			} else
> >>>>  				continue;
> >>>>
> >>>> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> >>>> index 8c93845..6eb0230 100644
> >>>> --- a/drivers/gpu/drm/i915/i915_drv.h
> >>>> +++ b/drivers/gpu/drm/i915/i915_drv.h
> >>>> @@ -2584,6 +2584,7 @@ struct drm_i915_cmd_table {
> >>>>  #define INTEL_PCH_LPT_LP_DEVICE_ID_TYPE		0x9c00
> >>>>  #define INTEL_PCH_SPT_DEVICE_ID_TYPE		0xA100
> >>>>  #define INTEL_PCH_SPT_LP_DEVICE_ID_TYPE		0x9D00
> >>>> +#define INTEL_PCH_P2X_DEVICE_ID_TYPE		0x7100
> >>>>
> >>>>  #define INTEL_PCH_TYPE(dev) (__I915__(dev)->pch_type)
> >>>>  #define HAS_PCH_SPT(dev) (INTEL_PCH_TYPE(dev) == PCH_SPT)
> >>>>
> >>>
> >>> Assuming Kevin is ok with this:
> >>> Reviewed-by: Jesse Barnes <jbarnes at virtuousgeek.org>
> >>
> >> Yes, I'm OK with this change. Just one comment. Does it make
> >> sense to always have the guess as the fallback, instead of only
> >> for P2X? If native side is OK with this, it will remove the need 
> >> to add more IDs for different hypervisors in the future...
> > 
> > Yeah, at this point I don't think we have mix & match cases to worry
> > about, so we could guess based on the GPU type across the board.
> 
> On second thought, let's get this version merged first, then play with
> assuming a bridge type in a later patch, in case that breaks something.

Queued for -next, thanks for the patch.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


More information about the Intel-gfx mailing list