Re: [Intel-gfx] [PATCH] drm/i915: add another virtual PCH bridge for passthrough support

2016-03-18 Thread Kay, Allen M 

This patch is require for running i915 in a VM in universal passthrough (UPT) 
mode on some systems.  UPT mode allows IGD to be passed through to a VM without 
hypervisor quirks.

Reviewed-by: Allen Kay 

> -Original Message-
> From: Jesse Barnes [mailto:jbar...@virtuousgeek.org]
> Sent: Wednesday, March 16, 2016 1:32 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Kay, Allen M 
> Subject: [PATCH] drm/i915: add another virtual PCH bridge for passthrough
> support
> 
> Some configs use the P2X type but some use a P3X type PCH, so add that to
> the detect_pch function so things work correctly.
> 
> Signed-off-by: Jesse Barnes 
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 1 +
>  drivers/gpu/drm/i915/i915_drv.h | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c
> b/drivers/gpu/drm/i915/i915_drv.c index 20e8200..6ad4390 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -504,6 +504,7 @@ void intel_detect_pch(struct drm_device *dev)
>   WARN_ON(!IS_SKYLAKE(dev) &&
>   !IS_KABYLAKE(dev));
>   } else if ((id == INTEL_PCH_P2X_DEVICE_ID_TYPE) ||
> +(id == INTEL_PCH_P3X_DEVICE_ID_TYPE) ||
>  ((id ==
> INTEL_PCH_QEMU_DEVICE_ID_TYPE) &&
>   pch->subsystem_vendor == 0x1af4 &&
>   pch->subsystem_device == 0x1100)) { diff -
> -git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 9e76bfc..e53cd42 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2695,6 +2695,7 @@ struct drm_i915_cmd_table {
>  #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_P3X_DEVICE_ID_TYPE 0x7000
>  #define INTEL_PCH_QEMU_DEVICE_ID_TYPE0x2900 /* qemu q35
> has 2918 */
> 
>  #define INTEL_PCH_TYPE(dev) (__I915__(dev)->pch_type)
> --
> 1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] How to create PCH to support those existing driver

2014-08-19 Thread Kay, Allen M 


> -Original Message-
> From: Michael S. Tsirkin [mailto:m...@redhat.com]
> Sent: Tuesday, August 19, 2014 2:51 PM
> To: Kay, Allen M
> Cc: Chen, Tiejun; Paolo Bonzini; Wang, Yong Y; Don Dutile; Jesse Barnes;
> Konrad Rzeszutek Wilk; qemu-de...@nongnu.org; xen-
> de...@lists.xensource.com; intel-gfx; Stefano Stabellini
> (stefano.stabell...@citrix.com)
> Subject: Re: How to create PCH to support those existing driver
> 
> On Tue, Aug 19, 2014 at 09:24:03PM +, Kay, Allen M wrote:
> > > Allen,
> > >
> > > Could you reply this?
> >
> > Let me summarized what we have discussed and learned so far:
> >
> > 1) Future Windows/Linux IGD drivers will be modified to restrain from
> accessing MCH/PCH devices.  We are prototyping this in Windows driver right
> now and will pass the same methodology to Linux driver once we have a
> workable solution.  The goal is removing all MCH/PCH accesses in the IGD
> driver.
> >
> > 2) We want the same solution to work in both native and virtualization
> environments.  Given most driver developers test their changes only in
> native environment, doing anything specific for virtualization in the driver 
> will
> cause frequent breakage for virtualization use cases.
> >
> > 3) Back porting this new code to support previous generations of HW will
> be problematic if not impossible.  Each Windows IGD driver release binary
> supports two generations of HW.  For example, 15.36 driver supports
> Broadwell/Haswell, 15.33 driver supports Haswell/IvyBridge, 15.31 driver
> supports Ivybridge/Sandybridge, etc.   Once the driver is product validated,
> there is little opportunity to  go back and make high impact changes that
> might affect stability in native environment.
> >
> > 4) I agree there is little reason to do anything that requires driver 
> > changes
> at this point,  unless it is the final desired solution.
> >
> > The question is whether/how to support IGD passthrough for previous
> generations of HW?
> >
> > 1) If we want to support SandyBridge/IvyBridge/Haswell/Broadwell, we will
> need most of the original QEMU patches.  We might be able to do without
> igd_pci_write().  I have tested QEMU changes without igd_pci_write() on
> both Haswell/Broadwell and Windows booted without any problems.  This
> will limit only read operations which should reduce a quite a bit of risk to 
> the
> host platform.
> 
> Excellent. I was thinking about changing host's driver to do the writes in a
> safe manner, but if don't need that, all the better.
> As a next step, we need to limit read operations to specific set of registers
> that we can validate.
> We can't just pass through reads blindly to host, pci reads have side-effects
> and host chipset isn't protected by the iommu.
> Since these are legacy devices and drivers, it should be possible to
> enumerate all registers that they need.
> 

