diff mbox series

[v3,1/2] PCI: vmd: Filter resource type bits from shadow register

Message ID 20200528030240.16024-3-jonathan.derrick@intel.com
State New
Headers show
Series VMD endpoint passthrough support | expand

Commit Message

Derrick, Jonathan May 28, 2020, 3:02 a.m. UTC
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 including the resource type bits. After calculating
the offset, the extra resource type 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")
Signed-off-by: Jon Derrick <jonathan.derrick@intel.com>
---
 drivers/pci/controller/vmd.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

Comments

Lorenzo Pieralisi May 29, 2020, 10:33 a.m. UTC | #1
On Wed, May 27, 2020 at 11:02:39PM -0400, 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 including the resource type bits. After calculating
> the offset, the extra resource type 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")
> Signed-off-by: Jon Derrick <jonathan.derrick@intel.com>
> ---
>  drivers/pci/controller/vmd.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)

Hi Jon,

it looks like I can take this patch for v5.8 whereas patch 2 depends
on the QEMU changes acceptance and should probably wait.

Please let me know your thoughts asap and I will try to at least
squeeze this patch in.

Lorenzo

> 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);
>  		}
>  	}
> -- 
> 1.8.3.1
>
Derrick, Jonathan May 29, 2020, 3:53 p.m. UTC | #2
On Fri, 2020-05-29 at 11:33 +0100, Lorenzo Pieralisi wrote:
> On Wed, May 27, 2020 at 11:02:39PM -0400, 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 including the resource type bits. After calculating
> > the offset, the extra resource type 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")
> > Signed-off-by: Jon Derrick <jonathan.derrick@intel.com>
> > ---
> >  drivers/pci/controller/vmd.c | 6 ++++--
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> Hi Jon,
> 
> it looks like I can take this patch for v5.8 whereas patch 2 depends
> on the QEMU changes acceptance and should probably wait.
> 
> Please let me know your thoughts asap and I will try to at least
> squeeze this patch in.
> 
> Lorenzo

Hi Lorenzo,

This is fine. Please take Patch 1.
Patch 2 is harmless without the QEMU changes, but may always need a
different approach.

Best,
jon


> 
> > 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);
> >  		}
> >  	}
> > -- 
> > 1.8.3.1
> >
Lorenzo Pieralisi May 29, 2020, 4:18 p.m. UTC | #3
On Fri, May 29, 2020 at 03:53:37PM +0000, Derrick, Jonathan wrote:
> On Fri, 2020-05-29 at 11:33 +0100, Lorenzo Pieralisi wrote:
> > On Wed, May 27, 2020 at 11:02:39PM -0400, 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 including the resource type bits. After calculating
> > > the offset, the extra resource type 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")
> > > Signed-off-by: Jon Derrick <jonathan.derrick@intel.com>
> > > ---
> > >  drivers/pci/controller/vmd.c | 6 ++++--
> > >  1 file changed, 4 insertions(+), 2 deletions(-)
> > 
> > Hi Jon,
> > 
> > it looks like I can take this patch for v5.8 whereas patch 2 depends
> > on the QEMU changes acceptance and should probably wait.
> > 
> > Please let me know your thoughts asap and I will try to at least
> > squeeze this patch in.
> > 
> > Lorenzo
> 
> Hi Lorenzo,
> 
> This is fine. Please take Patch 1.
> Patch 2 is harmless without the QEMU changes, but may always need a
> different approach.

Pulled patch 1 into pci/vmd, thanks.

Lorenzo
Derrick, Jonathan June 11, 2020, 9:16 p.m. UTC | #4
On Fri, 2020-05-29 at 17:18 +0100, Lorenzo Pieralisi wrote:
> On Fri, May 29, 2020 at 03:53:37PM +0000, Derrick, Jonathan wrote:
> > On Fri, 2020-05-29 at 11:33 +0100, Lorenzo Pieralisi wrote:
> > > On Wed, May 27, 2020 at 11:02:39PM -0400, 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 including the resource type bits. After calculating
> > > > the offset, the extra resource type 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")
> > > > Signed-off-by: Jon Derrick <jonathan.derrick@intel.com>
> > > > ---
> > > >  drivers/pci/controller/vmd.c | 6 ++++--
> > > >  1 file changed, 4 insertions(+), 2 deletions(-)
> > > 
> > > Hi Jon,
> > > 
> > > it looks like I can take this patch for v5.8 whereas patch 2 depends
> > > on the QEMU changes acceptance and should probably wait.
> > > 
> > > Please let me know your thoughts asap and I will try to at least
> > > squeeze this patch in.
> > > 
> > > Lorenzo
> > 
> > Hi Lorenzo,
> > 
> > This is fine. Please take Patch 1.
> > Patch 2 is harmless without the QEMU changes, but may always need a
> > different approach.
> 
> Pulled patch 1 into pci/vmd, thanks.
> 
> Lorenzo

Hi Lorenzo,

Alex has pr-ed the QEMU patch [1]
Is it too late to pull patch 2/2 for v5.8?

[1] 
https://github.com/awilliam/qemu-vfio/releases/tag/vfio-update-20200611.0
Lorenzo Pieralisi June 12, 2020, 1:54 p.m. UTC | #5
On Thu, Jun 11, 2020 at 09:16:48PM +0000, Derrick, Jonathan wrote:

[...]

> > > > Hi Jon,
> > > > 
> > > > it looks like I can take this patch for v5.8 whereas patch 2 depends
> > > > on the QEMU changes acceptance and should probably wait.
> > > > 
> > > > Please let me know your thoughts asap and I will try to at least
> > > > squeeze this patch in.
> > > > 
> > > > Lorenzo
> > > 
> > > Hi Lorenzo,
> > > 
> > > This is fine. Please take Patch 1.
> > > Patch 2 is harmless without the QEMU changes, but may always need a
> > > different approach.
> > 
> > Pulled patch 1 into pci/vmd, thanks.
> > 
> > Lorenzo
> 
> Hi Lorenzo,
> 
> Alex has pr-ed the QEMU patch [1]
> Is it too late to pull patch 2/2 for v5.8?

I think it is - I don't know if Bjorn planned a second PR for this
merge window, if not it is v5.9 material I am afraid.

Thanks,
Lorenzo

> [1] 
> https://github.com/awilliam/qemu-vfio/releases/tag/vfio-update-20200611.0
Derrick, Jonathan June 12, 2020, 3:11 p.m. UTC | #6
On Fri, 2020-06-12 at 14:54 +0100, Lorenzo Pieralisi wrote:
> On Thu, Jun 11, 2020 at 09:16:48PM +0000, Derrick, Jonathan wrote:
> 
> [...]
> 
> > > > > Hi Jon,
> > > > > 
> > > > > it looks like I can take this patch for v5.8 whereas patch 2 depends
> > > > > on the QEMU changes acceptance and should probably wait.
> > > > > 
> > > > > Please let me know your thoughts asap and I will try to at least
> > > > > squeeze this patch in.
> > > > > 
> > > > > Lorenzo
> > > > 
> > > > Hi Lorenzo,
> > > > 
> > > > This is fine. Please take Patch 1.
> > > > Patch 2 is harmless without the QEMU changes, but may always need a
> > > > different approach.
> > > 
> > > Pulled patch 1 into pci/vmd, thanks.
> > > 
> > > Lorenzo
> > 
> > Hi Lorenzo,
> > 
> > Alex has pr-ed the QEMU patch [1]
> > Is it too late to pull patch 2/2 for v5.8?
> 
> I think it is - I don't know if Bjorn planned a second PR for this
> merge window, if not it is v5.9 material I am afraid.
> 
> Thanks,
> Lorenzo
> 
> > [1] 
> > https://github.com/awilliam/qemu-vfio/releases/tag/vfio-update-20200611.0

No problem
Jon
diff mbox series

Patch

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);
 		}
 	}