Skip to contentSkip to conversation

Front-end driver for PCIe Pass-through on Hyper-V

PATCH Superseded [email protected] 3 participants 13 messages Jun 11, 2015 – Jun 12, 2015

Subsystems (4)

v1 of 3 Superseded Latest is v3 →

lore
Share & tools
lore
#0 lore raw

cover Front-end driver for PCIe Pass-through on Hyper-V

From: Jake Oshins <[email protected]>

This patch does some slight refactoring on the hv_vmbus driver and its dependents and then introduces a new paravirtual front-end driver for PCI which supports PCI Express devices passed through to a Linux guest running in a Hyper-V VM.

To support this front-end, several new mechanisms are introduced:

1 - A common way of finding free memory-mapped I/O space in a Hyper-V VM,
available to all Hyper-V-related drivers.

2 - A way of handling PCI Message-Signaled Interrupt (MSI and MSI-X)
creation and formatting when Hyper-V is running.

3 - A mapping function from Linux processor number to Hyper-V virtual
processor number, available to drivers, which is necessary for MSI(-X) creation.

The Hyper-V Frame Buffer driver is modified to use the MMIO space allocation function so that its allocations both don't collide with the PCI front end and so that the chosen range can come from any available part of MMIO space.

Finally, the new PCI front-end driver is the last patch in the series.

Jake Oshins (6):
drivers:hv: Modify vmbus to search for all MMIO ranges available drivers:hv: Move MMIO range picking from hyper_fb.mod to hv_vmbus.mod arch:x86:hv: Add mechanism for Hyper-V paravirt drivers to hook msi
message creation
drivers:hv: Export a function that maps Linux proc num onto Hyper-V
proc num
drivers:hv: Define the channel type for Hyper-V PCI Express
pass-through
drivers:pci:hv: New paravirtual PCI front-end for Hyper-V VMs

 MAINTAINERS                     |    1 +
 arch/x86/include/asm/mshyperv.h |    2 +
 arch/x86/kernel/cpu/mshyperv.c  |   30 +
 drivers/hv/vmbus_drv.c          |  208 +++-
 drivers/pci/Kconfig             |    9 +
 drivers/pci/host/Makefile       |    1 +
 drivers/pci/host/hv_pcifront.c  | 2177 +++++++++++++++++++++++++++++++++++++++
 drivers/video/fbdev/hyperv_fb.c |   46 +-
 include/linux/hyperv.h          |   38 +-
 9 files changed, 2469 insertions(+), 43 deletions(-)
 create mode 100644 drivers/pci/host/hv_pcifront.c
Signature · 1 line
1.9.1
#1 lore raw

PATCH 1/6 drivers:hv: Modify vmbus to search for all MMIO ranges available

From: Jake Oshins <[email protected]>

---
 drivers/hv/vmbus_drv.c          | 105 ++++++++++++++++++++++++++++++++++------
 drivers/video/fbdev/hyperv_fb.c |   2 +-
 include/linux/hyperv.h          |   2 +-
 3 files changed, 92 insertions(+), 17 deletions(-)
drivers/hv/vmbus_drv.c +90 -15
index c85235e..d0e8832 100644
@@ -72,10 +72,7 @@ static struct notifier_block hyperv_panic_block = {
 	.notifier_call = hyperv_panic_event,
 };
 
-struct resource hyperv_mmio = {
-	.name  = "hyperv mmio",
-	.flags = IORESOURCE_MEM,
-};
+struct resource *hyperv_mmio;
 EXPORT_SYMBOL_GPL(hyperv_mmio);
 
 static int vmbus_exists(void)
@@ -982,30 +979,105 @@ void vmbus_device_unregister(struct hv_device *device_obj)
 
 
 /*
- * VMBUS is an acpi enumerated device. Get the the information we
+ * VMBUS is an acpi enumerated device. Get the information we
  * need from DSDT.
  */
-
+#define VTPM_BASE_ADDRESS 0xfed40000
 static acpi_status vmbus_walk_resources(struct acpi_resource *res, void *ctx)
 {
+	resource_size_t start = 0;
+	resource_size_t end = 0;
+	struct resource *new_res;
+	struct resource **old_res = &hyperv_mmio;
+	struct resource **prev_res = NULL;
+
 	switch (res->type) {
 	case ACPI_RESOURCE_TYPE_IRQ:
 		irq = res->data.irq.interrupts[0];
+		return AE_OK;
+
+	/*
+	 * "Address" descriptors are for bus windows. Ignore
+	 * "memory" descriptors, which are for registers on
+	 * devices.
+	 */
+	case ACPI_RESOURCE_TYPE_ADDRESS32:
+		start = res->data.address32.address.minimum;
+		end = res->data.address32.address.maximum;
 		break;
 
 	case ACPI_RESOURCE_TYPE_ADDRESS64:
-		hyperv_mmio.start = res->data.address64.address.minimum;
-		hyperv_mmio.end = res->data.address64.address.maximum;
+		start = res->data.address64.address.minimum;
+		end = res->data.address64.address.maximum;
 		break;
+
+	default:
+		/* Unused resource type */
+		return AE_OK;
+
 	}
+	/*
+	 * Ignore ranges that are below 1MB, as they're not
+	 * necessary or useful here.
+	 */
+	if (end < 0x100000)
+		return AE_OK;
+
+	new_res = kzalloc(sizeof(*new_res), GFP_ATOMIC);
+	if (!new_res)
+		return AE_NO_MEMORY;
+
+	/* If this range overlaps the virtual TPM, truncate it. */
+	if (end > VTPM_BASE_ADDRESS && start < VTPM_BASE_ADDRESS)
+		end = VTPM_BASE_ADDRESS;
+
+	new_res->name = "hyperv mmio";
+	new_res->flags = IORESOURCE_MEM;
+	new_res->start = start;
+	new_res->end = end;
+
+	do {
+		if (!*old_res) {
+			*old_res = new_res;
+			break;
+		}
+
+		if ((*old_res)->end < new_res->start) {
+			new_res->sibling = *old_res;
+			if (prev_res)
+				(*prev_res)->sibling = new_res;
+			*old_res = new_res;
+			break;
+		}
+
+		prev_res = old_res;
+		old_res = &(*old_res)->sibling;
+
+	} while (1);
 
 	return AE_OK;
 }
 
+static int vmbus_acpi_remove(struct acpi_device *device)
+{
+	struct resource *cur_res;
+	struct resource *next_res;
+
+	if (hyperv_mmio) {
+		for (cur_res = hyperv_mmio; cur_res; cur_res = next_res) {
+			next_res = cur_res->sibling;
+			kfree(cur_res);
+		}
+	}
+
+	return 0;
+}
+
 static int vmbus_acpi_add(struct acpi_device *device)
 {
 	acpi_status result;
 	int ret_val = -ENODEV;
+	struct acpi_device *ancestor;
 
 	hv_acpi_dev = device;
 
@@ -1015,23 +1087,25 @@ static int vmbus_acpi_add(struct acpi_device *device)
 	if (ACPI_FAILURE(result))
 		goto acpi_walk_err;
 	/*
-	 * The parent of the vmbus acpi device (Gen2 firmware) is the VMOD that
-	 * has the mmio ranges. Get that.
+	 * Some ancestor of the vmbus acpi device (Gen1 or Gen2
+	 * firmware) is the VMOD that has the mmio ranges. Get that.
 	 */
-	if (device->parent) {
-		result = acpi_walk_resources(device->parent->handle,
+	for (ancestor = device->parent; ancestor; ancestor = ancestor->parent) {
+		result = acpi_walk_resources(ancestor->handle,
 					METHOD_NAME__CRS,
 					vmbus_walk_resources, NULL);
 
 		if (ACPI_FAILURE(result))
-			goto acpi_walk_err;
-		if (hyperv_mmio.start && hyperv_mmio.end)
-			request_resource(&iomem_resource, &hyperv_mmio);
+			continue;
+		if (hyperv_mmio)
+			break;
 	}
 	ret_val = 0;
 
 acpi_walk_err:
 	complete(&probe_event);
+	if (ret_val)
+		vmbus_acpi_remove(device);
 	return ret_val;
 }
 
@@ -1047,6 +1121,7 @@ static struct acpi_driver vmbus_acpi_driver = {
 	.ids = vmbus_acpi_device_ids,
 	.ops = {
 		.add = vmbus_acpi_add,
+		.remove = vmbus_acpi_remove,
 	},
 };
 
drivers/video/fbdev/hyperv_fb.c +1 -1
index 807ee22..b54ee1c 100644
@@ -688,7 +688,7 @@ static int hvfb_getmem(struct fb_info *info)
 	par->mem.name = KBUILD_MODNAME;
 	par->mem.flags = IORESOURCE_MEM | IORESOURCE_BUSY;
 	if (gen2vm) {
-		ret = allocate_resource(&hyperv_mmio, &par->mem,
+		ret = allocate_resource(hyperv_mmio, &par->mem,
 					screen_fb_size,
 					0, -1,
 					screen_fb_size,
include/linux/hyperv.h +1 -1
index 902c37a..21fa867 100644
@@ -1245,7 +1245,7 @@ void hv_vss_deinit(void);
 void hv_vss_onchannelcallback(void *);
 void hv_process_channel_removal(struct vmbus_channel *channel, u32 relid);
 
-extern struct resource hyperv_mmio;
+extern struct resource *hyperv_mmio;
 
 /*
  * Negotiated version with the Host.
Signature · 1 line
1.9.1
#2 lore raw

PATCH 2/6 drivers:hv: Move MMIO range picking from hyper_fb.mod to hv_vmbus.mod

In reply to [email protected]

From: Jake Oshins <[email protected]>

---
 drivers/hv/vmbus_drv.c          | 87 ++++++++++++++++++++++++++++++++++++++++-
 drivers/video/fbdev/hyperv_fb.c | 46 ++++++++++------------
 include/linux/hyperv.h          |  7 +++-
 3 files changed, 112 insertions(+), 28 deletions(-)
drivers/hv/vmbus_drv.c +86 -1
index d0e8832..067a469 100644
@@ -39,6 +39,7 @@
 #include <asm/mshyperv.h>
 #include <linux/notifier.h>
 #include <linux/ptrace.h>
+#include <linux/screen_info.h>
 #include "hyperv_vmbus.h"
 
 static struct acpi_device  *hv_acpi_dev;
@@ -73,7 +74,6 @@ static struct notifier_block hyperv_panic_block = {
 };
 
 struct resource *hyperv_mmio;
-EXPORT_SYMBOL_GPL(hyperv_mmio);
 
 static int vmbus_exists(void)
 {
@@ -1073,6 +1073,91 @@ static int vmbus_acpi_remove(struct acpi_device *device)
 	return 0;
 }
 
+/**
+ * This function walks the resources granted to VMBus by the
+ * _CRS object in the ACPI namespace underneath the parent
+ * "bridge" whether that's a root PCI bus in the Generation 1
+ * case or a Module Device in the Generation 2 case.  It then
+ * attempts to allocate from the global MMIO pool in a way that
+ * matches the constraints supplied in these parameters and by
+ * that _CRS.
+ *
+ * @param new - If successful, supplied a pointer to the
+ *            allocated MMIO space.
+ * @param device_obj - Identifies the caller
+ * @param min - Minimum guest physical address of the allocation
+ * @param max - Maximum guest physical address
+ * @param size - Size of the range to be allocated
+ * @param align - Alignment of the range to be allocated
+ * @param fb_overlap_ok - Whether this allocation can be allowed
+ *			to overlap the video frame buffer.
+ *
+ * @return int
+ */
+int vmbus_allocate_mmio(struct resource **new, struct hv_device *device_obj,
+			resource_size_t min, resource_size_t max,
+			resource_size_t size, resource_size_t align,
+			bool fb_overlap_ok)
+{
+	struct resource *iter;
+	resource_size_t range_min, range_max, start, local_min, local_max;
+	const char *dev_n = dev_name(&device_obj->device);
+	u32 fb_end = screen_info.lfb_base + (screen_info.lfb_size << 1);
+	int i;
+
+	pr_devel("allocating %llxx bytes alignment %llx in %llx->%llx for %s\n",
+		 size, align, min, max, dev_n);
+
+	for (iter = hyperv_mmio; iter; iter = iter->sibling) {
+
+		if ((iter->start >= max) || (iter->end <= min))
+			continue;
+
+		range_min = iter->start;
+		range_max = iter->end;
+
+		/* If this range overlaps the frame buffer, split it into
+		   two tries. */
+		for (i = 0; i < 2; i++) {
+			local_min = range_min;
+			local_max = range_max;
+			if (fb_overlap_ok || ((range_min >= fb_end) ||
+			      (range_max <= screen_info.lfb_base))) {
+				i++;
+			} else {
+				if ((range_min <= screen_info.lfb_base) &&
+				    (range_max >= screen_info.lfb_base)) {
+
+					/*
+					 * The frame buffer is in this window,
+					 * so trim this into the part that
+					 * preceeds the frame buffer.
+					 */
+					local_max = screen_info.lfb_base-1;
+					range_min = fb_end;
+				} else {
+					range_min = fb_end;
+					continue;
+				}
+			}
+
+			pr_devel("looking between %llx:%llx\n", range_min,
+				 range_max);
+			start = (local_min + align - 1) & ~(align - 1);
+			for (; start + size - 1 <= local_max; start += align) {
+				*new = request_mem_region_exclusive(start, size,
+								    dev_n);
+				if (*new)
+					return 0;
+			}
+		}
+	}
+
+	pr_warn("vmbus_allocate_mmio failed\n");
+	return -ENXIO;
+}
+EXPORT_SYMBOL_GPL(vmbus_allocate_mmio);
+
 static int vmbus_acpi_add(struct acpi_device *device)
 {
 	acpi_status result;
drivers/video/fbdev/hyperv_fb.c +21 -25

98 lines not on this page · raw message

include/linux/hyperv.h +5 -2
index 21fa867..ffd98d7 100644
@@ -982,6 +982,11 @@ int __must_check __vmbus_driver_register(struct hv_driver *hv_driver,
 					 const char *mod_name);
 void vmbus_driver_unregister(struct hv_driver *hv_driver);
 
+int vmbus_allocate_mmio(struct resource **new, struct hv_device *device_obj,
+			resource_size_t min, resource_size_t max,
+			resource_size_t size, resource_size_t align,
+			bool fb_overlap_ok);
+
 /**
  * VMBUS_DEVICE - macro used to describe a specific hyperv vmbus device
  *
@@ -1245,8 +1250,6 @@ void hv_vss_deinit(void);
 void hv_vss_onchannelcallback(void *);
 void hv_process_channel_removal(struct vmbus_channel *channel, u32 relid);
 
-extern struct resource *hyperv_mmio;
-
 /*
  * Negotiated version with the Host.
  */
Signature · 1 line
1.9.1
#4 lore raw

PATCH 3/6 arch:x86:hv: Add mechanism for Hyper-V paravirt drivers to hook msi message creation

In reply to [email protected]

From: Jake Oshins <[email protected]>

---
 arch/x86/include/asm/mshyperv.h |  2 ++
 arch/x86/kernel/cpu/mshyperv.c  | 30 ++++++++++++++++++++++++++++++
 2 files changed, 32 insertions(+)
arch/x86/include/asm/mshyperv.h +2 -0
index c163215..bf7789e 100644
@@ -19,5 +19,7 @@ void hyperv_callback_vector(void);
 void hyperv_vector_handler(struct pt_regs *regs);
 void hv_setup_vmbus_irq(void (*handler)(void));
 void hv_remove_vmbus_irq(void);
+void hyperv_install_interrupt_translation(struct x86_msi_ops *new_ops);
+void hyperv_uninstall_interrupt_translation(void);
 
 #endif
arch/x86/kernel/cpu/mshyperv.c +30 -0
index 939155f..816e329 100644
@@ -69,6 +69,36 @@ void hv_remove_vmbus_irq(void)
 }
 EXPORT_SYMBOL_GPL(hv_setup_vmbus_irq);
 EXPORT_SYMBOL_GPL(hv_remove_vmbus_irq);
+
+struct x86_msi_ops old_msi_ops;
+
+void hyperv_install_interrupt_translation(struct x86_msi_ops *new_ops)
+{
+	old_msi_ops.setup_msi_irqs = xchg(&(x86_msi.setup_msi_irqs),
+					  new_ops->setup_msi_irqs);
+	old_msi_ops.compose_msi_msg = xchg(&(x86_msi.compose_msi_msg),
+					   new_ops->compose_msi_msg);
+	old_msi_ops.teardown_msi_irqs = xchg(&(x86_msi.teardown_msi_irqs),
+					     new_ops->teardown_msi_irqs);
+	old_msi_ops.restore_msi_irqs = xchg(&(x86_msi.restore_msi_irqs),
+					    new_ops->restore_msi_irqs);
+
+	new_ops->setup_msi_irqs = old_msi_ops.setup_msi_irqs;
+	new_ops->compose_msi_msg = old_msi_ops.compose_msi_msg;
+	new_ops->teardown_msi_irqs = old_msi_ops.teardown_msi_irqs;
+	new_ops->restore_msi_irqs = old_msi_ops.restore_msi_irqs;
+}
+EXPORT_SYMBOL_GPL(hyperv_install_interrupt_translation);
+
+void hyperv_uninstall_interrupt_translation(void)
+{
+	xchg(&(x86_msi.setup_msi_irqs), old_msi_ops.setup_msi_irqs);
+	xchg(&(x86_msi.compose_msi_msg), old_msi_ops.compose_msi_msg);
+	xchg(&(x86_msi.teardown_msi_irqs), old_msi_ops.teardown_msi_irqs);
+	xchg(&(x86_msi.restore_msi_irqs), old_msi_ops.restore_msi_irqs);
+}
+EXPORT_SYMBOL_GPL(hyperv_uninstall_interrupt_translation);
+
 #endif
 
 static uint32_t  __init ms_hyperv_platform(void)
Signature · 1 line
1.9.1
#5 lore raw

PATCH 4/6 drivers:hv: Export a function that maps Linux proc num onto Hyper-V proc num

In reply to [email protected]

From: Jake Oshins <[email protected]>

---
 drivers/hv/vmbus_drv.c | 16 ++++++++++++++++
 include/linux/hyperv.h |  2 ++
 2 files changed, 18 insertions(+)
drivers/hv/vmbus_drv.c +16 -0
index 067a469..65e4eb6 100644
@@ -1158,6 +1158,22 @@ int vmbus_allocate_mmio(struct resource **new, struct hv_device *device_obj,
 }
 EXPORT_SYMBOL_GPL(vmbus_allocate_mmio);
 
+/**
+ * This function returns the mapping between the Linux processor
+ * number and
+ * the hypervisor's virtual processor number, useful in making
+ * hypercalls and such that talk about specific processors.
+ *
+ * @param procnum - in Linux terms
+ *
+ * @return int - in Hyper-V terms
+ */
+int vmbus_procnum_to_vpnum(int procnum)
+{
+	return hv_context.vp_index[procnum];
+}
+EXPORT_SYMBOL_GPL(vmbus_procnum_to_vpnum);
+
 static int vmbus_acpi_add(struct acpi_device *device)
 {
 	acpi_status result;
include/linux/hyperv.h +2 -0
index ffd98d7..6fec42d 100644
@@ -987,6 +987,8 @@ int vmbus_allocate_mmio(struct resource **new, struct hv_device *device_obj,
 			resource_size_t size, resource_size_t align,
 			bool fb_overlap_ok);
 
+int vmbus_procnum_to_vpnum(int procnum);
+
 /**
  * VMBUS_DEVICE - macro used to describe a specific hyperv vmbus device
  *
Signature · 1 line
1.9.1
#6 lore raw

PATCH 5/6 drivers:hv: Define the channel type for Hyper-V PCI Express pass-through

In reply to [email protected]

From: Jake Oshins <[email protected]>

---
 include/linux/hyperv.h | 11 +++++++++++
 1 file changed, 11 insertions(+)
include/linux/hyperv.h +11 -0
index 6fec42d..1903238 100644
@@ -1144,6 +1144,17 @@ int vmbus_procnum_to_vpnum(int procnum);
 		}
 
 /*
+ * PCI Express Pass Through
+ * {44C4F61D-4444-4400-9D52-802E27EDE19F}
+ */
+
+#define HV_PCIE_GUID \
+	.guid = { \
+			0x1D, 0xF6, 0xC4, 0x44, 0x44, 0x44, 0x00, 0x44, \
+			0x9D, 0x52, 0x80, 0x2E, 0x27, 0xED, 0xE1, 0x9F \
+		}
+
+/*
  * Common header for Hyper-V ICs
  */
 
Signature · 1 line
1.9.1
#7 lore raw

PATCH 6/6 drivers:pci:hv: New paravirtual PCI front-end for Hyper-V VMs

In reply to [email protected]

From: Jake Oshins <[email protected]>

drivers:pci:hv: Update MAINTAINERS

drivers:pci:hv: New paravirtual PCI front-end for Hyper-V VMs

---
 MAINTAINERS                    |    1 +
 drivers/pci/Kconfig            |    9 +
 drivers/pci/host/Makefile      |    1 +
 drivers/pci/host/hv_pcifront.c | 2177 ++++++++++++++++++++++++++++++++++++++++
 include/linux/hyperv.h         |   18 +
 5 files changed, 2206 insertions(+)
 create mode 100644 drivers/pci/host/hv_pcifront.c
MAINTAINERS +1 -0
index d8afd29..ed8d991 100644
@@ -4759,6 +4759,7 @@ F:	arch/x86/kernel/cpu/mshyperv.c
 F:	drivers/hid/hid-hyperv.c
 F:	drivers/hv/
 F:	drivers/input/serio/hyperv-keyboard.c
+F:	drivers/pci/host/hv_pcifront.c
 F:	drivers/net/hyperv/
 F:	drivers/scsi/storvsc_drv.c
 F:	drivers/video/fbdev/hyperv_fb.c
drivers/pci/Kconfig +9 -0
index 7a8f1c5..e008f68 100644
@@ -114,4 +114,13 @@ config PCI_LABEL
 	def_bool y if (DMI || ACPI)
 	select NLS
 
+config HYPERV_VPCI
+        tristate "Hyper-V PCI Frontend"
+        depends on PCI && X86 && HYPERV
+        select PCI_HV
+        default y
+        help
+          The PCI device frontend driver allows the kernel to import arbitrary
+          PCI devices from a PCI backend to support PCI driver domains.
+
 source "drivers/pci/host/Kconfig"
drivers/pci/host/Makefile +1 -0
index f733b4e..7bf8442 100644
@@ -2,6 +2,7 @@ obj-$(CONFIG_PCIE_DW) += pcie-designware.o
 obj-$(CONFIG_PCI_DRA7XX) += pci-dra7xx.o
 obj-$(CONFIG_PCI_EXYNOS) += pci-exynos.o
 obj-$(CONFIG_PCI_IMX6) += pci-imx6.o
+obj-$(CONFIG_HYPERV_VPCI) += hv_pcifront.o
 obj-$(CONFIG_PCI_MVEBU) += pci-mvebu.o
 obj-$(CONFIG_PCI_TEGRA) += pci-tegra.o
 obj-$(CONFIG_PCI_RCAR_GEN2) += pci-rcar-gen2.o
drivers/pci/host/hv_pcifront.c new file +2177 -0

2,177 lines not on this page · raw message

include/linux/hyperv.h +18 -0
index 1903238..0acf9ff 100644
@@ -1269,4 +1269,22 @@ void hv_process_channel_removal(struct vmbus_channel *channel, u32 relid);
 
 extern __u32 vmbus_proto_version;
 
+/*
+ * Functions for passing data between SR-IOV PF and VF drivers.  The VF driver
+ * sends requests to read and write blocks.  Each block must be 128 bytes or
+ * smaller so that the host can guarantee a successful response.  (All
+ * intermediate buffers are preallocated.)  Optionally, the VF driver can
+ * register a callback function which will be invoked when the host says that
+ * one or more of the first 64 block IDs is "invalid" which means that the
+ * VF driver should reread them.
+ */
+#define CONFIG_BLOCK_SIZE_MAX 128
+int hv_read_config_block(struct pci_dev *dev, void *buf, int buf_len,
+			 int block_id, int *bytes_returned);
+int hv_write_config_block(struct pci_dev *dev, void *buf, int len,
+			  int block_id);
+int hv_register_block_invalidate(struct pci_dev *dev, void *context,
+				 void (*block_invalidate)(void *context,
+							  u64 block_mask));
+
 #endif /* _HYPERV_H */
Signature · 1 line
1.9.1
#8 lore raw

Re: [PATCH 6/6] drivers:pci:hv: New paravirtual PCI front-end for Hyper-V VMs

Quoted 3 lines · On Thu, Jun 11, 2015 at 04:22:27PM +0000, [email protected] wrote:

From: Jake Oshins <[email protected]>

drivers:pci:hv: Update MAINTAINERS

Huh?

Quoted 2 lines

drivers:pci:hv: New paravirtual PCI front-end for Hyper-V VMs

What is this odd format?

Quoted 1 line

No blank line?

Come on, you all know better than this...

greg k-h

#9 lore raw

Re: [PATCH 6/6] drivers:pci:hv: New paravirtual PCI front-end for Hyper-V VMs

In reply to [email protected]

Greg has already asked you to resend. So here follow a few remarks to take into account for that resend.

drivers/pci/Kconfig config PCI_LABEL · line 120

Quoted 7 lines · On Thu, 2015-06-11 at 16:22 +0000, [email protected] wrote:
drivers/pci/Kconfig +4 -0
 
+config HYPERV_VPCI
+        tristate "Hyper-V PCI Frontend"
+        depends on PCI && X86 && HYPERV
+        select PCI_HV

That symbol doesn't exist and is not added in this series, right? If so, scripts/checkkconsymbols.py could have told you that.

Quoted 1 line

+ default y

Are you sure?

Quoted 6 lines
drivers/pci/Kconfig +3 -0
+        help
+          The PCI device frontend driver allows the kernel to import arbitrary
+          PCI devices from a PCI backend to support PCI driver domains.

drivers/pci/host/hv_pcifront.c line 14

Quoted 9 lines
drivers/pci/host/hv_pcifront.c new file +8 -0
 
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or
+ * NON INFRINGEMENT.  See the GNU General Public License for more

This states the license is GPL v2.

drivers/pci/host/hv_pcifront.c line 792

Quoted 5 lines
drivers/pci/host/hv_pcifront.c new file +3 -0
+EXPORT_SYMBOL(hv_read_config_block);
 
+EXPORT_SYMBOL(hv_write_config_block);
 
+EXPORT_SYMBOL(hv_register_block_invalidate);

I couldn't spot any users of these exports. Actually, I couldn't even spot any users of these three functions. Why were they added?

Quoted 1 line

+MODULE_LICENSE("GPL");

This states, according to include/linux/module.h, that the license is GPL v2 or later. So I think either the comment at the top of this file or the ident used in the MODULE_LICENSE() macro needs to change.

Thanks,

Paul Bolle

#10 lore raw

RE: [PATCH 6/6] drivers:pci:hv: New paravirtual PCI front-end for Hyper-V VMs

PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBQYXVsIEJvbGxlIFttYWlsdG86 cGVib2xsZUB0aXNjYWxpLm5sXQ0KPiBTZW50OiBGcmlkYXksIEp1bmUgMTIsIDIwMTUgMTo0NCBB TQ0KPiBUbzogSmFrZSBPc2hpbnMNCj4gQ2M6IGdyZWdraEBsaW51eGZvdW5kYXRpb24ub3JnOyBL WSBTcmluaXZhc2FuOyBsaW51eC0NCj4ga2VybmVsQHZnZXIua2VybmVsLm9yZzsgZGV2ZWxAbGlu dXhkcml2ZXJwcm9qZWN0Lm9yZzsgb2xhZkBhZXBmbGUuZGU7DQo+IGFwd0BjYW5vbmljYWwuY29t OyB2a3V6bmV0c0ByZWRoYXQuY29tOyBsaW51eC1wY2lAdmdlci5rZXJuZWwub3JnOw0KPiBiaGVs Z2Fhc0Bnb29nbGUuY29tOyBNaWtlIEViZXJzb2w7IEhhaXlhbmcgWmhhbmcNCj4gU3ViamVjdDog UmU6IFtQQVRDSCA2LzZdIGRyaXZlcnM6cGNpOmh2OiBOZXcgcGFyYXZpcnR1YWwgUENJIGZyb250 LWVuZCBmb3INCj4gSHlwZXItViBWTXMNCj4gDQo+IEdyZWcgaGFzIGFscmVhZHkgYXNrZWQgeW91 IHRvIHJlc2VuZC4gU28gaGVyZSBmb2xsb3cgYSBmZXcgcmVtYXJrcyB0bw0KPiB0YWtlIGludG8g YWNjb3VudCBmb3IgdGhhdCByZXNlbmQuDQo+IA0KDQpUaGFuayB5b3UuICBJJ2xsIGZpeCBldmVy eXRoaW5nIHlvdSd2ZSBtZW50aW9uZWQgYmVmb3JlIHJlc2VuZGluZy4gIEkgZG8gaGF2ZSBvbmUg bW9yZSBxdWVzdGlvbiwgYmVsb3cuDQoNCj4gDQo+ID4gK0VYUE9SVF9TWU1CT0woaHZfcmVhZF9j b25maWdfYmxvY2spOw0KPiANCj4gPiArRVhQT1JUX1NZTUJPTChodl93cml0ZV9jb25maWdfYmxv Y2spOw0KPiANCj4gPiArRVhQT1JUX1NZTUJPTChodl9yZWdpc3Rlcl9ibG9ja19pbnZhbGlkYXRl KTsNCj4gDQo+IEkgY291bGRuJ3Qgc3BvdCBhbnkgdXNlcnMgb2YgdGhlc2UgZXhwb3J0cy4gQWN0 dWFsbHksIEkgY291bGRuJ3QgZXZlbg0KPiBzcG90IGFueSB1c2VycyBvZiB0aGVzZSB0aHJlZSBm dW5jdGlvbnMuIFdoeSB3ZXJlIHRoZXkgYWRkZWQ/DQo+IA0KDQpUaGlzIGRyaXZlciBpcyBpbnRl bmRlZCB0byBzdXBwb3J0IGJvdGggZnVsbCBQQ0kgRXhwcmVzcyBkZXZpY2UgcGFzcyB0aHJvdWdo IGFuZCBhbHNvIGJlIHRoZSBiYXNpcyBmb3IgU1ItSU9WIG5ldHdvcmtpbmcgb24gdG9wIG9mIEh5 cGVyLVYuICBUaGVzZSBmdW5jdGlvbnMgd291bGQgYWxsb3cgc29tZWJvZHkgdHJ5aW5nIHRvIG1h a2UgdGhlaXIgTklDIGRyaXZlciB3b3JrIG9uIHRvcCBvZiBIeXBlci1WIHRvIGV4Y2hhbmdlIG1l c3NhZ2VzIHdpdGggdGhlaXIgYmFjay1lbmQgV2luZG93cyBkcml2ZXIuDQoNCk15IHF1ZXN0aW9u IGlzIHRoaXMuICBIb3cgZG9lcyBzb21lYm9keSBkZWxpdmVyaW5nIGEgcGxhdGZvcm0gdXN1YWxs eSB3b3JrIHdpdGggdGhlIExpbnV4IGNvbW11bml0eSB0byBkZWxpdmVyIGVuYWJsZW1lbnQgY29k ZSBsaWtlIHRoaXM/ICBJJ20gdHJ5aW5nIHRvIHdvcmsgaW4gdGhlIG9wZW4sIGFuZCBnbyB1cHN0 cmVhbSBlYXJseSAob3IgYXQgbGVhc3QgSSB0aGluayB0aGF0IHVuZGVyc3RhbmQgd2hhdCB0aGVz ZSB0aGluZ3MgbWVhbi4pICBJZiB0aGUgY29tbXVuaXR5IGRvZXNuJ3Qgd2FudCBmdW5jdGlvbnMg dGhhdCBoYXZlIG5vIGNhbGxlcnMgKGFuZCBJIHVuZGVyc3RhbmQgdGhhdCwgdG9vKSB0aGVuIGhv dyBzaG91bGQgSSBwcm92aWRlIHRoZW0gdG8gdGhlIE5JQyB2ZW5kb3JzPw0KDQpUaGFua3MsDQpK YWtlIE9zaGlucw0KDQo=

#11 lore raw

Re: [PATCH 6/6] drivers:pci:hv: New paravirtual PCI front-end for Hyper-V VMs

Quoted 3 lines · Jake Oshins

This driver is intended to support both full PCI Express device pass through and also be the basis for SR-IOV networking on top of Hyper-V. These functions would allow somebody trying to make their NIC driver work on top of Hyper-V to exchange messages with their back-end Windows driver.

My question is this. How does somebody delivering a platform usually work with the Linux community to deliver enablement code like this? I'm trying to work in the open, and go upstream early (or at least I think that understand what these things mean.) If the community doesn't want functions that have no callers (and I understand that, too) then how should I provide them to the NIC vendors?

You add the functions in a patch series along with the NIC driver that uses it. We don't add functions with no callers, sorry.

hope this helps,

greg k-h

#12 lore raw
In reply to [email protected]
Quoted 19 lines · On Thu, Jun 11, 2015 at 04:22:21PM +0000, [email protected] wrote:

From: Jake Oshins <[email protected]>

This patch does some slight refactoring on the hv_vmbus driver and its dependents and then introduces a new paravirtual front-end driver for PCI which supports PCI Express devices passed through to a Linux guest running in a Hyper-V VM.

To support this front-end, several new mechanisms are introduced:

1 - A common way of finding free memory-mapped I/O space in a Hyper-V VM,
available to all Hyper-V-related drivers.

2 - A way of handling PCI Message-Signaled Interrupt (MSI and MSI-X)
creation and formatting when Hyper-V is running.

3 - A mapping function from Linux processor number to Hyper-V virtual
processor number, available to drivers, which is necessary for MSI(-X) creation.

Quoted 6 lines

The Hyper-V Frame Buffer driver is modified to use the MMIO space allocation function so that its allocations both don't collide with the PCI front end and so that the chosen range can come from any available part of MMIO space.

Finally, the new PCI front-end driver is the last patch in the series.

All of this information needs to be in the patches themselves, they all do not have any changelog information in them at all, making them not acceptable at all.

Please fix all of this up and resend.

thanks,

greg k-h