If we limit platform support to HSW/BDW the number of register reads is quite 
small.  I believe some of the register reads are for the old Ironlake 
platforms.  I will work with Tiejun to get the smaller set for HSW/BDW systems.

> 
> > 2) If we want the upstream QEMU only work with future driver version,
> then most of the IGD passthrough patch is probably not needed - with
> exception of opregion mapping handlers.  The downside is products that
> depend on this feature will need to apply private patches separately to re-
> enable IGD passthrough capability.
> >
> > Any advice on how should Tiejun proceed from here?
> >
> > Allen
> 
> I'm fine with either trying to make existing windows and linux drivers work,
> or waiting for future drivers.
> 
> To me, quick hacks that need minor changes in driver but don't avoid poking
> at MCH/PCH don't seem to have value, I know I proposed some of these
> myself but this was before I realised a cleaner solution is possible.
> 
> 
> --
> MST

Allen
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] How to create PCH to support those existing driver

2014-08-19 Thread Kay, Allen M 
> Allen,
> 
> Could you reply this?

Let me summarized what we have discussed and learned so far:

1) Future Windows/Linux IGD drivers will be modified to restrain from accessing 
MCH/PCH devices.  We are prototyping this in Windows driver right now and will 
pass the same methodology to Linux driver once we have a workable solution.  
The goal is removing all MCH/PCH accesses in the IGD driver.

2) We want the same solution to work in both native and virtualization 
environments.  Given most driver developers test their changes only in native 
environment, doing anything specific for virtualization in the driver will 
cause frequent breakage for virtualization use cases.

3) Back porting this new code to support previous generations of HW will be 
problematic if not impossible.  Each Windows IGD driver release binary supports 
two generations of HW.  For example, 15.36 driver supports Broadwell/Haswell, 
15.33 driver supports Haswell/IvyBridge, 15.31 driver supports 
Ivybridge/Sandybridge, etc.   Once the driver is product validated, there is 
little opportunity to  go back and make high impact changes that might affect 
stability in native environment.

4) I agree there is little reason to do anything that requires driver changes 
at this point,  unless it is the final desired solution.

The question is whether/how to support IGD passthrough for previous generations 
of HW?

1) If we want to support SandyBridge/IvyBridge/Haswell/Broadwell, we will need 
most of the original QEMU patches.  We might be able to do without 
igd_pci_write().  I have tested QEMU changes without igd_pci_write() on both 
Haswell/Broadwell and Windows booted without any problems.  This will limit 
only read operations which should reduce a quite a bit of risk to the host 
platform.

2) If we want the upstream QEMU only work with future driver version, then most 
of the IGD passthrough patch is probably not needed - with exception of 
opregion mapping handlers.  The downside is products that depend on this 
feature will need to apply private patches separately to re-enable IGD 
passthrough capability.

Any advice on how should Tiejun proceed from here?

Allen

