Skip to contentSkip to conversation

VMD: Document code for maintainability

PATCH Applied Keith Busch 2 participants 3 messages Mar 2, 2016 – Mar 10, 2016

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH 1/2 VMD: Document code for maintainability

This comments the less obvious portion of the code for setting up memory windows, and the platform dependency for initializing the h/w with appropriate resources.

---
 arch/x86/pci/vmd.c | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)
arch/x86/pci/vmd.c +17 -0
index d57e480..68faa5e 100644
@@ -532,6 +532,23 @@ static int vmd_enable_domain(struct vmd_dev *vmd)
 		.flags = IORESOURCE_BUS | IORESOURCE_PCI_FIXED,
 	};
 
+	/*
+	 * If the window is below 4GB, clear IORESOURCE_MEM_64 so we can
+	 * put 32-bit resources in the window.
+	 *
+	 * There's no hardware reason why a 64-bit window *couldn't*
+	 * contain a 32-bit resource, but pbus_size_mem() computes the
+	 * bridge window size assuming a 64-bit window will contain no
+	 * 32-bit resources.  __pci_assign_resource() enforces that
+	 * artificial restriction to make sure everything will fit.
+	 *
+	 * The only way we could use a 64-bit non-prefechable MEMBAR is
+	 * if its address is <4GB so that we can convert it to a 32-bit
+	 * resource. To be visible to the host OS, all VMD endpoints must
+	 * be initially configured by platform BIOS, which includes setting
+	 * up these resources. We can assume the device is configured
+	 * according to the platform needs.
+	 */
 	res = &vmd->dev->resource[VMD_MEMBAR1];
 	upper_bits = upper_32_bits(res->end);
 	flags = res->flags & ~IORESOURCE_SIZEALIGN;
Signature · 1 line
2.7.2
#1 lore raw

PATCH 2/2 VMD: Set bus resource start to 0

The bus always starts at 0. Due to alignment and down-casting, this happened to work before, but looked alarmingly incorrect in kernel logs.

---
 arch/x86/pci/vmd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/pci/vmd.c +1 -1
index 68faa5e..f60ecaa 100644
@@ -527,7 +527,7 @@ static int vmd_enable_domain(struct vmd_dev *vmd)
 	res = &vmd->dev->resource[VMD_CFGBAR];
 	vmd->resources[0] = (struct resource) {
 		.name  = "VMD CFGBAR",
-		.start = res->start,
+		.start = 0,
 		.end   = (resource_size(res) >> 20) - 1,
 		.flags = IORESOURCE_BUS | IORESOURCE_PCI_FIXED,
 	};
Signature · 1 line
2.7.2
#2 lore raw
In reply to Keith Busch
Quoted 5 lines · Keith Busch

This comments the less obvious portion of the code for setting up memory windows, and the platform dependency for initializing the h/w with appropriate resources.

I applied both patches to pci/host-vmd for v4.6, thanks, Keith!

Quoted 39 lines
---
 arch/x86/pci/vmd.c | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)
arch/x86/pci/vmd.c +17 -0
index d57e480..68faa5e 100644
@@ -532,6 +532,23 @@ static int vmd_enable_domain(struct vmd_dev *vmd)
 		.flags = IORESOURCE_BUS | IORESOURCE_PCI_FIXED,
 	};
 
+	/*
+	 * If the window is below 4GB, clear IORESOURCE_MEM_64 so we can
+	 * put 32-bit resources in the window.
+	 *
+	 * There's no hardware reason why a 64-bit window *couldn't*
+	 * contain a 32-bit resource, but pbus_size_mem() computes the
+	 * bridge window size assuming a 64-bit window will contain no
+	 * 32-bit resources.  __pci_assign_resource() enforces that
+	 * artificial restriction to make sure everything will fit.
+	 *
+	 * The only way we could use a 64-bit non-prefechable MEMBAR is
+	 * if its address is <4GB so that we can convert it to a 32-bit
+	 * resource. To be visible to the host OS, all VMD endpoints must
+	 * be initially configured by platform BIOS, which includes setting
+	 * up these resources. We can assume the device is configured
+	 * according to the platform needs.
+	 */
 	res = &vmd->dev->resource[VMD_MEMBAR1];
 	upper_bits = upper_32_bits(res->end);
 	flags = res->flags & ~IORESOURCE_SIZEALIGN;
Signature · 6 lines
2.7.2

--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html