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@xxxxxxxxxxxxxxx # v4.19+
> Signed-off-by: Jon Derrick <jonathan.derrick@xxxxxxxxx>
> ---
> 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);
> }
> }