> -Original Message-
> From: Chen, Tiejun
> Sent: Monday, August 18, 2014 6:39 PM
> To: Michael S. Tsirkin
> Cc: Paolo Bonzini; Kay, Allen M; Wang, Yong Y; Don Dutile; Jesse Barnes;
> Konrad Rzeszutek Wilk; qemu-de...@nongnu.org; xen-
> de...@lists.xensource.com; intel-gfx
> Subject: Re: How to create PCH to support those existing driver
> 
> 
> 
> On 2014/8/18 17:58, Michael S. Tsirkin wrote:
> > On Mon, Aug 18, 2014 at 05:01:25PM +0800, Chen, Tiejun wrote:
> >> On 2014/8/18 16:21, Michael S. Tsirkin wrote:
> >>> On Mon, Aug 18, 2014 at 11:06:29AM +0800, Chen, Tiejun wrote:
> >>>> On 2014/8/17 18:32, Michael S. Tsirkin wrote:
> >>>>> On Fri, Aug 15, 2014 at 09:58:40AM +0800, Chen, Tiejun wrote:
> >>>>>> Michael and Paolo,
> >>>>>
> >>>>> Please re-post discussion on list. These off list ones are just
> >>>>> wasting time since they invariably have to be repeated on list again.
> >>>>
> >>>> Okay, now just reissue this discussion to all related guys. And do
> >>>> you think we need to discuss in public, qemu and xen mail list?
> >>>
> >>> Absolutely.
> >>
> >> Now -CC qemu, xen and intel-gfx.
> >>
> >> If I'm missing someone important please tell me as well.
> >>
> >>>
> >>>>>
> >>>>>> After I created that new machine specific to IGD passthrough,
> >>>>>> xenigd, now I will step next to register the PCH.
> >>>>>>
> >>>>>> IIRC, our complete solution should be as follows:
> >>>>>>
> >>>>>> #1 create a new machine based on piix, xenigd
> >>>>>>
> >>>>>> This is done with Michael help.
> >>>>>>
> >>>>>> #2 register ISA bridge
> >>>>>>
> >>>>>> 1> Its still fixed at 1f.0.
> >>>>>> 2> ISA bridge's vendor_id/device_id should be emulated but then
> >>>>>>
> >>>>>>subsystem_vendor_id = PCI_VENDOR_ID_XEN;
> >>>>>>subsystem_device_id = ISA Bridge's real device id
> >>>>>>
> >>>>>> This mean we need to change driver to walk with this way.
> >>>>>> For example, in
> >>>>>> case of Linux native driver,
> >>>>>>
> >>>>>> intel_detect_pch()
> >>>>>

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

2014-07-18 Thread Kay, Allen M 
> For the MCH PCI registers that do need to be read - can you tell us which 
> ones those are?

In qemu/hw/xen_pt_igd.c/igd_pci_read(), following MCH PCI config register reads 
are passthrough to the host HW.   Some of the registers are needed by Ironlake 
GFX driver which we probably can remove.  I did a trace recently on Broadwell,  
the number of register accessed are even smaller (0, 2, 2c, 2e, 50, 52, a0, 
a4).  Given that we now have integrated MCH and GPU in the same socket, looks 
like driver can easily remove reads for offsets 0 - 0x2e.

case 0x00:/* vendor id */
case 0x02:/* device id */
case 0x08:/* revision id */
case 0x2c:/* sybsystem vendor id */
case 0x2e:/* sybsystem id */
case 0x50:/* SNB: processor graphics control register */
case 0x52:/* processor graphics control register */
case 0xa0:/* top of memory */
case 0xb0:/* ILK: BSM: should read from dev 2 offset 
0x5c */
case 0x58:/* SNB: PAVPC Offset */
case 0xa4:/* SNB: graphics base of stolen memory */
case 0xa8:/* SNB: base of GTT stolen memory */

Allen

