[PATCH 0/3] x86/Hyper-V/IOMMU: Add Hyper-V IOMMU driver to support x2apic mode

[PATCH 0/3] x86/Hyper-V/IOMMU: Add Hyper-V IOMMU driver to support x2apic mode

[lantianyu1986]

From: Lan Tianyu <Tianyu.Lan@microsoft.com>

On the bare metal, enabling X2APIC mode requires interrupt remapping
function which helps to deliver irq to cpu with 32-bit APIC ID.
Hyper-V doesn't provide interrupt remapping function so far and Hyper-V
MSI protocol already supports to deliver interrupt to the CPU whose
virtual processor index is more than 255. IO-APIC interrupt still has
8-bit APIC ID limitation.

This patchset is to add Hyper-V stub IOMMU driver in order to enable
X2APIC mode successfully in Hyper-V Linux guest. The driver returns X2APIC
interrupt remapping capability when X2APIC mode is available. X2APIC
destination mode is set to physical by PATCH 1 when X2APIC is available.
Hyper-V IOMMU driver will scan cpu 0~255 and set cpu into IO-APIC MAX cpu
affinity cpumask if its APIC ID is 8-bit. Driver creates a Hyper-V irq domain
to limit IO-APIC interrupts' affinity and make sure cpus assigned with IO-APIC
interrupt are in the scope of IO-APIC MAX cpu affinity.

Lan Tianyu (3):
  x86/Hyper-V: Set x2apic destination mode to physical when x2apic is   
     available
  HYPERV/IOMMU: Add Hyper-V stub IOMMU driver
  MAINTAINERS: Add Hyper-V IOMMU driver into Hyper-V CORE AND DRIVERS
    scope

 MAINTAINERS                    |   1 +
 arch/x86/kernel/cpu/mshyperv.c |  14 +++
 drivers/iommu/Kconfig          |   7 ++
 drivers/iommu/Makefile         |   1 +
 drivers/iommu/hyperv-iommu.c   | 189 +++++++++++++++++++++++++++++++++++++++++
 drivers/iommu/irq_remapping.c  |   3 +
 drivers/iommu/irq_remapping.h  |   1 +
 7 files changed, 216 insertions(+)
 create mode 100644 drivers/iommu/hyperv-iommu.c

-- 
2.7.4

[PATCH 1/3] x86/Hyper-V: Set x2apic destination mode to physical when x2apic is available

[lantianyu1986]

From: Lan Tianyu <Tianyu.Lan@microsoft.com>

Hyper-V doesn't provide irq remapping for IO-APIC. To enable x2apic,
set x2apic destination mode to physcial mode when x2apic is available
and Hyper-V IOMMU driver makes sure cpus assigned with IO-APIC irqs have
8-bit APIC id.

Signed-off-by: Lan Tianyu <Tianyu.Lan@microsoft.com>
---
 arch/x86/kernel/cpu/mshyperv.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index e81a2db..9d62f33 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -36,6 +36,8 @@
 struct ms_hyperv_info ms_hyperv;
 EXPORT_SYMBOL_GPL(ms_hyperv);
 
+extern int x2apic_phys;
+
 #if IS_ENABLED(CONFIG_HYPERV)
 static void (*vmbus_handler)(void);
 static void (*hv_stimer0_handler)(void);
@@ -328,6 +330,18 @@ static void __init ms_hyperv_init_platform(void)
 # ifdef CONFIG_SMP
 	smp_ops.smp_prepare_boot_cpu = hv_smp_prepare_boot_cpu;
 # endif
+
+/*
+ * Hyper-V doesn't provide irq remapping for IO-APIC. To enable x2apic,
+ * set x2apic destination mode to physcial mode when x2apic is available
+ * and Hyper-V IOMMU driver makes sure cpus assigned with IO-APIC irqs
+ * have 8-bit APIC id.
+ */
+# if IS_ENABLED(CONFIG_HYPERV_IOMMU)
+	if (x2apic_supported())
+		x2apic_phys = 1;
+# endif
+
 #endif
 }
 
-- 
2.7.4

[PATCH 2/3] HYPERV/IOMMU: Add Hyper-V stub IOMMU driver

[lantianyu1986]

From: Lan Tianyu <Tianyu.Lan@microsoft.com>

On the bare metal, enabling X2APIC mode requires interrupt remapping
function which helps to deliver irq to cpu with 32-bit APIC ID.
Hyper-V doesn't provide interrupt remapping function so far and Hyper-V
MSI protocol already supports to deliver interrupt to the CPU whose
virtual processor index is more than 255. IO-APIC interrupt still has
8-bit APIC ID limitation.

This patch is to add Hyper-V stub IOMMU driver in order to enable
X2APIC mode successfully in Hyper-V Linux guest. The driver returns X2APIC
interrupt remapping capability when X2APIC mode is available. Otherwise,
it creates a Hyper-V irq domain to limit IO-APIC interrupts' affinity
and make sure cpus assigned with IO-APIC interrupt have 8-bit APIC ID.

Signed-off-by: Lan Tianyu <Tianyu.Lan@microsoft.com>
---
 drivers/iommu/Kconfig         |   7 ++
 drivers/iommu/Makefile        |   1 +
 drivers/iommu/hyperv-iommu.c  | 189 ++++++++++++++++++++++++++++++++++++++++++
 drivers/iommu/irq_remapping.c |   3 +
 drivers/iommu/irq_remapping.h |   1 +
 5 files changed, 201 insertions(+)
 create mode 100644 drivers/iommu/hyperv-iommu.c

diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 45d7021..5c397c0 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -437,4 +437,11 @@ config QCOM_IOMMU
 	help
 	  Support for IOMMU on certain Qualcomm SoCs.
 
+config HYPERV_IOMMU
+	bool "Hyper-V stub IOMMU support"
+	depends on HYPERV
+	help
+	    Hyper-V stub IOMMU driver provides capability to run
+	    Linux guest with X2APIC mode enabled.
+
 endif # IOMMU_SUPPORT
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index a158a68..8c71a15 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -32,3 +32,4 @@ obj-$(CONFIG_EXYNOS_IOMMU) += exynos-iommu.o
 obj-$(CONFIG_FSL_PAMU) += fsl_pamu.o fsl_pamu_domain.o
 obj-$(CONFIG_S390_IOMMU) += s390-iommu.o
 obj-$(CONFIG_QCOM_IOMMU) += qcom_iommu.o
+obj-$(CONFIG_HYPERV_IOMMU) += hyperv-iommu.o
diff --git a/drivers/iommu/hyperv-iommu.c b/drivers/iommu/hyperv-iommu.c
new file mode 100644
index 0000000..a64b747
--- /dev/null
+++ b/drivers/iommu/hyperv-iommu.c
@@ -0,0 +1,189 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#define pr_fmt(fmt)     "HYPERV-IR: " fmt
+
+#include <linux/types.h>
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/iommu.h>
+#include <linux/module.h>
+
+#include <asm/hw_irq.h>
+#include <asm/io_apic.h>
+#include <asm/irq_remapping.h>
+#include <asm/hypervisor.h>
+
+#include "irq_remapping.h"
+
+/*
+ * According IO-APIC spec, IO APIC has a 24-entry Interrupt
+ * Redirection Table.
+ */
+#define IOAPIC_REMAPPING_ENTRY 24
+
+static cpumask_t ioapic_max_cpumask = { CPU_BITS_NONE };
+struct irq_domain *ioapic_ir_domain;
+
+static int hyperv_ir_set_affinity(struct irq_data *data,
+		const struct cpumask *mask, bool force)
+{
+	struct irq_data *parent = data->parent_data;
+	struct irq_cfg *cfg = irqd_cfg(data);
+	struct IO_APIC_route_entry *entry;
+	cpumask_t cpumask;
+	int ret;
+
+	cpumask_andnot(&cpumask, mask, &ioapic_max_cpumask);
+
+	/* Return error If new irq affinity is out of ioapic_max_cpumask. */
+	if (!cpumask_empty(&cpumask))
+		return -EINVAL;
+
+	ret = parent->chip->irq_set_affinity(parent, mask, force);
+	if (ret < 0 || ret == IRQ_SET_MASK_OK_DONE)
+		return ret;
+
+	entry = data->chip_data;
+	entry->dest = cfg->dest_apicid;
+	entry->vector = cfg->vector;
+	send_cleanup_vector(cfg);
+
+	return 0;
+}
+
+static struct irq_chip hyperv_ir_chip = {
+	.name			= "HYPERV-IR",
+	.irq_ack		= apic_ack_irq,
+	.irq_set_affinity	= hyperv_ir_set_affinity,
+};
+
+static int hyperv_irq_remapping_alloc(struct irq_domain *domain,
+				     unsigned int virq, unsigned int nr_irqs,
+				     void *arg)
+{
+	struct irq_alloc_info *info = arg;
+	struct IO_APIC_route_entry *entry;
+	struct irq_data *irq_data;
+	struct irq_desc *desc;
+	struct irq_cfg *cfg;
+	int ret = 0;
+
+	if (!info || info->type != X86_IRQ_ALLOC_TYPE_IOAPIC || nr_irqs > 1)
+		return -EINVAL;
+
+	ret = irq_domain_alloc_irqs_parent(domain, virq, nr_irqs, arg);
+	if (ret < 0)
+		goto fail;
+
+	irq_data = irq_domain_get_irq_data(domain, virq);
+	cfg = irqd_cfg(irq_data);
+	if (!irq_data || !cfg) {
+		ret = -EINVAL;
+		goto fail;
+	}
+
+	irq_data->chip = &hyperv_ir_chip;
+
+	/*
+	 * Save IOAPIC entry pointer here in order to set vector and
+	 * and dest_apicid in the hyperv_irq_remappng_activate()
+	 * and hyperv_ir_set_affinity(). IOAPIC driver ignores
+	 * cfg->dest_apicid and cfg->vector when irq remapping
+	 * mode is enabled. Detail see ioapic_configure_entry().
+	 */
+	irq_data->chip_data = entry = info->ioapic_entry;
+
+	/*
+	 * Hypver-V IO APIC irq affinity should be in the scope of
+	 * ioapic_max_cpumask because no irq remapping support.
+	 */
+	desc = irq_data_to_desc(irq_data);
+	cpumask_and(desc->irq_common_data.affinity,
+			desc->irq_common_data.affinity,
+			&ioapic_max_cpumask);
+
+ fail:
+	return ret;
+}
+
+static void hyperv_irq_remapping_free(struct irq_domain *domain,
+				 unsigned int virq, unsigned int nr_irqs)
+{
+	irq_domain_free_irqs_common(domain, virq, nr_irqs);
+}
+
+static int hyperv_irq_remappng_activate(struct irq_domain *domain,
+			  struct irq_data *irq_data, bool reserve)
+{
+	struct irq_cfg *cfg = irqd_cfg(irq_data);
+	struct IO_APIC_route_entry *entry = irq_data->chip_data;
+
+	entry->dest = cfg->dest_apicid;
+	entry->vector = cfg->vector;
+
+	return 0;
+}
+
+static struct irq_domain_ops hyperv_ir_domain_ops = {
+	.alloc = hyperv_irq_remapping_alloc,
+	.free = hyperv_irq_remapping_free,
+	.activate = hyperv_irq_remappng_activate,
+};
+
+static int __init hyperv_prepare_irq_remapping(void)
+{
+	struct fwnode_handle *fn;
+	u32 apic_id;
+	int i;
+
+	if (x86_hyper_type != X86_HYPER_MS_HYPERV ||
+	    !x2apic_supported())
+		return -ENODEV;
+
+	fn = irq_domain_alloc_named_id_fwnode("HYPERV-IR", 0);
+	if (!fn)
+		return -EFAULT;
+
+	ioapic_ir_domain =
+		irq_domain_create_hierarchy(arch_get_ir_parent_domain(),
+				0, IOAPIC_REMAPPING_ENTRY, fn,
+				&hyperv_ir_domain_ops, NULL);
+
+	irq_domain_free_fwnode(fn);
+
+	/*
+	 * Hyper-V doesn't provide irq remapping function for
+	 * IO-APIC and so IO-APIC only accepts 8-bit APIC ID.
+	 * Prepare max cpu affinity for IOAPIC irqs. Scan cpu 0-255
+	 * and set cpu into ioapic_max_cpumask if its APIC ID is less
+	 * than 255.
+	 */
+	for (i = 0; i < 256; i++) {
+		apic_id = cpu_physical_id(i);
+		if (apic_id > 255)
+			continue;
+
+		cpumask_set_cpu(i, &ioapic_max_cpumask);
+	}
+
+	return 0;
+}
+
+static int __init hyperv_enable_irq_remapping(void)
+{
+	return IRQ_REMAP_X2APIC_MODE;
+}
+
+static struct irq_domain *hyperv_get_ir_irq_domain(struct irq_alloc_info *info)
+{
+	if (info->type == X86_IRQ_ALLOC_TYPE_IOAPIC)
+		return ioapic_ir_domain;
+	else
+		return NULL;
+}
+
+struct irq_remap_ops hyperv_irq_remap_ops = {
+	.prepare		= hyperv_prepare_irq_remapping,
+	.enable			= hyperv_enable_irq_remapping,
+	.get_ir_irq_domain	= hyperv_get_ir_irq_domain,
+};
diff --git a/drivers/iommu/irq_remapping.c b/drivers/iommu/irq_remapping.c
index b94ebd4..81cf290 100644
--- a/drivers/iommu/irq_remapping.c
+++ b/drivers/iommu/irq_remapping.c
@@ -103,6 +103,9 @@ int __init irq_remapping_prepare(void)
 	else if (IS_ENABLED(CONFIG_AMD_IOMMU) &&
 		 amd_iommu_irq_ops.prepare() == 0)
 		remap_ops = &amd_iommu_irq_ops;
