Re: [PATCH] PCI: vmd: Filter resource type bits from shadow register

Re: [PATCH] PCI: vmd: Filter resource type bits from shadow register

[Derrick, Jonathan]

Anything wrong with this, Lorenzo?

Thanks

On Fri, 2020-03-20 at 12:58 -0600, Jon Derrick wrote:
> Versions of VMD with the Host Physical Address shadow register use this
> register to calculate the bus address offset needed to do guest
> passthrough of the domain. This register shadows the Host Physical
> Address registers directly, including the resource type bits. After
> calculating the offset, the extra bits lead to the VMD resources being
> over-provisioned at the front and under-provisioned at the back.
> 
> Example:
> pci 10000:80:02.0: reg 0x10: [mem 0xf801fffc-0xf803fffb 64bit]
> 
> Expected:
> pci 10000:80:02.0: reg 0x10: [mem 0xf8020000-0xf803ffff 64bit]
> 
> If other devices are mapped in the over-provisioned front, it could lead
> to resource conflict issues with VMD or those devices.
> 
> Fixes: a1a30170138c9 ("PCI: vmd: Fix shadow offsets to reflect spec changes")
> Cc: stable@vger.kernel.org # v4.19+
> Signed-off-by: Jon Derrick <jonathan.derrick@intel.com>
> ---
>  drivers/pci/controller/vmd.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c
> index dac91d6..e386d4e 100644
> --- a/drivers/pci/controller/vmd.c
> +++ b/drivers/pci/controller/vmd.c
> @@ -445,9 +445,11 @@ static int vmd_enable_domain(struct vmd_dev *vmd, unsigned long features)
>  			if (!membar2)
>  				return -ENOMEM;
>  			offset[0] = vmd->dev->resource[VMD_MEMBAR1].start -
> -					readq(membar2 + MB2_SHADOW_OFFSET);
> +					(readq(membar2 + MB2_SHADOW_OFFSET) &
> +					 PCI_BASE_ADDRESS_MEM_MASK);
>  			offset[1] = vmd->dev->resource[VMD_MEMBAR2].start -
> -					readq(membar2 + MB2_SHADOW_OFFSET + 8);
> +					(readq(membar2 + MB2_SHADOW_OFFSET + 8) &
> +					 PCI_BASE_ADDRESS_MEM_MASK);
>  			pci_iounmap(vmd->dev, membar2);
>  		}
>  	}

Re: [PATCH] PCI: vmd: Filter resource type bits from shadow register

[Derrick, Jonathan]

Sorry I just noticed this never hit the ML.
I'm guessing it was rejected at the mailserver due to the bad stable address.

I'll resubmit for 5.8 in a while.

On Wed, 2020-04-08 at 11:36 -0600, Jonathan Derrick wrote:
> Anything wrong with this, Lorenzo?
> 
> Thanks
> 
> On Fri, 2020-03-20 at 12:58 -0600, Jon Derrick wrote:
> > Versions of VMD with the Host Physical Address shadow register use this
> > register to calculate the bus address offset needed to do guest
> > passthrough of the domain. This register shadows the Host Physical
> > Address registers directly, including the resource type bits. After
> > calculating the offset, the extra bits lead to the VMD resources being
> > over-provisioned at the front and under-provisioned at the back.
> > 
> > Example:
> > pci 10000:80:02.0: reg 0x10: [mem 0xf801fffc-0xf803fffb 64bit]
> > 
> > Expected:
> > pci 10000:80:02.0: reg 0x10: [mem 0xf8020000-0xf803ffff 64bit]
> > 
> > If other devices are mapped in the over-provisioned front, it could lead
> > to resource conflict issues with VMD or those devices.
> > 
> > Fixes: a1a30170138c9 ("PCI: vmd: Fix shadow offsets to reflect spec changes")
> > Cc: stable@vger.kernel.org # v4.19+
> > Signed-off-by: Jon Derrick <jonathan.derrick@intel.com>
> > ---
> >  drivers/pci/controller/vmd.c | 6 ++++--
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c
> > index dac91d6..e386d4e 100644
> > --- a/drivers/pci/controller/vmd.c
> > +++ b/drivers/pci/controller/vmd.c
> > @@ -445,9 +445,11 @@ static int vmd_enable_domain(struct vmd_dev *vmd, unsigned long features)
> >  			if (!membar2)
> >  				return -ENOMEM;
> >  			offset[0] = vmd->dev->resource[VMD_MEMBAR1].start -
> > -					readq(membar2 + MB2_SHADOW_OFFSET);
> > +					(readq(membar2 + MB2_SHADOW_OFFSET) &
> > +					 PCI_BASE_ADDRESS_MEM_MASK);
> >  			offset[1] = vmd->dev->resource[VMD_MEMBAR2].start -
> > -					readq(membar2 + MB2_SHADOW_OFFSET + 8);
> > +					(readq(membar2 + MB2_SHADOW_OFFSET + 8) &
> > +					 PCI_BASE_ADDRESS_MEM_MASK);
> >  			pci_iounmap(vmd->dev, membar2);
> >  		}
> >  	}