Front-end driver for PCIe Pass-through on Hyper-V
Subsystems (4)
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
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
@@ -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 0xfed40000static 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
@@ -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
@@ -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
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
@@ -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
@@ -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
Re: [PATCH 2/6] drivers:hv: Move MMIO range picking from hyper_fb.mod to hv_vmbus.mod
Quoted 3 lines · On Thu, Jun 11, 2015 at 04:22:23PM +0000, [email protected] wrote:
From: Jake Oshins <[email protected]>
Signed-off-by Jake Oshins <[email protected]>
No changelog body text at all? That's a sure way to get a patch instantly deleted from my queue...
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
@@ -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
@@ -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
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
@@ -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
@@ -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
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
@@ -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
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
@@ -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
@@ -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
@@ -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
@@ -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
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
Signed-off-by Jake Oshins <[email protected]>
No blank line?
Come on, you all know better than this...
greg k-h
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
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=
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
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_vmbusdriver 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