+	else if (IS_ENABLED(CONFIG_HYPERV_IOMMU) &&
+		 hyperv_irq_remap_ops.prepare() == 0)
+		remap_ops = &hyperv_irq_remap_ops;
 	else
 		return -ENOSYS;
 
diff --git a/drivers/iommu/irq_remapping.h b/drivers/iommu/irq_remapping.h
index 0afef6e..f8609e9 100644
--- a/drivers/iommu/irq_remapping.h
+++ b/drivers/iommu/irq_remapping.h
@@ -64,6 +64,7 @@ struct irq_remap_ops {
 
 extern struct irq_remap_ops intel_irq_remap_ops;
 extern struct irq_remap_ops amd_iommu_irq_ops;
+extern struct irq_remap_ops hyperv_irq_remap_ops;
 
 #else  /* CONFIG_IRQ_REMAP */
 
-- 
2.7.4

[PATCH 3/3] MAINTAINERS: Add Hyper-V IOMMU driver into Hyper-V CORE AND DRIVERS scope

[lantianyu1986]

From: Lan Tianyu <Tianyu.Lan@microsoft.com>

This patch is to add Hyper-V IOMMU driver file into Hyper-V CORE and
DRIVERS scope.

Signed-off-by: Lan Tianyu <Tianyu.Lan@microsoft.com>
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 9f64f8d..5fb6306 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7015,6 +7015,7 @@ F:	drivers/net/hyperv/
 F:	drivers/scsi/storvsc_drv.c
 F:	drivers/uio/uio_hv_generic.c
 F:	drivers/video/fbdev/hyperv_fb.c
+F:	drivers/iommu/hyperv_iommu.c
 F:	net/vmw_vsock/hyperv_transport.c
 F:	include/linux/hyperv.h
 F:	include/uapi/linux/hyperv.h
-- 
2.7.4

Re: [PATCH 1/3] x86/Hyper-V: Set x2apic destination mode to physical when x2apic is available

[Greg KH]

On Thu, Jan 31, 2019 at 06:17:31PM +0800, lantianyu1986@gmail.com wrote:
> From: Lan Tianyu <Tianyu.Lan@microsoft.com>
> 
> Hyper-V doesn't provide irq remapping for IO-APIC. To enable x2apic,
> set x2apic destination mode to physcial mode when x2apic is available
> and Hyper-V IOMMU driver makes sure cpus assigned with IO-APIC irqs have
> 8-bit APIC id.
> 
> Signed-off-by: Lan Tianyu <Tianyu.Lan@microsoft.com>
> ---
>  arch/x86/kernel/cpu/mshyperv.c | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
> index e81a2db..9d62f33 100644
> --- a/arch/x86/kernel/cpu/mshyperv.c
> +++ b/arch/x86/kernel/cpu/mshyperv.c
> @@ -36,6 +36,8 @@
>  struct ms_hyperv_info ms_hyperv;
>  EXPORT_SYMBOL_GPL(ms_hyperv);
>  
> +extern int x2apic_phys;

Shouldn't this be in a .h file somewhere instead?

thanks,

greg k-h

Re: [PATCH 2/3] HYPERV/IOMMU: Add Hyper-V stub IOMMU driver

[Greg KH]

On Thu, Jan 31, 2019 at 06:17:32PM +0800, lantianyu1986@gmail.com wrote:
> --- /dev/null
> +++ b/drivers/iommu/hyperv-iommu.c
> @@ -0,0 +1,189 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +#define pr_fmt(fmt)     "HYPERV-IR: " fmt

Minor nit, you never do any pr_*() calls, so this isn't needed, right?

> +static cpumask_t ioapic_max_cpumask = { CPU_BITS_NONE };
> +struct irq_domain *ioapic_ir_domain;

Global?  Why?

thanks,

greg k-h

Re: [PATCH 1/3] x86/Hyper-V: Set x2apic destination mode to physical when x2apic is available

[Tianyu Lan]

Hi Greg:
             Thanks for your review.

On Thu, Jan 31, 2019 at 7:57 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Thu, Jan 31, 2019 at 06:17:31PM +0800, lantianyu1986@gmail.com wrote:
> > From: Lan Tianyu <Tianyu.Lan@microsoft.com>
> >
> > Hyper-V doesn't provide irq remapping for IO-APIC. To enable x2apic,
> > set x2apic destination mode to physcial mode when x2apic is available
> > and Hyper-V IOMMU driver makes sure cpus assigned with IO-APIC irqs have
> > 8-bit APIC id.
> >
> > Signed-off-by: Lan Tianyu <Tianyu.Lan@microsoft.com>
> > ---
> >  arch/x86/kernel/cpu/mshyperv.c | 14 ++++++++++++++
> >  1 file changed, 14 insertions(+)
> >
> > diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
> > index e81a2db..9d62f33 100644
> > --- a/arch/x86/kernel/cpu/mshyperv.c
> > +++ b/arch/x86/kernel/cpu/mshyperv.c
> > @@ -36,6 +36,8 @@
> >  struct ms_hyperv_info ms_hyperv;
> >  EXPORT_SYMBOL_GPL(ms_hyperv);
> >
> > +extern int x2apic_phys;
>
> Shouldn't this be in a .h file somewhere instead?

You are right. I should use <asm/apic.h> here. Thanks.

> thanks,
>
> greg k-h



-- 
Best regards
Tianyu Lan

Re: [PATCH 2/3] HYPERV/IOMMU: Add Hyper-V stub IOMMU driver

[Tianyu Lan]

On Thu, Jan 31, 2019 at 7:59 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Thu, Jan 31, 2019 at 06:17:32PM +0800, lantianyu1986@gmail.com wrote:
> > --- /dev/null
> > +++ b/drivers/iommu/hyperv-iommu.c
> > @@ -0,0 +1,189 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +
> > +#define pr_fmt(fmt)     "HYPERV-IR: " fmt
>
> Minor nit, you never do any pr_*() calls, so this isn't needed, right?

Yes, you are right. I will remove it. Sorry. I used pr_info() during
development stage and removed
them before sending patch out. Thanks.

>
> > +static cpumask_t ioapic_max_cpumask = { CPU_BITS_NONE };
> > +struct irq_domain *ioapic_ir_domain;
>
> Global?  Why?

It should be "static" here.

-- 
Best regards
Tianyu Lan

Re: [PATCH 2/3] HYPERV/IOMMU: Add Hyper-V stub IOMMU driver

[Vitaly Kuznetsov]

lantianyu1986@gmail.com writes:

> From: Lan Tianyu <Tianyu.Lan@microsoft.com>
>
> On the bare metal, enabling X2APIC mode requires interrupt remapping
> function which helps to deliver irq to cpu with 32-bit APIC ID.
> Hyper-V doesn't provide interrupt remapping function so far and Hyper-V
> MSI protocol already supports to deliver interrupt to the CPU whose
> virtual processor index is more than 255. IO-APIC interrupt still has
> 8-bit APIC ID limitation.
>
> This patch is to add Hyper-V stub IOMMU driver in order to enable
> X2APIC mode successfully in Hyper-V Linux guest. The driver returns X2APIC
> interrupt remapping capability when X2APIC mode is available. Otherwise,
> it creates a Hyper-V irq domain to limit IO-APIC interrupts' affinity
> and make sure cpus assigned with IO-APIC interrupt have 8-bit APIC ID.
>
> Signed-off-by: Lan Tianyu <Tianyu.Lan@microsoft.com>
> ---
>  drivers/iommu/Kconfig         |   7 ++
>  drivers/iommu/Makefile        |   1 +
>  drivers/iommu/hyperv-iommu.c  | 189 ++++++++++++++++++++++++++++++++++++++++++
>  drivers/iommu/irq_remapping.c |   3 +
>  drivers/iommu/irq_remapping.h |   1 +
>  5 files changed, 201 insertions(+)
>  create mode 100644 drivers/iommu/hyperv-iommu.c
>
> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> index 45d7021..5c397c0 100644
> --- a/drivers/iommu/Kconfig
> +++ b/drivers/iommu/Kconfig
> @@ -437,4 +437,11 @@ config QCOM_IOMMU
>  	help
>  	  Support for IOMMU on certain Qualcomm SoCs.
>  
> +config HYPERV_IOMMU
> +	bool "Hyper-V stub IOMMU support"
> +	depends on HYPERV
> +	help
> +	    Hyper-V stub IOMMU driver provides capability to run
> +	    Linux guest with X2APIC mode enabled.
> +
>  endif # IOMMU_SUPPORT
> diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
> index a158a68..8c71a15 100644
> --- a/drivers/iommu/Makefile
> +++ b/drivers/iommu/Makefile
> @@ -32,3 +32,4 @@ obj-$(CONFIG_EXYNOS_IOMMU) += exynos-iommu.o
>  obj-$(CONFIG_FSL_PAMU) += fsl_pamu.o fsl_pamu_domain.o
>  obj-$(CONFIG_S390_IOMMU) += s390-iommu.o
>  obj-$(CONFIG_QCOM_IOMMU) += qcom_iommu.o
> +obj-$(CONFIG_HYPERV_IOMMU) += hyperv-iommu.o
> diff --git a/drivers/iommu/hyperv-iommu.c b/drivers/iommu/hyperv-iommu.c
> new file mode 100644
> index 0000000..a64b747
> --- /dev/null
> +++ b/drivers/iommu/hyperv-iommu.c
> @@ -0,0 +1,189 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +#define pr_fmt(fmt)     "HYPERV-IR: " fmt
> +
> +#include <linux/types.h>
> +#include <linux/interrupt.h>
> +#include <linux/irq.h>
> +#include <linux/iommu.h>
> +#include <linux/module.h>
> +
> +#include <asm/hw_irq.h>
> +#include <asm/io_apic.h>
> +#include <asm/irq_remapping.h>
> +#include <asm/hypervisor.h>
> +
> +#include "irq_remapping.h"
> +
> +/*
> + * According IO-APIC spec, IO APIC has a 24-entry Interrupt
> + * Redirection Table.
> + */
> +#define IOAPIC_REMAPPING_ENTRY 24

KVM already defines KVM_IOAPIC_NUM_PINS - is this the same thing?

> +
> +static cpumask_t ioapic_max_cpumask = { CPU_BITS_NONE };
> +struct irq_domain *ioapic_ir_domain;
> +
> +static int hyperv_ir_set_affinity(struct irq_data *data,
> +		const struct cpumask *mask, bool force)
> +{
> +	struct irq_data *parent = data->parent_data;
> +	struct irq_cfg *cfg = irqd_cfg(data);
> +	struct IO_APIC_route_entry *entry;
> +	cpumask_t cpumask;
> +	int ret;
> +
> +	cpumask_andnot(&cpumask, mask, &ioapic_max_cpumask);
> +
> +	/* Return error If new irq affinity is out of ioapic_max_cpumask. */
> +	if (!cpumask_empty(&cpumask))
> +		return -EINVAL;
> +
> +	ret = parent->chip->irq_set_affinity(parent, mask, force);
> +	if (ret < 0 || ret == IRQ_SET_MASK_OK_DONE)
> +		return ret;
> +
> +	entry = data->chip_data;
> +	entry->dest = cfg->dest_apicid;
> +	entry->vector = cfg->vector;
> +	send_cleanup_vector(cfg);
> +
> +	return 0;
> +}
> +
> +static struct irq_chip hyperv_ir_chip = {
> +	.name			= "HYPERV-IR",
> +	.irq_ack		= apic_ack_irq,
> +	.irq_set_affinity	= hyperv_ir_set_affinity,
> +};
> +
> +static int hyperv_irq_remapping_alloc(struct irq_domain *domain,
> +				     unsigned int virq, unsigned int nr_irqs,
> +				     void *arg)
> +{
> +	struct irq_alloc_info *info = arg;
> +	struct IO_APIC_route_entry *entry;
> +	struct irq_data *irq_data;
> +	struct irq_desc *desc;
> +	struct irq_cfg *cfg;
> +	int ret = 0;
> +
> +	if (!info || info->type != X86_IRQ_ALLOC_TYPE_IOAPIC || nr_irqs > 1)
> +		return -EINVAL;
> +
> +	ret = irq_domain_alloc_irqs_parent(domain, virq, nr_irqs, arg);
> +	if (ret < 0)
> +		goto fail;
> +
> +	irq_data = irq_domain_get_irq_data(domain, virq);
> +	cfg = irqd_cfg(irq_data);
> +	if (!irq_data || !cfg) {
> +		ret = -EINVAL;
> +		goto fail;
> +	}

fail: label doesn't do anything, you can just return (and you actually
do on the first failure path).

> +
> +	irq_data->chip = &hyperv_ir_chip;
> +
> +	/*
> +	 * Save IOAPIC entry pointer here in order to set vector and
> +	 * and dest_apicid in the hyperv_irq_remappng_activate()

and and

> +	 * and hyperv_ir_set_affinity(). IOAPIC driver ignores
> +	 * cfg->dest_apicid and cfg->vector when irq remapping
> +	 * mode is enabled. Detail see ioapic_configure_entry().

I would re-phrase this a bit:

/*
 * IOAPIC entry pointer is saved in chip_data to allow
 * hyperv_irq_remappng_activate()/hyperv_ir_set_affinity() to set
 * vector and dest_apicid. cfg->vector and cfg->dest_apicid are
 * ignorred when IRQ remapping is enabled. See ioapic_configure_entry().
 */

But I'm still a bit confused. Hope others are not.

> +	 */
> +	irq_data->chip_data = entry = info->ioapic_entry;
> +

I personally dislike double assignments, hard to remember which one
happens first :-)

> +	/*
> +	 * Hypver-V IO APIC irq affinity should be in the scope of
> +	 * ioapic_max_cpumask because no irq remapping support.
> +	 */
> +	desc = irq_data_to_desc(irq_data);
> +	cpumask_and(desc->irq_common_data.affinity,
> +			desc->irq_common_data.affinity,
> +			&ioapic_max_cpumask);
> +
> + fail:
> +	return ret;
> +}
> +
> +static void hyperv_irq_remapping_free(struct irq_domain *domain,
> +				 unsigned int virq, unsigned int nr_irqs)
> +{
> +	irq_domain_free_irqs_common(domain, virq, nr_irqs);
> +}
> +
> +static int hyperv_irq_remappng_activate(struct irq_domain *domain,
> +			  struct irq_data *irq_data, bool reserve)
> +{
> +	struct irq_cfg *cfg = irqd_cfg(irq_data);
> +	struct IO_APIC_route_entry *entry = irq_data->chip_data;
> +
> +	entry->dest = cfg->dest_apicid;
> +	entry->vector = cfg->vector;
> +
> +	return 0;
> +}
> +
> +static struct irq_domain_ops hyperv_ir_domain_ops = {
> +	.alloc = hyperv_irq_remapping_alloc,
> +	.free = hyperv_irq_remapping_free,
> +	.activate = hyperv_irq_remappng_activate,
> +};
> +
> +static int __init hyperv_prepare_irq_remapping(void)
> +{
> +	struct fwnode_handle *fn;
> +	u32 apic_id;
> +	int i;
> +
> +	if (x86_hyper_type != X86_HYPER_MS_HYPERV ||
> +	    !x2apic_supported())
> +		return -ENODEV;
> +
> +	fn = irq_domain_alloc_named_id_fwnode("HYPERV-IR", 0);
> +	if (!fn)
> +		return -EFAULT;
> +
> +	ioapic_ir_domain =
> +		irq_domain_create_hierarchy(arch_get_ir_parent_domain(),
> +				0, IOAPIC_REMAPPING_ENTRY, fn,
> +				&hyperv_ir_domain_ops, NULL);
> +
> +	irq_domain_free_fwnode(fn);
> +
> +	/*
> +	 * Hyper-V doesn't provide irq remapping function for
> +	 * IO-APIC and so IO-APIC only accepts 8-bit APIC ID.
> +	 * Prepare max cpu affinity for IOAPIC irqs. Scan cpu 0-255
> +	 * and set cpu into ioapic_max_cpumask if its APIC ID is less
> +	 * than 255.
> +	 */
> +	for (i = 0; i < 256; i++) {
> +		apic_id = cpu_physical_id(i);
> +		if (apic_id > 255)
> +			continue;
> +
> +		cpumask_set_cpu(i, &ioapic_max_cpumask);
> +	}

This is probably not an issue right now, but what if we have > 256 CPUs?
Assuming there are no CPUs with the same APIC is, would it be better to
go through all of them seeting bits in ioapic_max_cpumask accordingly?
(Imagine a situation when CPU257 has APIC id = 1).

> +
> +	return 0;
> +}
> +
> +static int __init hyperv_enable_irq_remapping(void)
> +{
> +	return IRQ_REMAP_X2APIC_MODE;
> +}
> +
> +static struct irq_domain *hyperv_get_ir_irq_domain(struct irq_alloc_info *info)
> +{
> +	if (info->type == X86_IRQ_ALLOC_TYPE_IOAPIC)
> +		return ioapic_ir_domain;
> +	else
> +		return NULL;
> +}
> +
> +struct irq_remap_ops hyperv_irq_remap_ops = {
> +	.prepare		= hyperv_prepare_irq_remapping,
> +	.enable			= hyperv_enable_irq_remapping,
> +	.get_ir_irq_domain	= hyperv_get_ir_irq_domain,
> +};
> diff --git a/drivers/iommu/irq_remapping.c b/drivers/iommu/irq_remapping.c
> index b94ebd4..81cf290 100644
> --- a/drivers/iommu/irq_remapping.c
> +++ b/drivers/iommu/irq_remapping.c
> @@ -103,6 +103,9 @@ int __init irq_remapping_prepare(void)
>  	else if (IS_ENABLED(CONFIG_AMD_IOMMU) &&
>  		 amd_iommu_irq_ops.prepare() == 0)
>  		remap_ops = &amd_iommu_irq_ops;
> +	else if (IS_ENABLED(CONFIG_HYPERV_IOMMU) &&
> +		 hyperv_irq_remap_ops.prepare() == 0)
> +		remap_ops = &hyperv_irq_remap_ops;
>  	else
>  		return -ENOSYS;

Here we act under assumption that Intel/AMD IOMMUs will never be exposed
under Hyper-V. It may make sense to actually reverse the order of the
check: check PV IOMMUs _before_ we actually check for hardware ones.

>  
> diff --git a/drivers/iommu/irq_remapping.h b/drivers/iommu/irq_remapping.h
> index 0afef6e..f8609e9 100644
> --- a/drivers/iommu/irq_remapping.h
> +++ b/drivers/iommu/irq_remapping.h
> @@ -64,6 +64,7 @@ struct irq_remap_ops {
>  
>  extern struct irq_remap_ops intel_irq_remap_ops;
>  extern struct irq_remap_ops amd_iommu_irq_ops;
> +extern struct irq_remap_ops hyperv_irq_remap_ops;
>  
>  #else  /* CONFIG_IRQ_REMAP */

-- 
Vitaly

Re: [PATCH 2/3] HYPERV/IOMMU: Add Hyper-V stub IOMMU driver

[Tianyu Lan]

Hi Vitaly:
            Thanks for your review.

On Thu, Jan 31, 2019 at 10:04 PM Vitaly Kuznetsov <vkuznets@redhat.com> wrote:
>
> lantianyu1986@gmail.com writes:
>
> > From: Lan Tianyu <Tianyu.Lan@microsoft.com>
> >
> > On the bare metal, enabling X2APIC mode requires interrupt remapping
> > function which helps to deliver irq to cpu with 32-bit APIC ID.
> > Hyper-V doesn't provide interrupt remapping function so far and Hyper-V
> > MSI protocol already supports to deliver interrupt to the CPU whose
> > virtual processor index is more than 255. IO-APIC interrupt still has
> > 8-bit APIC ID limitation.
> >
> > This patch is to add Hyper-V stub IOMMU driver in order to enable
> > X2APIC mode successfully in Hyper-V Linux guest. The driver returns X2APIC
> > interrupt remapping capability when X2APIC mode is available. Otherwise,
> > it creates a Hyper-V irq domain to limit IO-APIC interrupts' affinity
> > and make sure cpus assigned with IO-APIC interrupt have 8-bit APIC ID.
> >
> > Signed-off-by: Lan Tianyu <Tianyu.Lan@microsoft.com>
> > ---
> >  drivers/iommu/Kconfig         |   7 ++
> >  drivers/iommu/Makefile        |   1 +
> >  drivers/iommu/hyperv-iommu.c  | 189 ++++++++++++++++++++++++++++++++++++++++++
> >  drivers/iommu/irq_remapping.c |   3 +
> >  drivers/iommu/irq_remapping.h |   1 +
> >  5 files changed, 201 insertions(+)
> >  create mode 100644 drivers/iommu/hyperv-iommu.c
> >
> > diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> > index 45d7021..5c397c0 100644
> > --- a/drivers/iommu/Kconfig
> > +++ b/drivers/iommu/Kconfig
> > @@ -437,4 +437,11 @@ config QCOM_IOMMU
> >       help
> >         Support for IOMMU on certain Qualcomm SoCs.
> >
> > +config HYPERV_IOMMU
> > +     bool "Hyper-V stub IOMMU support"
> > +     depends on HYPERV
> > +     help
> > +         Hyper-V stub IOMMU driver provides capability to run
> > +         Linux guest with X2APIC mode enabled.
> > +
> >  endif # IOMMU_SUPPORT
> > diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
> > index a158a68..8c71a15 100644
> > --- a/drivers/iommu/Makefile
> > +++ b/drivers/iommu/Makefile
> > @@ -32,3 +32,4 @@ obj-$(CONFIG_EXYNOS_IOMMU) += exynos-iommu.o
> >  obj-$(CONFIG_FSL_PAMU) += fsl_pamu.o fsl_pamu_domain.o
> >  obj-$(CONFIG_S390_IOMMU) += s390-iommu.o
> >  obj-$(CONFIG_QCOM_IOMMU) += qcom_iommu.o
> > +obj-$(CONFIG_HYPERV_IOMMU) += hyperv-iommu.o
> > diff --git a/drivers/iommu/hyperv-iommu.c b/drivers/iommu/hyperv-iommu.c
> > new file mode 100644
> > index 0000000..a64b747
> > --- /dev/null
> > +++ b/drivers/iommu/hyperv-iommu.c
> > @@ -0,0 +1,189 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +
> > +#define pr_fmt(fmt)     "HYPERV-IR: " fmt
> > +
> > +#include <linux/types.h>
> > +#include <linux/interrupt.h>
> > +#include <linux/irq.h>
> > +#include <linux/iommu.h>
> > +#include <linux/module.h>
> > +
> > +#include <asm/hw_irq.h>
> > +#include <asm/io_apic.h>
> > +#include <asm/irq_remapping.h>
> > +#include <asm/hypervisor.h>
> > +
> > +#include "irq_remapping.h"
> > +
> > +/*
> > + * According IO-APIC spec, IO APIC has a 24-entry Interrupt
> > + * Redirection Table.
> > + */
> > +#define IOAPIC_REMAPPING_ENTRY 24
>
> KVM already defines KVM_IOAPIC_NUM_PINS - is this the same thing?

It's the same purpose  IOMMU driver is out of KVM scope and so define a new one.
Otherwise, this maybe changed in the future when add interrupt
remapping function.

>
> > +
> > +static cpumask_t ioapic_max_cpumask = { CPU_BITS_NONE };
> > +struct irq_domain *ioapic_ir_domain;
> > +
> > +static int hyperv_ir_set_affinity(struct irq_data *data,
> > +             const struct cpumask *mask, bool force)
> > +{
> > +     struct irq_data *parent = data->parent_data;
> > +     struct irq_cfg *cfg = irqd_cfg(data);
> > +     struct IO_APIC_route_entry *entry;
> > +     cpumask_t cpumask;
> > +     int ret;
> > +
> > +     cpumask_andnot(&cpumask, mask, &ioapic_max_cpumask);
> > +
> > +     /* Return error If new irq affinity is out of ioapic_max_cpumask. */
> > +     if (!cpumask_empty(&cpumask))
> > +             return -EINVAL;
> > +
> > +     ret = parent->chip->irq_set_affinity(parent, mask, force);
> > +     if (ret < 0 || ret == IRQ_SET_MASK_OK_DONE)
> > +             return ret;
> > +
> > +     entry = data->chip_data;
> > +     entry->dest = cfg->dest_apicid;
> > +     entry->vector = cfg->vector;
> > +     send_cleanup_vector(cfg);
> > +
> > +     return 0;
> > +}
> > +
> > +static struct irq_chip hyperv_ir_chip = {
> > +     .name                   = "HYPERV-IR",
> > +     .irq_ack                = apic_ack_irq,
> > +     .irq_set_affinity       = hyperv_ir_set_affinity,
> > +};
> > +
> > +static int hyperv_irq_remapping_alloc(struct irq_domain *domain,
> > +                                  unsigned int virq, unsigned int nr_irqs,
> > +                                  void *arg)
> > +{
> > +     struct irq_alloc_info *info = arg;
> > +     struct IO_APIC_route_entry *entry;
> > +     struct irq_data *irq_data;
> > +     struct irq_desc *desc;
> > +     struct irq_cfg *cfg;
> > +     int ret = 0;
> > +
> > +     if (!info || info->type != X86_IRQ_ALLOC_TYPE_IOAPIC || nr_irqs > 1)
> > +             return -EINVAL;
> > +
> > +     ret = irq_domain_alloc_irqs_parent(domain, virq, nr_irqs, arg);
> > +     if (ret < 0)
> > +             goto fail;
> > +
> > +     irq_data = irq_domain_get_irq_data(domain, virq);
> > +     cfg = irqd_cfg(irq_data);
> > +     if (!irq_data || !cfg) {
> > +             ret = -EINVAL;
> > +             goto fail;
> > +     }
>
> fail: label doesn't do anything, you can just return (and you actually
> do on the first failure path).

Yes，will update.

>
> > +
> > +     irq_data->chip = &hyperv_ir_chip;
> > +
> > +     /*
> > +      * Save IOAPIC entry pointer here in order to set vector and
> > +      * and dest_apicid in the hyperv_irq_remappng_activate()
>
> and and

Nice catch.

>
> > +      * and hyperv_ir_set_affinity(). IOAPIC driver ignores
> > +      * cfg->dest_apicid and cfg->vector when irq remapping
> > +      * mode is enabled. Detail see ioapic_configure_entry().
>
> I would re-phrase this a bit:
>
> /*
>  * IOAPIC entry pointer is saved in chip_data to allow
>  * hyperv_irq_remappng_activate()/hyperv_ir_set_affinity() to set
>  * vector and dest_apicid. cfg->vector and cfg->dest_apicid are
>  * ignorred when IRQ remapping is enabled. See ioapic_configure_entry().
>  */
>
> But I'm still a bit confused. Hope others are not.

This is better. Thanks.

>
> > +      */
> > +     irq_data->chip_data = entry = info->ioapic_entry;
> > +
>
> I personally dislike double assignments, hard to remember which one
> happens first :-)

OK. will update.

>
> > +     /*
> > +      * Hypver-V IO APIC irq affinity should be in the scope of
> > +      * ioapic_max_cpumask because no irq remapping support.
> > +      */
> > +     desc = irq_data_to_desc(irq_data);
> > +     cpumask_and(desc->irq_common_data.affinity,
> > +                     desc->irq_common_data.affinity,
> > +                     &ioapic_max_cpumask);
> > +
> > + fail:
> > +     return ret;
> > +}
> > +
> > +static void hyperv_irq_remapping_free(struct irq_domain *domain,
> > +                              unsigned int virq, unsigned int nr_irqs)
> > +{
> > +     irq_domain_free_irqs_common(domain, virq, nr_irqs);
> > +}
> > +
> > +static int hyperv_irq_remappng_activate(struct irq_domain *domain,
> > +                       struct irq_data *irq_data, bool reserve)
> > +{
> > +     struct irq_cfg *cfg = irqd_cfg(irq_data);
> > +     struct IO_APIC_route_entry *entry = irq_data->chip_data;
> > +
> > +     entry->dest = cfg->dest_apicid;
> > +     entry->vector = cfg->vector;
> > +
> > +     return 0;
> > +}
> > +
> > +static struct irq_domain_ops hyperv_ir_domain_ops = {
> > +     .alloc = hyperv_irq_remapping_alloc,
> > +     .free = hyperv_irq_remapping_free,
> > +     .activate = hyperv_irq_remappng_activate,
> > +};
> > +
> > +static int __init hyperv_prepare_irq_remapping(void)
> > +{
> > +     struct fwnode_handle *fn;
> > +     u32 apic_id;
> > +     int i;
> > +
> > +     if (x86_hyper_type != X86_HYPER_MS_HYPERV ||
> > +         !x2apic_supported())
> > +             return -ENODEV;
> > +
> > +     fn = irq_domain_alloc_named_id_fwnode("HYPERV-IR", 0);
> > +     if (!fn)
> > +             return -EFAULT;
> > +
> > +     ioapic_ir_domain =
> > +             irq_domain_create_hierarchy(arch_get_ir_parent_domain(),
> > +                             0, IOAPIC_REMAPPING_ENTRY, fn,
> > +                             &hyperv_ir_domain_ops, NULL);
> > +
> > +     irq_domain_free_fwnode(fn);
> > +
> > +     /*
> > +      * Hyper-V doesn't provide irq remapping function for
> > +      * IO-APIC and so IO-APIC only accepts 8-bit APIC ID.
> > +      * Prepare max cpu affinity for IOAPIC irqs. Scan cpu 0-255
> > +      * and set cpu into ioapic_max_cpumask if its APIC ID is less
> > +      * than 255.
> > +      */
> > +     for (i = 0; i < 256; i++) {
> > +             apic_id = cpu_physical_id(i);
> > +             if (apic_id > 255)
> > +                     continue;
> > +
> > +             cpumask_set_cpu(i, &ioapic_max_cpumask);
> > +     }
>
> This is probably not an issue right now, but what if we have > 256 CPUs?
> Assuming there are no CPUs with the same APIC is, would it be better to
> go through all of them seeting bits in ioapic_max_cpumask accordingly?
> (Imagine a situation when CPU257 has APIC id = 1).

The APiC ID assignment with "CPUx"accords the order of local APIC
entry in the ACPI MADT table.
We got that the order will be monotonic increasing from Hyper-V team
.I will add this in the comment
to avoid confusion. APIC IDs reflects cpu topology and so there maybe
some APIC ID gaps(e.g, cpu
number in one socket is a number of  power of 2).

>
> > +
> > +     return 0;
> > +}
> > +
> > +static int __init hyperv_enable_irq_remapping(void)
> > +{
> > +     return IRQ_REMAP_X2APIC_MODE;
> > +}
> > +
> > +static struct irq_domain *hyperv_get_ir_irq_domain(struct irq_alloc_info *info)
> > +{
> > +     if (info->type == X86_IRQ_ALLOC_TYPE_IOAPIC)
> > +             return ioapic_ir_domain;
> > +     else
> > +             return NULL;
> > +}
> > +
> > +struct irq_remap_ops hyperv_irq_remap_ops = {
> > +     .prepare                = hyperv_prepare_irq_remapping,
> > +     .enable                 = hyperv_enable_irq_remapping,
> > +     .get_ir_irq_domain      = hyperv_get_ir_irq_domain,
> > +};
> > diff --git a/drivers/iommu/irq_remapping.c b/drivers/iommu/irq_remapping.c
> > index b94ebd4..81cf290 100644
> > --- a/drivers/iommu/irq_remapping.c
> > +++ b/drivers/iommu/irq_remapping.c
> > @@ -103,6 +103,9 @@ int __init irq_remapping_prepare(void)
> >       else if (IS_ENABLED(CONFIG_AMD_IOMMU) &&
> >                amd_iommu_irq_ops.prepare() == 0)
> >               remap_ops = &amd_iommu_irq_ops;
> > +     else if (IS_ENABLED(CONFIG_HYPERV_IOMMU) &&
> > +              hyperv_irq_remap_ops.prepare() == 0)
> > +             remap_ops = &hyperv_irq_remap_ops;
> >       else
> >               return -ENOSYS;
>
> Here we act under assumption that Intel/AMD IOMMUs will never be exposed
> under Hyper-V. It may make sense to actually reverse the order of the
> check: check PV IOMMUs _before_ we actually check for hardware ones.

Yes, this will be better for Hyper-V case but KVM guest and bare metal
use Intel/AMD
IOMMU driver. The function is just called once during boot up and so check order
will not affect boot time too much.

@Joerg Roedel Could you have a look this? Thanks.

Re: [PATCH 1/3] x86/Hyper-V: Set x2apic destination mode to physical when x2apic is available

[Dan Carpenter]

On Thu, Jan 31, 2019 at 06:17:31PM +0800, lantianyu1986@gmail.com wrote:
>
>

This comment needs to be indented one tab or it looks like we're outside
the funciton.

> +/*
> + * Hyper-V doesn't provide irq remapping for IO-APIC. To enable x2apic,
> + * set x2apic destination mode to physcial mode when x2apic is available
> + * and Hyper-V IOMMU driver makes sure cpus assigned with IO-APIC irqs
> + * have 8-bit APIC id.
> + */
> +# if IS_ENABLED(CONFIG_HYPERV_IOMMU)
> +	if (x2apic_supported())
> +		x2apic_phys = 1;
> +# endif

The IS_ENABLED() macro is really magical.  You could write this like so:

	if (IS_ENABLED(CONFIG_HYPERV_IOMMU) && x2apic_supported())
		x2apic_phys = 1;

It works the same and is slightly more pleasant to look at.

regards,
dan carpenter

Re: [PATCH 1/3] x86/Hyper-V: Set x2apic destination mode to physical when x2apic is available

[Tianyu Lan]

On Fri, Feb 1, 2019 at 3:07 PM Dan Carpenter <dan.carpenter@oracle.com> wrote:
>
> On Thu, Jan 31, 2019 at 06:17:31PM +0800, lantianyu1986@gmail.com wrote:
> >
> >
>
> This comment needs to be indented one tab or it looks like we're outside
> the funciton.
>
> > +/*
> > + * Hyper-V doesn't provide irq remapping for IO-APIC. To enable x2apic,
> > + * set x2apic destination mode to physcial mode when x2apic is available
> > + * and Hyper-V IOMMU driver makes sure cpus assigned with IO-APIC irqs
> > + * have 8-bit APIC id.
> > + */
> > +# if IS_ENABLED(CONFIG_HYPERV_IOMMU)
> > +     if (x2apic_supported())
> > +             x2apic_phys = 1;
> > +# endif
>
> The IS_ENABLED() macro is really magical.  You could write this like so:
>
>         if (IS_ENABLED(CONFIG_HYPERV_IOMMU) && x2apic_supported())
>                 x2apic_phys = 1;
>
> It works the same and is slightly more pleasant to look at.

Yes, that will better. Thanks for your suggestion. Dan

-- 
Best regards
Tianyu Lan

Re: [PATCH 2/3] HYPERV/IOMMU: Add Hyper-V stub IOMMU driver

[Joerg Roedel]

Hi,

On Thu, Jan 31, 2019 at 06:17:32PM +0800, lantianyu1986@gmail.com wrote:
> +config HYPERV_IOMMU
> +	bool "Hyper-V stub IOMMU support"

This is not a real IOMMU driver, it only implements IRQ remapping
capabilities. Please change the name to reflect that, e.g. to
"Hyper-V IRQ Remapping Support" or something like that.

> +static int __init hyperv_prepare_irq_remapping(void)
> +{
> +	struct fwnode_handle *fn;
> +	u32 apic_id;
> +	int i;
> +
> +	if (x86_hyper_type != X86_HYPER_MS_HYPERV ||
> +	    !x2apic_supported())
> +		return -ENODEV;
> +
> +	fn = irq_domain_alloc_named_id_fwnode("HYPERV-IR", 0);
> +	if (!fn)
> +		return -EFAULT;

Why does this return -EFAULT? I guess there is no fault happening in
irq_domain_alloc_named_id_fwnode()...


	Joerg

Re: [PATCH 2/3] HYPERV/IOMMU: Add Hyper-V stub IOMMU driver

[Robin Murphy]

On 31/01/2019 10:17, lantianyu1986@gmail.com wrote:
> From: Lan Tianyu <Tianyu.Lan@microsoft.com>
> 
> On the bare metal, enabling X2APIC mode requires interrupt remapping
> function which helps to deliver irq to cpu with 32-bit APIC ID.
> Hyper-V doesn't provide interrupt remapping function so far and Hyper-V
> MSI protocol already supports to deliver interrupt to the CPU whose
> virtual processor index is more than 255. IO-APIC interrupt still has
> 8-bit APIC ID limitation.
> 
> This patch is to add Hyper-V stub IOMMU driver in order to enable
> X2APIC mode successfully in Hyper-V Linux guest. The driver returns X2APIC
> interrupt remapping capability when X2APIC mode is available. Otherwise,
> it creates a Hyper-V irq domain to limit IO-APIC interrupts' affinity
> and make sure cpus assigned with IO-APIC interrupt have 8-bit APIC ID.

AFAICS this is a Hyper-V IOAPIC driver which neither implements nor even 
touches the IOMMU API, so having it in drivers/iommu rather than, say, 
drivers/irqchip seems a bit of a stretch to me :/

Maybe this could be a good push to clean up and properly factor out the 
x86 IRQ remapping stuff, possibly to live somewhere closer to other IRQ 
layer code? I appreciate it's a bit muddied by the major x86 vendors 
both keeping their DMA virtualisation and IRQ virtualisation 
architectures together under one umbrella "IOMMU" spec, but IIRC the 
fact that intel-iommu supports building for !IOMMU_API already causes us 
a bit of grief.

Of course, I'm coming from a particular not-entirely-objective viewpoint 
where DMA remapping (SMMU) code in drivers/iommu, IRQ remapping (ITS) 
code in drivers/irqchip, and the relevant ACPI table handling (IORT) in 
drivers/acpi is the norm, but even though that largely falls out of a 
less-tightly-coupled system architecture it does seem perfectly logical 
either way.

Robin.

(who has admittedly been drinking the Cambridge water for many years now...)

> Signed-off-by: Lan Tianyu <Tianyu.Lan@microsoft.com>
> ---
>   drivers/iommu/Kconfig         |   7 ++
>   drivers/iommu/Makefile        |   1 +
>   drivers/iommu/hyperv-iommu.c  | 189 ++++++++++++++++++++++++++++++++++++++++++
>   drivers/iommu/irq_remapping.c |   3 +
>   drivers/iommu/irq_remapping.h |   1 +
>   5 files changed, 201 insertions(+)
>   create mode 100644 drivers/iommu/hyperv-iommu.c
> 
> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> index 45d7021..5c397c0 100644
> --- a/drivers/iommu/Kconfig
> +++ b/drivers/iommu/Kconfig
> @@ -437,4 +437,11 @@ config QCOM_IOMMU
>   	help
>   	  Support for IOMMU on certain Qualcomm SoCs.
>   
> +config HYPERV_IOMMU
> +	bool "Hyper-V stub IOMMU support"
> +	depends on HYPERV
> +	help
> +	    Hyper-V stub IOMMU driver provides capability to run
> +	    Linux guest with X2APIC mode enabled.
> +
>   endif # IOMMU_SUPPORT
> diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
> index a158a68..8c71a15 100644
> --- a/drivers/iommu/Makefile
> +++ b/drivers/iommu/Makefile
> @@ -32,3 +32,4 @@ obj-$(CONFIG_EXYNOS_IOMMU) += exynos-iommu.o
>   obj-$(CONFIG_FSL_PAMU) += fsl_pamu.o fsl_pamu_domain.o
>   obj-$(CONFIG_S390_IOMMU) += s390-iommu.o
>   obj-$(CONFIG_QCOM_IOMMU) += qcom_iommu.o
> +obj-$(CONFIG_HYPERV_IOMMU) += hyperv-iommu.o
> diff --git a/drivers/iommu/hyperv-iommu.c b/drivers/iommu/hyperv-iommu.c
> new file mode 100644
> index 0000000..a64b747
> --- /dev/null
> +++ b/drivers/iommu/hyperv-iommu.c
> @@ -0,0 +1,189 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +#define pr_fmt(fmt)     "HYPERV-IR: " fmt
> +
> +#include <linux/types.h>
> +#include <linux/interrupt.h>
> +#include <linux/irq.h>
> +#include <linux/iommu.h>
> +#include <linux/module.h>
> +
> +#include <asm/hw_irq.h>
> +#include <asm/io_apic.h>
> +#include <asm/irq_remapping.h>
> +#include <asm/hypervisor.h>
> +
> +#include "irq_remapping.h"
> +
> +/*
> + * According IO-APIC spec, IO APIC has a 24-entry Interrupt
> + * Redirection Table.
> + */
> +#define IOAPIC_REMAPPING_ENTRY 24
> +
> +static cpumask_t ioapic_max_cpumask = { CPU_BITS_NONE };
> +struct irq_domain *ioapic_ir_domain;
> +
> +static int hyperv_ir_set_affinity(struct irq_data *data,
> +		const struct cpumask *mask, bool force)
> +{
> +	struct irq_data *parent = data->parent_data;
> +	struct irq_cfg *cfg = irqd_cfg(data);
> +	struct IO_APIC_route_entry *entry;
> +	cpumask_t cpumask;
> +	int ret;
> +
> +	cpumask_andnot(&cpumask, mask, &ioapic_max_cpumask);
> +
> +	/* Return error If new irq affinity is out of ioapic_max_cpumask. */
> +	if (!cpumask_empty(&cpumask))
> +		return -EINVAL;
> +
> +	ret = parent->chip->irq_set_affinity(parent, mask, force);
> +	if (ret < 0 || ret == IRQ_SET_MASK_OK_DONE)
> +		return ret;
> +
> +	entry = data->chip_data;
> +	entry->dest = cfg->dest_apicid;
> +	entry->vector = cfg->vector;
> +	send_cleanup_vector(cfg);
> +
> +	return 0;
> +}
> +
> +static struct irq_chip hyperv_ir_chip = {
> +	.name			= "HYPERV-IR",
> +	.irq_ack		= apic_ack_irq,
> +	.irq_set_affinity	= hyperv_ir_set_affinity,
> +};
> +
> +static int hyperv_irq_remapping_alloc(struct irq_domain *domain,
> +				     unsigned int virq, unsigned int nr_irqs,
> +				     void *arg)
> +{
> +	struct irq_alloc_info *info = arg;
> +	struct IO_APIC_route_entry *entry;
> +	struct irq_data *irq_data;
> +	struct irq_desc *desc;
> +	struct irq_cfg *cfg;
> +	int ret = 0;
> +
> +	if (!info || info->type != X86_IRQ_ALLOC_TYPE_IOAPIC || nr_irqs > 1)
> +		return -EINVAL;
> +
> +	ret = irq_domain_alloc_irqs_parent(domain, virq, nr_irqs, arg);
> +	if (ret < 0)
> +		goto fail;
> +
> +	irq_data = irq_domain_get_irq_data(domain, virq);
> +	cfg = irqd_cfg(irq_data);
> +	if (!irq_data || !cfg) {
> +		ret = -EINVAL;
> +		goto fail;
> +	}
> +
> +	irq_data->chip = &hyperv_ir_chip;
> +
> +	/*
> +	 * Save IOAPIC entry pointer here in order to set vector and
> +	 * and dest_apicid in the hyperv_irq_remappng_activate()
> +	 * and hyperv_ir_set_affinity(). IOAPIC driver ignores
> +	 * cfg->dest_apicid and cfg->vector when irq remapping
> +	 * mode is enabled. Detail see ioapic_configure_entry().
> +	 */
> +	irq_data->chip_data = entry = info->ioapic_entry;
> +
> +	/*
> +	 * Hypver-V IO APIC irq affinity should be in the scope of
> +	 * ioapic_max_cpumask because no irq remapping support.
> +	 */
> +	desc = irq_data_to_desc(irq_data);
> +	cpumask_and(desc->irq_common_data.affinity,
> +			desc->irq_common_data.affinity,
> +			&ioapic_max_cpumask);
> +
> + fail:
> +	return ret;
> +}
> +
> +static void hyperv_irq_remapping_free(struct irq_domain *domain,
> +				 unsigned int virq, unsigned int nr_irqs)
> +{
> +	irq_domain_free_irqs_common(domain, virq, nr_irqs);
> +}
> +
> +static int hyperv_irq_remappng_activate(struct irq_domain *domain,
> +			  struct irq_data *irq_data, bool reserve)
> +{
> +	struct irq_cfg *cfg = irqd_cfg(irq_data);
> +	struct IO_APIC_route_entry *entry = irq_data->chip_data;
> +
> +	entry->dest = cfg->dest_apicid;
> +	entry->vector = cfg->vector;
> +
> +	return 0;
> +}
> +
> +static struct irq_domain_ops hyperv_ir_domain_ops = {
> +	.alloc = hyperv_irq_remapping_alloc,
> +	.free = hyperv_irq_remapping_free,
> +	.activate = hyperv_irq_remappng_activate,
> +};
> +
> +static int __init hyperv_prepare_irq_remapping(void)
> +{
> +	struct fwnode_handle *fn;
> +	u32 apic_id;
> +	int i;
> +
> +	if (x86_hyper_type != X86_HYPER_MS_HYPERV ||
> +	    !x2apic_supported())
> +		return -ENODEV;
> +
> +	fn = irq_domain_alloc_named_id_fwnode("HYPERV-IR", 0);
> +	if (!fn)
> +		return -EFAULT;
> +
> +	ioapic_ir_domain =
> +		irq_domain_create_hierarchy(arch_get_ir_parent_domain(),
> +				0, IOAPIC_REMAPPING_ENTRY, fn,
> +				&hyperv_ir_domain_ops, NULL);
> +
> +	irq_domain_free_fwnode(fn);
> +
> +	/*
> +	 * Hyper-V doesn't provide irq remapping function for
> +	 * IO-APIC and so IO-APIC only accepts 8-bit APIC ID.
> +	 * Prepare max cpu affinity for IOAPIC irqs. Scan cpu 0-255
> +	 * and set cpu into ioapic_max_cpumask if its APIC ID is less
> +	 * than 255.
> +	 */
> +	for (i = 0; i < 256; i++) {
> +		apic_id = cpu_physical_id(i);
> +		if (apic_id > 255)
> +			continue;
> +
> +		cpumask_set_cpu(i, &ioapic_max_cpumask);
> +	}
> +
> +	return 0;
> +}
> +
> +static int __init hyperv_enable_irq_remapping(void)
> +{
> +	return IRQ_REMAP_X2APIC_MODE;
> +}
> +
> +static struct irq_domain *hyperv_get_ir_irq_domain(struct irq_alloc_info *info)
> +{
> +	if (info->type == X86_IRQ_ALLOC_TYPE_IOAPIC)
> +		return ioapic_ir_domain;
> +	else
> +		return NULL;
> +}
> +
> +struct irq_remap_ops hyperv_irq_remap_ops = {
> +	.prepare		= hyperv_prepare_irq_remapping,
> +	.enable			= hyperv_enable_irq_remapping,
> +	.get_ir_irq_domain	= hyperv_get_ir_irq_domain,
> +};
> diff --git a/drivers/iommu/irq_remapping.c b/drivers/iommu/irq_remapping.c
> index b94ebd4..81cf290 100644
> --- a/drivers/iommu/irq_remapping.c
> +++ b/drivers/iommu/irq_remapping.c
> @@ -103,6 +103,9 @@ int __init irq_remapping_prepare(void)
>   	else if (IS_ENABLED(CONFIG_AMD_IOMMU) &&
>   		 amd_iommu_irq_ops.prepare() == 0)
>   		remap_ops = &amd_iommu_irq_ops;
> +	else if (IS_ENABLED(CONFIG_HYPERV_IOMMU) &&
> +		 hyperv_irq_remap_ops.prepare() == 0)
> +		remap_ops = &hyperv_irq_remap_ops;
>   	else
>   		return -ENOSYS;
>   
> diff --git a/drivers/iommu/irq_remapping.h b/drivers/iommu/irq_remapping.h
> index 0afef6e..f8609e9 100644
> --- a/drivers/iommu/irq_remapping.h
> +++ b/drivers/iommu/irq_remapping.h
> @@ -64,6 +64,7 @@ struct irq_remap_ops {
>   
>   extern struct irq_remap_ops intel_irq_remap_ops;
>   extern struct irq_remap_ops amd_iommu_irq_ops;
> +extern struct irq_remap_ops hyperv_irq_remap_ops;
>   
>   #else  /* CONFIG_IRQ_REMAP */
>   
> 

Re: [PATCH 2/3] HYPERV/IOMMU: Add Hyper-V stub IOMMU driver

[Tianyu Lan]

Hi Joerg:
             Thanks for your review.

On Sat, Feb 2, 2019 at 12:34 AM Joerg Roedel <joro@8bytes.org> wrote:
>
> Hi,
>
> On Thu, Jan 31, 2019 at 06:17:32PM +0800, lantianyu1986@gmail.com wrote:
> > +config HYPERV_IOMMU
> > +     bool "Hyper-V stub IOMMU support"
>
> This is not a real IOMMU driver, it only implements IRQ remapping
> capabilities. Please change the name to reflect that, e.g. to
> "Hyper-V IRQ Remapping Support" or something like that.

Yes, that makes sense. Will update.

>
> > +static int __init hyperv_prepare_irq_remapping(void)
> > +{
> > +     struct fwnode_handle *fn;
> > +     u32 apic_id;
> > +     int i;
> > +
> > +     if (x86_hyper_type != X86_HYPER_MS_HYPERV ||
> > +         !x2apic_supported())
> > +             return -ENODEV;
> > +
> > +     fn = irq_domain_alloc_named_id_fwnode("HYPERV-IR", 0);
> > +     if (!fn)
> > +             return -EFAULT;
>
> Why does this return -EFAULT? I guess there is no fault happening in
> irq_domain_alloc_named_id_fwnode()...

Yes, “-ENOMEM” should be more accurate.

-- 
Best regards
Tianyu Lan

Re: [PATCH 2/3] HYPERV/IOMMU: Add Hyper-V stub IOMMU driver

[Tianyu Lan]

Hi Sasha:
             Thanks for your review.

On Fri, Feb 1, 2019 at 10:51 PM Sasha Levin <sashal@kernel.org> wrote:
>
> Hi Tianyu,
>
> Few comments below.
>
> On Thu, Jan 31, 2019 at 06:17:32PM +0800, lantianyu1986@gmail.com wrote:
> >From: Lan Tianyu <Tianyu.Lan@microsoft.com>
> >
> >On the bare metal, enabling X2APIC mode requires interrupt remapping
> >function which helps to deliver irq to cpu with 32-bit APIC ID.
> >Hyper-V doesn't provide interrupt remapping function so far and Hyper-V
> >MSI protocol already supports to deliver interrupt to the CPU whose
> >virtual processor index is more than 255. IO-APIC interrupt still has
> >8-bit APIC ID limitation.
> >
> >This patch is to add Hyper-V stub IOMMU driver in order to enable
> >X2APIC mode successfully in Hyper-V Linux guest. The driver returns X2APIC
> >interrupt remapping capability when X2APIC mode is available. Otherwise,
> >it creates a Hyper-V irq domain to limit IO-APIC interrupts' affinity
> >and make sure cpus assigned with IO-APIC interrupt have 8-bit APIC ID.
> >
> >Signed-off-by: Lan Tianyu <Tianyu.Lan@microsoft.com>
> >---
> > drivers/iommu/Kconfig         |   7 ++
> > drivers/iommu/Makefile        |   1 +
> > drivers/iommu/hyperv-iommu.c  | 189 ++++++++++++++++++++++++++++++++++++++++++
> > drivers/iommu/irq_remapping.c |   3 +
> > drivers/iommu/irq_remapping.h |   1 +
> > 5 files changed, 201 insertions(+)
> > create mode 100644 drivers/iommu/hyperv-iommu.c
> >
> >diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> >index 45d7021..5c397c0 100644
> >--- a/drivers/iommu/Kconfig
> >+++ b/drivers/iommu/Kconfig
> >@@ -437,4 +437,11 @@ config QCOM_IOMMU
> >       help
> >         Support for IOMMU on certain Qualcomm SoCs.
> >
> >+config HYPERV_IOMMU
> >+      bool "Hyper-V stub IOMMU support"
> >+      depends on HYPERV
>
>         select IOMMU_API ?

Yes。 will  update.

>
> >+      help
> >+          Hyper-V stub IOMMU driver provides capability to run
> >+          Linux guest with X2APIC mode enabled.
> >+
> > endif # IOMMU_SUPPORT
> >diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
> >index a158a68..8c71a15 100644
> >--- a/drivers/iommu/Makefile
> >+++ b/drivers/iommu/Makefile
> >@@ -32,3 +32,4 @@ obj-$(CONFIG_EXYNOS_IOMMU) += exynos-iommu.o
> > obj-$(CONFIG_FSL_PAMU) += fsl_pamu.o fsl_pamu_domain.o
> > obj-$(CONFIG_S390_IOMMU) += s390-iommu.o
> > obj-$(CONFIG_QCOM_IOMMU) += qcom_iommu.o
> >+obj-$(CONFIG_HYPERV_IOMMU) += hyperv-iommu.o
> >diff --git a/drivers/iommu/hyperv-iommu.c b/drivers/iommu/hyperv-iommu.c
> >new file mode 100644
> >index 0000000..a64b747
> >--- /dev/null
> >+++ b/drivers/iommu/hyperv-iommu.c
> >@@ -0,0 +1,189 @@
> >+// SPDX-License-Identifier: GPL-2.0
> >+
> >+#define pr_fmt(fmt)     "HYPERV-IR: " fmt
> >+
> >+#include <linux/types.h>
> >+#include <linux/interrupt.h>
> >+#include <linux/irq.h>
> >+#include <linux/iommu.h>
> >+#include <linux/module.h>
> >+
> >+#include <asm/hw_irq.h>
> >+#include <asm/io_apic.h>
> >+#include <asm/irq_remapping.h>
> >+#include <asm/hypervisor.h>
> >+
> >+#include "irq_remapping.h"
> >+
> >+/*
> >+ * According IO-APIC spec, IO APIC has a 24-entry Interrupt
> >+ * Redirection Table.
>
> Can the spec be linked somewhere? In the commit message, or here?

Sure. Will update.

>
> >+ */
> >+#define IOAPIC_REMAPPING_ENTRY 24
> >+
> >+static cpumask_t ioapic_max_cpumask = { CPU_BITS_NONE };
> >+struct irq_domain *ioapic_ir_domain;
> >+
> >+static int hyperv_ir_set_affinity(struct irq_data *data,
> >+              const struct cpumask *mask, bool force)
> >+{
> >+      struct irq_data *parent = data->parent_data;
> >+      struct irq_cfg *cfg = irqd_cfg(data);
> >+      struct IO_APIC_route_entry *entry;
> >+      cpumask_t cpumask;
> >+      int ret;
> >+
> >+      cpumask_andnot(&cpumask, mask, &ioapic_max_cpumask);
> >+
> >+      /* Return error If new irq affinity is out of ioapic_max_cpumask. */
> >+      if (!cpumask_empty(&cpumask))
> >+              return -EINVAL;
> >+
> >+      ret = parent->chip->irq_set_affinity(parent, mask, force);
> >+      if (ret < 0 || ret == IRQ_SET_MASK_OK_DONE)
> >+              return ret;
> >+
> >+      entry = data->chip_data;
> >+      entry->dest = cfg->dest_apicid;
> >+      entry->vector = cfg->vector;
> >+      send_cleanup_vector(cfg);
> >+
> >+      return 0;
> >+}
> >+
> >+static struct irq_chip hyperv_ir_chip = {
> >+      .name                   = "HYPERV-IR",
> >+      .irq_ack                = apic_ack_irq,
> >+      .irq_set_affinity       = hyperv_ir_set_affinity,
> >+};
> >+
> >+static int hyperv_irq_remapping_alloc(struct irq_domain *domain,
> >+                                   unsigned int virq, unsigned int nr_irqs,
> >+                                   void *arg)
> >+{
> >+      struct irq_alloc_info *info = arg;
> >+      struct IO_APIC_route_entry *entry;
>
> What's the role of this variable? We set it, once, later on in the
> function but that's all?
>

This one should be removed.

> >+      struct irq_data *irq_data;
> >+      struct irq_desc *desc;
> >+      struct irq_cfg *cfg;
> >+      int ret = 0;
> >+
> >+      if (!info || info->type != X86_IRQ_ALLOC_TYPE_IOAPIC || nr_irqs > 1)
> >+              return -EINVAL;
> >+
> >+      ret = irq_domain_alloc_irqs_parent(domain, virq, nr_irqs, arg);
> >+      if (ret < 0)
> >+              goto fail;
> >+
> >+      irq_data = irq_domain_get_irq_data(domain, virq);
> >+      cfg = irqd_cfg(irq_data);
>
> Is this actually being used anywhere, or do we only need it for the
> check below? It's not clear from the code why we're calling irqd_cfg()
> and ignoring the result.

Sorry. irqd_cfg() should not be needed here.

>
> >+      if (!irq_data || !cfg) {
>
> You just dereferenced irq_data in the line above this one, it's a bit
> late to check that it's not NULL.
>

OK. Will update.

> >+              ret = -EINVAL;
> >+              goto fail;
> >+      }
> >+
> >+      irq_data->chip = &hyperv_ir_chip;
> >+
> >+      /*
> >+       * Save IOAPIC entry pointer here in order to set vector and
> >+       * and dest_apicid in the hyperv_irq_remappng_activate()
> >+       * and hyperv_ir_set_affinity(). IOAPIC driver ignores
> >+       * cfg->dest_apicid and cfg->vector when irq remapping
> >+       * mode is enabled. Detail see ioapic_configure_entry().
> >+       */
> >+      irq_data->chip_data = entry = info->ioapic_entry;
> >+
> >+      /*
> >+       * Hypver-V IO APIC irq affinity should be in the scope of
> >+       * ioapic_max_cpumask because no irq remapping support.
> >+       */
> >+      desc = irq_data_to_desc(irq_data);
> >+      cpumask_and(desc->irq_common_data.affinity,
> >+                      desc->irq_common_data.affinity,
> >+                      &ioapic_max_cpumask);
> >+
> >+ fail:
> >+      return ret;
>
> This one doesn't actually free anything?

irq_domain_free_irqs_common() should be called here. Thanks.

>
> >+}
> >+
> >+static void hyperv_irq_remapping_free(struct irq_domain *domain,
> >+                               unsigned int virq, unsigned int nr_irqs)
> >+{
> >+      irq_domain_free_irqs_common(domain, virq, nr_irqs);
> >+}
> >+
> >+static int hyperv_irq_remappng_activate(struct irq_domain *domain,
> >+                        struct irq_data *irq_data, bool reserve)
> >+{
> >+      struct irq_cfg *cfg = irqd_cfg(irq_data);
> >+      struct IO_APIC_route_entry *entry = irq_data->chip_data;
> >+
> >+      entry->dest = cfg->dest_apicid;
> >+      entry->vector = cfg->vector;
> >+
> >+      return 0;
> >+}
> >+
> >+static struct irq_domain_ops hyperv_ir_domain_ops = {
> >+      .alloc = hyperv_irq_remapping_alloc,
> >+      .free = hyperv_irq_remapping_free,
> >+      .activate = hyperv_irq_remappng_activate,
> >+};
> >+
> >+static int __init hyperv_prepare_irq_remapping(void)
> >+{
> >+      struct fwnode_handle *fn;
> >+      u32 apic_id;
> >+      int i;
> >+
> >+      if (x86_hyper_type != X86_HYPER_MS_HYPERV ||
> >+          !x2apic_supported())
> >+              return -ENODEV;
> >+
> >+      fn = irq_domain_alloc_named_id_fwnode("HYPERV-IR", 0);
> >+      if (!fn)
> >+              return -EFAULT;
>
> Why EFAULT? The only reason irq_domain_alloc_named_id_fwnode() might
> fail is running out of memory.

ENOMEM should be more accurate.

>
> >+
> >+      ioapic_ir_domain =
> >+              irq_domain_create_hierarchy(arch_get_ir_parent_domain(),
> >+                              0, IOAPIC_REMAPPING_ENTRY, fn,
> >+                              &hyperv_ir_domain_ops, NULL);
> >+
> >+      irq_domain_free_fwnode(fn);
> >+
> >+      /*
> >+       * Hyper-V doesn't provide irq remapping function for
> >+       * IO-APIC and so IO-APIC only accepts 8-bit APIC ID.
> >+       * Prepare max cpu affinity for IOAPIC irqs. Scan cpu 0-255
> >+       * and set cpu into ioapic_max_cpumask if its APIC ID is less
> >+       * than 255.
>
> Off-by-one here: it'll set the CPU in the affinity mask if it's less
> than 256, not 255.

Yes. will update.

>
> >+       */
> >+      for (i = 0; i < 256; i++) {
> >+              apic_id = cpu_physical_id(i);
> >+              if (apic_id > 255)
> >+                      continue;
> >+
> >+              cpumask_set_cpu(i, &ioapic_max_cpumask);
> >+      }
>
> I'm curious here: assuming we have a large amount of CPUs, what
> guarantee do we have that this mask will have anything set? What happens
> if it remains empty?

The APIC id of BSP is always 0. The CPU's APIC ID comes from ACPI MADT table.
The APIC ID in the ACPI MADT table will be monotone increasing from Hyper-V
team.

>
> >+
> >+      return 0;
> >+}
> >+
> >+static int __init hyperv_enable_irq_remapping(void)
> >+{
> >+      return IRQ_REMAP_X2APIC_MODE;
> >+}
> >+
> >+static struct irq_domain *hyperv_get_ir_irq_domain(struct irq_alloc_info *info)
> >+{
> >+      if (info->type == X86_IRQ_ALLOC_TYPE_IOAPIC)
> >+              return ioapic_ir_domain;
> >+      else
> >+              return NULL;
> >+}
> >+
> >+struct irq_remap_ops hyperv_irq_remap_ops = {
> >+      .prepare                = hyperv_prepare_irq_remapping,
> >+      .enable                 = hyperv_enable_irq_remapping,
> >+      .get_ir_irq_domain      = hyperv_get_ir_irq_domain,
> >+};
> >diff --git a/drivers/iommu/irq_remapping.c b/drivers/iommu/irq_remapping.c
> >index b94ebd4..81cf290 100644
> >--- a/drivers/iommu/irq_remapping.c
> >+++ b/drivers/iommu/irq_remapping.c
> >@@ -103,6 +103,9 @@ int __init irq_remapping_prepare(void)
> >       else if (IS_ENABLED(CONFIG_AMD_IOMMU) &&
> >                amd_iommu_irq_ops.prepare() == 0)
> >               remap_ops = &amd_iommu_irq_ops;
> >+      else if (IS_ENABLED(CONFIG_HYPERV_IOMMU) &&
> >+               hyperv_irq_remap_ops.prepare() == 0)
> >+              remap_ops = &hyperv_irq_remap_ops;
> >       else
> >               return -ENOSYS;
> >
> >diff --git a/drivers/iommu/irq_remapping.h b/drivers/iommu/irq_remapping.h
> >index 0afef6e..f8609e9 100644
> >--- a/drivers/iommu/irq_remapping.h
> >+++ b/drivers/iommu/irq_remapping.h
> >@@ -64,6 +64,7 @@ struct irq_remap_ops {
> >
> > extern struct irq_remap_ops intel_irq_remap_ops;
> > extern struct irq_remap_ops amd_iommu_irq_ops;
> >+extern struct irq_remap_ops hyperv_irq_remap_ops;
> >
> > #else  /* CONFIG_IRQ_REMAP */
> >
> >--
> >2.7.4
> >



-- 
Best regards
Tianyu Lan

Re: [PATCH 2/3] HYPERV/IOMMU: Add Hyper-V stub IOMMU driver

[Tianyu Lan]

Hi Robin:
           Thanks for your review.

On Sat, Feb 2, 2019 at 1:00 AM Robin Murphy <robin.murphy@arm.com> wrote:
>
> On 31/01/2019 10:17, lantianyu1986@gmail.com wrote:
> > From: Lan Tianyu <Tianyu.Lan@microsoft.com>
> >
> > On the bare metal, enabling X2APIC mode requires interrupt remapping
> > function which helps to deliver irq to cpu with 32-bit APIC ID.
> > Hyper-V doesn't provide interrupt remapping function so far and Hyper-V
> > MSI protocol already supports to deliver interrupt to the CPU whose
> > virtual processor index is more than 255. IO-APIC interrupt still has
> > 8-bit APIC ID limitation.
> >
> > This patch is to add Hyper-V stub IOMMU driver in order to enable
> > X2APIC mode successfully in Hyper-V Linux guest. The driver returns X2APIC
> > interrupt remapping capability when X2APIC mode is available. Otherwise,
> > it creates a Hyper-V irq domain to limit IO-APIC interrupts' affinity
> > and make sure cpus assigned with IO-APIC interrupt have 8-bit APIC ID.
>
> AFAICS this is a Hyper-V IOAPIC driver which neither implements nor even
> touches the IOMMU API, so having it in drivers/iommu rather than, say,
> drivers/irqchip seems a bit of a stretch to me :/
>
> Maybe this could be a good push to clean up and properly factor out the
> x86 IRQ remapping stuff, possibly to live somewhere closer to other IRQ
> layer code? I appreciate it's a bit muddied by the major x86 vendors
> both keeping their DMA virtualisation and IRQ virtualisation
> architectures together under one umbrella "IOMMU" spec, but IIRC the
> fact that intel-iommu supports building for !IOMMU_API already causes us
> a bit of grief.
>
> Of course, I'm coming from a particular not-entirely-objective viewpoint
> where DMA remapping (SMMU) code in drivers/iommu, IRQ remapping (ITS)
> code in drivers/irqchip, and the relevant ACPI table handling (IORT) in
> drivers/acpi is the norm, but even though that largely falls out of a
> less-tightly-coupled system architecture it does seem perfectly logical
> either way.

I think the different between arm and x86 about interrupt remapping is
that interrupt remapping
function is provided by IOMMU on x86 while it's provided by GIC or
other component on ARM.
As part of IOMMU on x86, the irq remapping code should be in the IOMMU
driver. if some thing
wrong, please correct me. Thanks.


>
> Robin.
>
> (who has admittedly been drinking the Cambridge water for many years now...)
>
> > Signed-off-by: Lan Tianyu <Tianyu.Lan@microsoft.com>
> > ---
> >   drivers/iommu/Kconfig         |   7 ++
> >   drivers/iommu/Makefile        |   1 +
> >   drivers/iommu/hyperv-iommu.c  | 189 ++++++++++++++++++++++++++++++++++++++++++
> >   drivers/iommu/irq_remapping.c |   3 +
> >   drivers/iommu/irq_remapping.h |   1 +
> >   5 files changed, 201 insertions(+)
> >   create mode 100644 drivers/iommu/hyperv-iommu.c
> >
> > diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> > index 45d7021..5c397c0 100644
> > --- a/drivers/iommu/Kconfig
> > +++ b/drivers/iommu/Kconfig
> > @@ -437,4 +437,11 @@ config QCOM_IOMMU
> >       help
> >         Support for IOMMU on certain Qualcomm SoCs.
> >
> > +config HYPERV_IOMMU
> > +     bool "Hyper-V stub IOMMU support"
> > +     depends on HYPERV
> > +     help
> > +         Hyper-V stub IOMMU driver provides capability to run
> > +         Linux guest with X2APIC mode enabled.
> > +
> >   endif # IOMMU_SUPPORT
> > diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
> > index a158a68..8c71a15 100644
> > --- a/drivers/iommu/Makefile
> > +++ b/drivers/iommu/Makefile
> > @@ -32,3 +32,4 @@ obj-$(CONFIG_EXYNOS_IOMMU) += exynos-iommu.o
> >   obj-$(CONFIG_FSL_PAMU) += fsl_pamu.o fsl_pamu_domain.o
> >   obj-$(CONFIG_S390_IOMMU) += s390-iommu.o
> >   obj-$(CONFIG_QCOM_IOMMU) += qcom_iommu.o
> > +obj-$(CONFIG_HYPERV_IOMMU) += hyperv-iommu.o
> > diff --git a/drivers/iommu/hyperv-iommu.c b/drivers/iommu/hyperv-iommu.c
> > new file mode 100644
> > index 0000000..a64b747
> > --- /dev/null
> > +++ b/drivers/iommu/hyperv-iommu.c
> > @@ -0,0 +1,189 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +
> > +#define pr_fmt(fmt)     "HYPERV-IR: " fmt
> > +
> > +#include <linux/types.h>
> > +#include <linux/interrupt.h>
> > +#include <linux/irq.h>
> > +#include <linux/iommu.h>
> > +#include <linux/module.h>
> > +
> > +#include <asm/hw_irq.h>
> > +#include <asm/io_apic.h>
> > +#include <asm/irq_remapping.h>
> > +#include <asm/hypervisor.h>
> > +
> > +#include "irq_remapping.h"
> > +
> > +/*
> > + * According IO-APIC spec, IO APIC has a 24-entry Interrupt
> > + * Redirection Table.
> > + */
> > +#define IOAPIC_REMAPPING_ENTRY 24
> > +
> > +static cpumask_t ioapic_max_cpumask = { CPU_BITS_NONE };
> > +struct irq_domain *ioapic_ir_domain;
> > +
> > +static int hyperv_ir_set_affinity(struct irq_data *data,
> > +             const struct cpumask *mask, bool force)
> > +{
> > +     struct irq_data *parent = data->parent_data;
> > +     struct irq_cfg *cfg = irqd_cfg(data);
> > +     struct IO_APIC_route_entry *entry;
> > +     cpumask_t cpumask;
> > +     int ret;
> > +
> > +     cpumask_andnot(&cpumask, mask, &ioapic_max_cpumask);
> > +
> > +     /* Return error If new irq affinity is out of ioapic_max_cpumask. */
> > +     if (!cpumask_empty(&cpumask))
> > +             return -EINVAL;
> > +
> > +     ret = parent->chip->irq_set_affinity(parent, mask, force);
> > +     if (ret < 0 || ret == IRQ_SET_MASK_OK_DONE)
> > +             return ret;
> > +
> > +     entry = data->chip_data;
> > +     entry->dest = cfg->dest_apicid;
> > +     entry->vector = cfg->vector;
> > +     send_cleanup_vector(cfg);
> > +
> > +     return 0;
> > +}
> > +
> > +static struct irq_chip hyperv_ir_chip = {
> > +     .name                   = "HYPERV-IR",
> > +     .irq_ack                = apic_ack_irq,
> > +     .irq_set_affinity       = hyperv_ir_set_affinity,
> > +};
> > +
> > +static int hyperv_irq_remapping_alloc(struct irq_domain *domain,
> > +                                  unsigned int virq, unsigned int nr_irqs,
> > +                                  void *arg)
> > +{
> > +     struct irq_alloc_info *info = arg;
> > +     struct IO_APIC_route_entry *entry;
> > +     struct irq_data *irq_data;
> > +     struct irq_desc *desc;
> > +     struct irq_cfg *cfg;
> > +     int ret = 0;
> > +
> > +     if (!info || info->type != X86_IRQ_ALLOC_TYPE_IOAPIC || nr_irqs > 1)
> > +             return -EINVAL;
> > +
> > +     ret = irq_domain_alloc_irqs_parent(domain, virq, nr_irqs, arg);
> > +     if (ret < 0)
> > +             goto fail;
> > +
> > +     irq_data = irq_domain_get_irq_data(domain, virq);
> > +     cfg = irqd_cfg(irq_data);
> > +     if (!irq_data || !cfg) {
> > +             ret = -EINVAL;
> > +             goto fail;
> > +     }
> > +
> > +     irq_data->chip = &hyperv_ir_chip;
> > +
> > +     /*
> > +      * Save IOAPIC entry pointer here in order to set vector and
> > +      * and dest_apicid in the hyperv_irq_remappng_activate()
> > +      * and hyperv_ir_set_affinity(). IOAPIC driver ignores
> > +      * cfg->dest_apicid and cfg->vector when irq remapping
> > +      * mode is enabled. Detail see ioapic_configure_entry().
> > +      */
> > +     irq_data->chip_data = entry = info->ioapic_entry;
> > +
> > +     /*
> > +      * Hypver-V IO APIC irq affinity should be in the scope of
> > +      * ioapic_max_cpumask because no irq remapping support.
> > +      */
> > +     desc = irq_data_to_desc(irq_data);
> > +     cpumask_and(desc->irq_common_data.affinity,
> > +                     desc->irq_common_data.affinity,
> > +                     &ioapic_max_cpumask);
> > +
> > + fail:
> > +     return ret;
> > +}
> > +
> > +static void hyperv_irq_remapping_free(struct irq_domain *domain,
> > +                              unsigned int virq, unsigned int nr_irqs)
> > +{
> > +     irq_domain_free_irqs_common(domain, virq, nr_irqs);
> > +}
> > +
> > +static int hyperv_irq_remappng_activate(struct irq_domain *domain,
> > +                       struct irq_data *irq_data, bool reserve)
> > +{
> > +     struct irq_cfg *cfg = irqd_cfg(irq_data);
> > +     struct IO_APIC_route_entry *entry = irq_data->chip_data;
> > +
> > +     entry->dest = cfg->dest_apicid;
> > +     entry->vector = cfg->vector;
> > +
> > +     return 0;
> > +}
> > +
> > +static struct irq_domain_ops hyperv_ir_domain_ops = {
> > +     .alloc = hyperv_irq_remapping_alloc,
> > +     .free = hyperv_irq_remapping_free,
> > +     .activate = hyperv_irq_remappng_activate,
> > +};
> > +
> > +static int __init hyperv_prepare_irq_remapping(void)
> > +{
> > +     struct fwnode_handle *fn;
> > +     u32 apic_id;
> > +     int i;
> > +
> > +     if (x86_hyper_type != X86_HYPER_MS_HYPERV ||
> > +         !x2apic_supported())
> > +             return -ENODEV;
> > +
> > +     fn = irq_domain_alloc_named_id_fwnode("HYPERV-IR", 0);
> > +     if (!fn)
> > +             return -EFAULT;
> > +
> > +     ioapic_ir_domain =
> > +             irq_domain_create_hierarchy(arch_get_ir_parent_domain(),
> > +                             0, IOAPIC_REMAPPING_ENTRY, fn,
> > +                             &hyperv_ir_domain_ops, NULL);
> > +
> > +     irq_domain_free_fwnode(fn);
> > +
> > +     /*
> > +      * Hyper-V doesn't provide irq remapping function for
> > +      * IO-APIC and so IO-APIC only accepts 8-bit APIC ID.
> > +      * Prepare max cpu affinity for IOAPIC irqs. Scan cpu 0-255
> > +      * and set cpu into ioapic_max_cpumask if its APIC ID is less
> > +      * than 255.
> > +      */
> > +     for (i = 0; i < 256; i++) {
> > +             apic_id = cpu_physical_id(i);
> > +             if (apic_id > 255)
> > +                     continue;
> > +
> > +             cpumask_set_cpu(i, &ioapic_max_cpumask);
> > +     }
> > +
> > +     return 0;
> > +}
> > +
> > +static int __init hyperv_enable_irq_remapping(void)
> > +{
> > +     return IRQ_REMAP_X2APIC_MODE;
> > +}
> > +
> > +static struct irq_domain *hyperv_get_ir_irq_domain(struct irq_alloc_info *info)
> > +{
> > +     if (info->type == X86_IRQ_ALLOC_TYPE_IOAPIC)
> > +             return ioapic_ir_domain;
> > +     else
> > +             return NULL;
> > +}
> > +
> > +struct irq_remap_ops hyperv_irq_remap_ops = {
> > +     .prepare                = hyperv_prepare_irq_remapping,
> > +     .enable                 = hyperv_enable_irq_remapping,
> > +     .get_ir_irq_domain      = hyperv_get_ir_irq_domain,
> > +};
> > diff --git a/drivers/iommu/irq_remapping.c b/drivers/iommu/irq_remapping.c
> > index b94ebd4..81cf290 100644
> > --- a/drivers/iommu/irq_remapping.c
> > +++ b/drivers/iommu/irq_remapping.c
> > @@ -103,6 +103,9 @@ int __init irq_remapping_prepare(void)
> >       else if (IS_ENABLED(CONFIG_AMD_IOMMU) &&
> >                amd_iommu_irq_ops.prepare() == 0)
> >               remap_ops = &amd_iommu_irq_ops;
> > +     else if (IS_ENABLED(CONFIG_HYPERV_IOMMU) &&
> > +              hyperv_irq_remap_ops.prepare() == 0)
> > +             remap_ops = &hyperv_irq_remap_ops;
> >       else
> >               return -ENOSYS;
> >
> > diff --git a/drivers/iommu/irq_remapping.h b/drivers/iommu/irq_remapping.h
> > index 0afef6e..f8609e9 100644
> > --- a/drivers/iommu/irq_remapping.h
> > +++ b/drivers/iommu/irq_remapping.h
> > @@ -64,6 +64,7 @@ struct irq_remap_ops {
> >
> >   extern struct irq_remap_ops intel_irq_remap_ops;
> >   extern struct irq_remap_ops amd_iommu_irq_ops;
> > +extern struct irq_remap_ops hyperv_irq_remap_ops;
> >
> >   #else  /* CONFIG_IRQ_REMAP */
> >
> >



-- 
Best regards
Tianyu Lan