-Original Message-
From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com] 
Sent: Friday, July 18, 2014 6:45 AM
To: Kay, Allen M
Cc: Michael S. Tsirkin; Jesse Barnes; peter.mayd...@linaro.org; 
xen-de...@lists.xensource.com; Ross Philipson; airl...@linux.ie; 
daniel.vet...@ffwll.ch; intel-gfx@lists.freedesktop.org; kelly.zyta...@amd.com; 
qemu-de...@nongnu.org; Anthony Perard; Stefano Stabellini; 
anth...@codemonkey.ws; Paolo Bonzini; Zhang, Yang Z; Chen, Tiejun
Subject: Re: [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel 
IGD passthrough support

On Thu, Jul 17, 2014 at 05:37:12PM +0000, Kay, Allen M wrote:
> > That sounds great. Tiejun could you confirm that with windows driver guys 
> > too?
> 
> I believe windows driver can also assume specific CPU/PCH combos.  I will 
> discuss this with native Windows driver guys.  Preferably, the same code path 
> can be used for both native and virtualization cases to avoid frequent 
> breakage as most developers and QA do not test new code changes in 
> virtualization environment.
> 
> I have verified that Windows driver do not need to write to any MCH PCI 
> registers on HSW/BDW so the PCI write function can be removed.  The  MCH PCI 
> registers that need to be read, we are working with HW team to get them 
> mirrored in GPU MMIO registers in future HW.
> 

For the MCH PCI registers that do need to be read - can you tell us which ones 
those are?

Thank you!
> Allen
> 
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On 
> Behalf Of Michael S. Tsirkin
> Sent: Thursday, July 03, 2014 1:28 PM
> To: Jesse Barnes
> Cc: peter.mayd...@linaro.org; xen-de...@lists.xensource.com; Ross 
> Philipson; Konrad Rzeszutek Wilk; airl...@linux.ie; 
> daniel.vet...@ffwll.ch; intel-gfx@lists.freedesktop.org; 
> kelly.zyta...@amd.com; qemu-de...@nongnu.org; Anthony Perard; Stefano 
> Stabellini; anth...@codemonkey.ws; Paolo Bonzini; Zhang, Yang Z; Chen, 
> Tiejun
> Subject: Re: [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: 
> add Intel IGD passthrough support
> 
> On Thu, Jul 03, 2014 at 12:09:28PM -0700, Jesse Barnes wrote:
> > On Thu, 3 Jul 2014 14:26:12 -0400
> > Konrad Rzeszutek Wilk  wrote:
> > 
> > > On Thu, Jul 03, 2014 at 10:32:12AM +0300, Michael S. Tsirkin wrote:
> > > > On Wed, Jul 02, 2014 at 12:23:37PM -0400, Konrad Rzeszutek Wilk wrote:
> > > > > On Wed, Jul 02, 2014 at 04:50:15PM +0200, Paolo Bonzini wrote:
> > > > > > Il 02/07/2014 16:00, Konrad Rzeszutek Wilk ha scritto:
> > > > > > >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.
> > > > > > >
> > > > > > >1). Fix IGD hardware to not use Southbridge magic addresses.
> > > > > > >We can moan and moan but I doubt it is going to change.
> > > > > > 
> > > > > > There are two problems:
> > > > > > 
> > > > > > - Northbridge (i.e. MCH i.e. PCI host bridge) configuration 
> > > > > > space addresses
> > > > > 
> > > > > Right. So in  drivers/gpu/drm/i915/i915_dma.c:
> > > > > 1135 #define MCHBAR_I915 0x44

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

2014-07-17 Thread Kay, Allen M 
> That sounds great. Tiejun could you confirm that with windows driver guys too?

I believe windows driver can also assume specific CPU/PCH combos.  I will 
discuss this with native Windows driver guys.  Preferably, the same code path 
can be used for both native and virtualization cases to avoid frequent breakage 
as most developers and QA do not test new code changes in virtualization 
environment.

I have verified that Windows driver do not need to write to any MCH PCI 
registers on HSW/BDW so the PCI write function can be removed.  The  MCH PCI 
registers that need to be read, we are working with HW team to get them 
mirrored in GPU MMIO registers in future HW.

Allen

-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Michael S. Tsirkin
Sent: Thursday, July 03, 2014 1:28 PM
To: Jesse Barnes
Cc: peter.mayd...@linaro.org; xen-de...@lists.xensource.com; Ross Philipson; 
Konrad Rzeszutek Wilk; airl...@linux.ie; daniel.vet...@ffwll.ch; 
intel-gfx@lists.freedesktop.org; kelly.zyta...@amd.com; qemu-de...@nongnu.org; 
Anthony Perard; Stefano Stabellini; anth...@codemonkey.ws; Paolo Bonzini; 
Zhang, Yang Z; Chen, Tiejun
Subject: Re: [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel 
IGD passthrough support

On Thu, Jul 03, 2014 at 12:09:28PM -0700, Jesse Barnes wrote:
> On Thu, 3 Jul 2014 14:26:12 -0400
> Konrad Rzeszutek Wilk  wrote:
> 
> > On Thu, Jul 03, 2014 at 10:32:12AM +0300, Michael S. Tsirkin wrote:
> > > On Wed, Jul 02, 2014 at 12:23:37PM -0400, Konrad Rzeszutek Wilk wrote:
> > > > On Wed, Jul 02, 2014 at 04:50:15PM +0200, Paolo Bonzini wrote:
> > > > > Il 02/07/2014 16:00, Konrad Rzeszutek Wilk ha scritto:
> > > > > >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.
> > > > > >
> > > > > >1). Fix IGD hardware to not use Southbridge magic addresses.
> > > > > >We can moan and moan but I doubt it is going to change.
> > > > > 
> > > > > There are two problems:
> > > > > 
> > > > > - Northbridge (i.e. MCH i.e. PCI host bridge) configuration 
> > > > > space addresses
> > > > 
> > > > Right. So in  drivers/gpu/drm/i915/i915_dma.c:
> > > > 1135 #define MCHBAR_I915 0x44   
> > > >  
> > > > 1136 #define MCHBAR_I965 0x48 
> > > > 
> > > > 1147 int reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : 
> > > > MCHBAR_I915;
> > > > 1152 if (INTEL_INFO(dev)->gen >= 4) 
> > > >  
> > > > 1153 pci_read_config_dword(dev_priv->bridge_dev, reg + 
> > > > 4, &temp_hi); 
> > > > 1154 pci_read_config_dword(dev_priv->bridge_dev, reg, 
> > > > &temp_lo); 
> > > > 1155 mchbar_addr = ((u64)temp_hi << 32) | temp_lo;  
> > > >   
> > > > 
> > > > and
> > > > 
> > > > 1139 #define DEVEN_REG 0x54 
> > > >  
> > > > 
> > > > 1193 int mchbar_reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : 
> > > > MCHBAR_I915; 
> > > > 1202 if (IS_I915G(dev) || IS_I915GM(dev)) { 
> > > >  
> > > > 1203 pci_read_config_dword(dev_priv->bridge_dev, 
> > > > DEVEN_REG, &temp);  
> > > > 1204 enabled = !!(temp & DEVEN_MCHBAR_EN);  
> > > >  
> > > > 1205 } else {   
> > > >  
> > > > 1206 pci_read_config_dword(dev_priv->bridge_dev, 
> > > > mchbar_reg, &temp); 
> > > > 1207 enabled = temp & 1;
> > > >  
> > > > 1208 }
> > > > > 
> > > > > - Southbridge (i.e. PCH i.e. ISA bridge) vendor/device ID; 
> > > > > some versions of the driver identify it by class, some versions 
> > > > > identify it by slot (1f.0).
> > > > 
> > > > Right, So in  drivers/gpu/drm/i915/i915_drv.c the giant 
> > > > intel_detect_pch which sets the pch_type based on :
> > > > 
> > > >  432 if (pch->vendor == PCI_VENDOR_ID_INTEL) {  
> > > >  
> > > >  433 unsigned short id = pch->device & 
> > > > INTEL_PCH_DEVICE_ID_MASK;
> > > >  434 dev_priv->pch_id = id; 
> > > >  
> > > >  435
> > > >  
> > > >  436 if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) { 
> > > > 
> > > > It checks for 0x3b00, 0x1c00, 0x1e00, 0x8c00 and 0x9c00.
> > > > The INTEL_PCH_DEVICE_ID_MASK is 0xff00
> > > > > 
> > > > > To solve the first, make a new machine type, PIIX4-based, and 
> > > > > pass through the registers you need.  The patch must document 
> > > >

[Intel-gfx] unbinding graphics driver

2011-10-04 Thread Kay, Allen M 
I'm working on assigning Intel graphics to a guest OS in Xen/KVM environment.  
Before assigning the device to the guest OS, I need to first unbind the i915 
driver from the device in the host kernel.

If I unbind the i915 driver  by doing "echo -n :00:02.0 > 
/sys/bus/pci/devices/:00:02.0/driver/unbind", I get a kernel oops with no 
stack trace.  Is this something theoretically allowed?

I have also tried to prevent the i915 driver from loading by renaming the drm 
directory in /lib/modules to drm.0.  However, i915 driver is still loaded from 
somewhere, I don't know how it can happen.  Is there a easy way to disable the 
i915 driver in the kernel?

Allen

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx