[PATCH] drivers: iommu: hyperv: Make HYPERV_IOMMU only available on x86

2019-10-16 Thread Boqun Feng
Currently hyperv-iommu is implemented in a x86 specific way, for
example, apic is used. So make the HYPERV_IOMMU Kconfig depend on X86
as a preparation for enabling HyperV on architecture other than x86.

Cc: Lan Tianyu 
Cc: Michael Kelley 
Cc: linux-hyp...@vger.kernel.org
Signed-off-by: Boqun Feng (Microsoft) 
---

Without this patch, I could observe compile error:

| drivers/iommu/hyperv-iommu.c:17:10: fatal error: asm/apic.h: No such
| file or directory
|   17 | #include 
|  |  ^~~~

, after apply Michael's ARM64 on HyperV enablement patchset.

 drivers/iommu/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index e3842eabcfdd..f1086eaed41c 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -467,7 +467,7 @@ config QCOM_IOMMU
 
 config HYPERV_IOMMU
bool "Hyper-V x2APIC IRQ Handling"
-   depends on HYPERV
+   depends on HYPERV && X86
select IOMMU_API
default HYPERV
help
-- 
2.23.0



Re: [patch V2 00/46] x86, PCI, XEN, genirq ...: Prepare for device MSI

2020-09-01 Thread Boqun Feng
Hi Thomas,

On Wed, Aug 26, 2020 at 01:16:28PM +0200, Thomas Gleixner wrote:
[...]
> 
> The whole lot is also available from git:
> 
>git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git device-msi
> 
> This has been tested on Intel/AMD/KVM but lacks testing on:
> 
> - HYPERV (-ENODEV)

FWIW, I did a build and boot test in a hyperv guest with your
development branch, the latest commit is 71cbf478eb6f ("irqchip: Add
IMS (Interrupt Message Storm) driver - NOT FOR MERGING"). And everything
seemed working fine.

If you want me to set/unset a particular CONFIG option or run some
command for testing purposes, please let me know ;-)

Regards,
Bqoun

> - VMD enabled systems (-ENODEV)
> - XEN (-ENOCLUE)
> - IMS (-ENODEV)
> 
> - Any non-X86 code which might depend on the broken compose MSI message
>   logic. Marc excpects not much fallout, but agrees that we need to fix
>   it anyway.
> 
> #1 - #3 should be applied unconditionally for obvious reasons
> #4 - #6 are wortwhile cleanups which should be done independent of device MSI
> 
> #7 - #8 look promising to cleanup the platform MSI implementation
>   independent of #8, but I neither had cycles nor the stomach to
>   tackle that.
> 
> #9is obviously just for the folks interested in IMS
> 
> Thanks,
> 
>   tglx
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [patch RFC 10/38] x86/ioapic: Consolidate IOAPIC allocation

2020-08-26 Thread Boqun Feng
Hi Thomas,

I hit a compiler error while I was trying to compile this patchset:

arch/x86/kernel/devicetree.c: In function ‘dt_irqdomain_alloc’:
arch/x86/kernel/devicetree.c:232:6: error: ‘struct irq_alloc_info’ has no 
member named ‘ioapic_id’; did you mean ‘ioapic’?
  232 |  tmp.ioapic_id = mpc_ioapic_id(mp_irqdomain_ioapic_idx(domain));
  |  ^
  |  ioapic
arch/x86/kernel/devicetree.c:233:6: error: ‘struct irq_alloc_info’ has no 
member named ‘ioapic_pin’; did you mean ‘ioapic’?
  233 |  tmp.ioapic_pin = fwspec->param[0]
  |  ^~
  |  ioapic

with CONFIG_OF=y. IIUC, the following changes are needed to fold into
this patch. (At least I can continue to compile the kernel with this
change)

diff --git a/arch/x86/kernel/devicetree.c b/arch/x86/kernel/devicetree.c
index a0e8fc7d85f1..ddffd80f5c52 100644
--- a/arch/x86/kernel/devicetree.c
+++ b/arch/x86/kernel/devicetree.c
@@ -229,8 +229,8 @@ static int dt_irqdomain_alloc(struct irq_domain *domain, 
unsigned int virq,
 
it = _ioapic_type[type_index];
ioapic_set_alloc_attr(, NUMA_NO_NODE, it->trigger, it->polarity);
-   tmp.ioapic_id = mpc_ioapic_id(mp_irqdomain_ioapic_idx(domain));
-   tmp.ioapic_pin = fwspec->param[0];
+   tmp.devid = mpc_ioapic_id(mp_irqdomain_ioapic_idx(domain));
+   tmp.ioapic.pin = fwspec->param[0];
 
return mp_irqdomain_alloc(domain, virq, nr_irqs, );
 }

Regards,
Boqun

