hv: Front-end driver for PCIe Pass-through on Hyper-V
Subsystems (4)
v2 cover hv: 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.
This patch series incorporates feedback from Greg K-H and Paul Bolle, and it differs from the the first version in that it:
- Removes code that has no callers
- Updates the MODULE_LICENSE macro
- Provides explanations in each of the patches
- Fixes the Kconfig so that the defaults and depends are reasonable
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 | 7 + drivers/pci/host/Makefile | 1 + drivers/pci/host/hv_pcifront.c | 1984 +++++++++++++++++++++++++++++++++++++++ drivers/video/fbdev/hyperv_fb.c | 46 +- include/linux/hyperv.h | 20 +- 9 files changed, 2256 insertions(+), 43 deletions(-) create mode 100644 drivers/pci/host/hv_pcifront.c
Signature · 1 line
1.9.1
PATCH v2 1/6 drivers:hv: Modify vmbus to search for all MMIO ranges available
From: Jake Oshins <[email protected]>
Before this patch, hv_vmbus would search the ACPI namespace above its device looking for a _CRS (current resources) object, and hunt through the list of resources in there looking for one that described memory- mapped I/O space above the 4GB line. It then exported the result for use in the hyperv_fb (frame buffer) driver.
With this patch, hv_vmbus looks for all usable MMIO ranges above 1GB and makes a list of them, with the highest range first in the list, as drivers which can allocate from that range should allocate from it.
Hyperv_fb is slightly modified to use this change.
This change is necessary for supporting other Hyper-V related drivers, which might need MMIO space below 4GB.
--- 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 v2 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]>
Currently, hv_vmbus finds the ranges of memory-mapped I/O space that are designated for paravirtual (and fully virtual) devices by the virtual firmware (BIOS or UEFI) and exports the answer. The hyperv_fb video driver then takes that information and uses it to claim a range of MMIO space.
This patch moves the logic for deciding which sub-range of MMIO space to claim from hyperv_fb to hv_vmbus, so that other drivers can share the same logic. It is also slightly expanded so that it searches all of the potential MMIO ranges described by the ACPI namespace.
--- 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
PATCH v2 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]>
This patch, when the kernel is built with CONFIG_HYPERV, exposes functions that would allow a paravirtual PCI front-end driver to hook MSI (message- signaled interrupt) message creation.
--- 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 v2 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]>
This patch exports a function which maps Linux processor number onto Hyper-V virtual processor number. This is necessary in order to map message- signaled interrupts (MSIs) into a VM, as the hypervisor needs to know the right target VP.
--- 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
Re: [PATCH v2 4/6] drivers:hv: Export a function that maps Linux proc num onto Hyper-V proc num
Quoted 18 lines · On Mon, Jun 15, 2015 at 05:06:37PM +0000, [email protected] wrote:
From: Jake Oshins <[email protected]>
This patch exports a function which maps Linux processor number onto Hyper-V virtual processor number. This is necessary in order to map message- signaled interrupts (MSIs) into a VM, as the hypervisor needs to know the right target VP.
Signed-off-by 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 +0
-0
drivers/hv/vmbus_drv.c int vmbus_allocate_mmio(struct resource **new, struct hv_device *device_obj, · line 1167
Quoted 10 lines
drivers/hv/vmbus_drv.c +7
-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
What kind of comment structure is this? It's not kernel doc :(
And "procnum" sounds like "process number", why not "cpu_number"?
RE: [PATCH v2 4/6] drivers:hv: Export a function that maps Linux proc num onto Hyper-V proc num
Quoted 21 lines
-----Original Message-----
From: Greg KH [mailto:[email protected]]
Sent: Monday, June 15, 2015 12:52 PM
To: Jake Oshins
Cc: KY Srinivasan; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; Haiyang Zhang; Mike Ebersol
Subject: Re: [PATCH v2 4/6] drivers:hv: Export a function that maps Linux proc num onto Hyper-V proc numQuoted 7 lines
+/**
+ * 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
Quoted 3 lines
What kind of comment structure is this? It's not kernel doc :(
And "procnum" sounds like "process number", why not "
cpu_number"?
Thanks. I'll wait a little while to see if any other feedback comes in and then I'll fix these and resend.
-- Jake Oshins
PATCH v2 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]>
This patch updates the list of VMBus channel GUIDs, defining the one for PCI Express pass-through.
--- 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 v2 6/6 drivers:pci:hv: New paravirtual PCI front-end for Hyper-V VMs
In reply to [email protected]From: Jake Oshins <[email protected]>
This patch supplies a new driver, hv_pcifront, which exposes new root PCI buses. When a Hyper-V VM running Linux is offered a paravirtual PCI bus in order to expose a device passed through on that bus, this drver registers a new bus with the PCI driver. This new bus is bus "zero" within a new PCI domain. This is done so that there's no overlap between the emulated, or fully virtualized, PCI that may be in the VM and a real PCIe device that will be exposed.
This PCI front-end only supports PCIe devices which do not use I/O BARs and which do not need a legacy INTx# interrupt (relying on MSI or MSI-X). Multifunction devices are supported, but devices with Type 1 or Type 2 config headers are not supported. (These are bridges to other PCI buses.)
The content of this patch differs from the one sent previously in that it incorporates feedback related to unused code (which has been removed) and GPL license (which has been updated.) It also removes Kconfig lines that had been copied from the Xen PCI front-end entry, but which shouldn't be used here.
--- MAINTAINERS | 1 + drivers/pci/Kconfig | 7 + drivers/pci/host/Makefile | 1 + drivers/pci/host/hv_pcifront.c | 1984 ++++++++++++++++++++++++++++++++++++++++ 4 files changed, 1993 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 +7 -0
@@ -114,4 +114,11 @@ config PCI_LABEL def_bool y if (DMI || ACPI) select NLS +config HYPERV_VPCI + tristate "Hyper-V PCI Frontend" + depends on PCI && X86 && HYPERV + 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 +1984 -0
1,984 lines not on this page · raw message
Signature · 1 line
1.9.1
Re: [PATCH v2 6/6] drivers:pci:hv: New paravirtual PCI front-end for Hyper-V VMs
Quoted 15 lines · On Mon, Jun 15, 2015 at 05:06:39PM +0000, [email protected] wrote:
From: Jake Oshins <[email protected]>
This patch supplies a new driver,
hv_pcifront, which exposes new root PCI buses. When a Hyper-V VM running Linux is offered a paravirtual PCI bus in order to expose a device passed through on that bus, this drver registers a new bus with the PCI driver. This new bus is bus "zero" within a new PCI domain. This is done so that there's no overlap between the emulated, or fully virtualized, PCI that may be in the VM and a real PCIe device that will be exposed.This PCI front-end only supports PCIe devices which do not use I/O BARs and which do not need a legacy INTx# interrupt (relying on MSI or MSI-X). Multifunction devices are supported, but devices with Type 1 or Type 2 config headers are not supported. (These are bridges to other PCI buses.)
Quoted 5 lines
The content of this patch differs from the one sent previously in that it incorporates feedback related to unused code (which has been removed) and GPL license (which has been updated.) It also removes
Kconfiglines that had been copied from the Xen PCI front-end entry, but which shouldn't be used here.
This paragraph goes below the --- line, we don't need it in the changelog :(