On Fri, Aug 21, 2020 at 02:24:34AM +0200, Thomas Gleixner wrote:
> Move the IOAPIC specific fields into their own struct and reuse the common
> devid. Get rid of the #ifdeffery as it does not matter at all whether the
> alloc info is a couple of bytes longer or not.
> 
> Signed-off-by: Thomas Gleixner 
> Cc: Wei Liu 
> Cc: "K. Y. Srinivasan" 
> Cc: Stephen Hemminger 
> Cc: Joerg Roedel 
> Cc: linux-hyp...@vger.kernel.org
> Cc: iommu@lists.linux-foundation.org
> Cc: Haiyang Zhang 
> Cc: Jon Derrick 
> Cc: Lu Baolu 
> ---
>  arch/x86/include/asm/hw_irq.h   |   23 ++-
>  arch/x86/kernel/apic/io_apic.c  |   70 
> ++--
>  drivers/iommu/amd/iommu.c   |   14 +++
>  drivers/iommu/hyperv-iommu.c|2 -
>  drivers/iommu/intel/irq_remapping.c |   18 -
>  5 files changed, 64 insertions(+), 63 deletions(-)
> 
> --- a/arch/x86/include/asm/hw_irq.h
> +++ b/arch/x86/include/asm/hw_irq.h
> @@ -44,6 +44,15 @@ enum irq_alloc_type {
>   X86_IRQ_ALLOC_TYPE_HPET_GET_PARENT,
>  };
>  
> +struct ioapic_alloc_info {
> + int pin;
> + int node;
> + u32 trigger : 1;
> + u32 polarity : 1;
> + u32 valid : 1;
> + struct IO_APIC_route_entry  *entry;
> +};
> +
>  /**
>   * irq_alloc_info - X86 specific interrupt allocation info
>   * @type:X86 specific allocation type
> @@ -53,6 +62,8 @@ enum irq_alloc_type {
>   * @mask:CPU mask for vector allocation
>   * @desc:Pointer to msi descriptor
>   * @data:Allocation specific data
> + *
> + * @ioapic:  IOAPIC specific allocation data
>   */
>  struct irq_alloc_info {
>   enum irq_alloc_type type;
> @@ -64,6 +75,7 @@ struct irq_alloc_info {
>   void*data;
>  
>   union {
> + struct ioapic_alloc_infoioapic;
>   int unused;
>  #ifdef   CONFIG_PCI_MSI
>   struct {
> @@ -71,17 +83,6 @@ struct irq_alloc_info {
>   irq_hw_number_t msi_hwirq;
>   };
>  #endif
> -#ifdef   CONFIG_X86_IO_APIC
> - struct {
> - int ioapic_id;
> - int ioapic_pin;
> - int ioapic_node;
> - u32 ioapic_trigger : 1;
> - u32 ioapic_polarity : 1;
> - u32 ioapic_valid : 1;
> - struct IO_APIC_route_entry *ioapic_entry;
> - };
> -#endif
>  #ifdef   CONFIG_DMAR_TABLE
>   struct {
>   int dmar_id;
> --- a/arch/x86/kernel/apic/io_apic.c
> +++ b/arch/x86/kernel/apic/io_apic.c
> @@ -860,10 +860,10 @@ void ioapic_set_alloc_attr(struct irq_al
>  {
>   init_irq_alloc_info(info, NULL);
>   info->type = X86_IRQ_ALLOC_TYPE_IOAPIC;
> - info->ioapic_node = node;
> - info->ioapic_trigger = trigger;
> - info->ioapic_polarity = polarity;
> - info->ioapic_valid = 1;
> + info->ioapic.node = node;
> + info->ioapic.trigger = trigger;
> + info->ioapic.polarity = polarity;
> + info->ioapic.valid = 1;
>  }
>  
>  #ifndef CONFIG_ACPI
> @@ -878,32 +878,32 @@ static void ioapic_copy_alloc_attr(struc
>  
>   copy_irq_alloc_info(dst, src);
>   dst->type = X86_IRQ_ALLOC_TYPE_IOAPIC;
> - dst->ioapic_id = 

Re: [PATCH v2 2/2] PCI: hv: Propagate coherence from VMbus device to PCI device

2022-03-23 Thread Boqun Feng
On Wed, Mar 23, 2022 at 01:31:12PM -0700, Michael Kelley wrote:
> PCI pass-thru devices in a Hyper-V VM are represented as a VMBus
> device and as a PCI device.  The coherence of the VMbus device is
> set based on the VMbus node in ACPI, but the PCI device has no
> ACPI node and defaults to not hardware coherent.  This results
> in extra software coherence management overhead on ARM64 when
> devices are hardware coherent.
> 
> Fix this by setting up the PCI host bus so that normal
> PCI mechanisms will propagate the coherence of the VMbus
> device to the PCI device. There's no effect on x86/x64 where
> devices are always hardware coherent.
> 
> Signed-off-by: Michael Kelley 

Acked-by: Boqun Feng 

Regards,
Boqun

> ---
>  drivers/pci/controller/pci-hyperv.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/pci/controller/pci-hyperv.c 
> b/drivers/pci/controller/pci-hyperv.c
> index ae0bc2f..88b3b56 100644
> --- a/drivers/pci/controller/pci-hyperv.c
> +++ b/drivers/pci/controller/pci-hyperv.c
> @@ -3404,6 +3404,15 @@ static int hv_pci_probe(struct hv_device *hdev,
>   hbus->bridge->domain_nr = dom;
>  #ifdef CONFIG_X86
>   hbus->sysdata.domain = dom;
> +#elif defined(CONFIG_ARM64)
> + /*
> +  * Set the PCI bus parent to be the corresponding VMbus
> +  * device. Then the VMbus device will be assigned as the
> +  * ACPI companion in pcibios_root_bridge_prepare() and
> +  * pci_dma_configure() will propagate device coherence
> +  * information to devices created on the bus.
> +  */
> + hbus->sysdata.parent = hdev->device.parent;
>  #endif
>  
>   hbus->hdev = hdev;
> -- 
> 1.8.3.1
> 
> 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu