[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v5 03/17] iommu: Add iommu_intpost to control VT-d Posted-Interrupts feature



On Wed, Aug 12, 2015 at 10:35:24AM +0800, Feng Wu wrote:
> VT-d Posted-Interrupts is an enhancement to CPU side Posted-Interrupt.
> With VT-d Posted-Interrupts enabled, external interrupts from
> direct-assigned devices can be delivered to guests without VMM
> intervention when guest is running in non-root mode.
> 
> This patch adds variable 'iommu_intpost' to control whether enable VT-d
> posted-interrupt or not in the generic IOMMU code.
> 
> CC: Jan Beulich <jbeulich@xxxxxxxx>
> CC: Kevin Tian <kevin.tian@xxxxxxxxx>
> Signed-off-by: Feng Wu <feng.wu@xxxxxxxxx>
> Reviewed-by: Kevin Tian <kevin.tian@xxxxxxxxx>

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
> ---
> v5:
> - Remove the "if no intremap then no intpost" logic in parse_iommu_param(), 
> which
>   can be covered in iommu_setup()
> 
> v3:
> - Remove pointless initializer for 'iommu_intpost'.
> - Some adjustment for "if no intremap then no intpost" logic.
>     * For parse_iommu_param(), move it to the end of the function,
>       so we don't need to add the some logic when introduing the
>       new kernel parameter 'intpost' in later patch.
>     * Add this logic in iommu_setup() after iommu_hardware_setup()
>       is called.
> 
>  xen/drivers/passthrough/iommu.c | 13 ++++++++++++-
>  xen/include/xen/iommu.h         |  2 +-
>  2 files changed, 13 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
> index 11d58cc..8eb77f7 100644
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -50,6 +50,14 @@ bool_t __read_mostly iommu_passthrough;
>  bool_t __read_mostly iommu_snoop = 1;
>  bool_t __read_mostly iommu_qinval = 1;
>  bool_t __read_mostly iommu_intremap = 1;
> +
> +/*
> + * In the current implementation of VT-d posted interrupts, in some extreme
> + * cases, the per cpu list which saves the blocked vCPU will be very long,
> + * and this will affect the interrupt latency, so let this feature off by
> + * default until we find a good solution to resolve it.
> + */
> +bool_t __read_mostly iommu_intpost;
>  bool_t __read_mostly iommu_hap_pt_share = 1;
>  bool_t __read_mostly iommu_debug;
>  bool_t __read_mostly amd_iommu_perdev_intremap = 1;
> @@ -304,6 +312,9 @@ int __init iommu_setup(void)
>          panic("Couldn't enable %s and iommu=required/force",
>                !iommu_enabled ? "IOMMU" : "Interrupt Remapping");
>  
> +    if ( !iommu_intremap )
> +        iommu_intpost = 0;
> +
>      if ( !iommu_enabled )
>      {
>          iommu_snoop = 0;
> @@ -371,7 +382,7 @@ void iommu_crash_shutdown(void)
>      const struct iommu_ops *ops = iommu_get_ops();
>      if ( iommu_enabled )
>          ops->crash_shutdown();
> -    iommu_enabled = iommu_intremap = 0;
> +    iommu_enabled = iommu_intremap = iommu_intpost = 0;
>  }
>  
>  int iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
> diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
> index 705969b..da326a1 100644
> --- a/xen/include/xen/iommu.h
> +++ b/xen/include/xen/iommu.h
> @@ -30,7 +30,7 @@
>  extern bool_t iommu_enable, iommu_enabled;
>  extern bool_t force_iommu, iommu_verbose;
>  extern bool_t iommu_workaround_bios_bug, iommu_passthrough;
> -extern bool_t iommu_snoop, iommu_qinval, iommu_intremap;
> +extern bool_t iommu_snoop, iommu_qinval, iommu_intremap, iommu_intpost;
>  extern bool_t iommu_hap_pt_share;
>  extern bool_t iommu_debug;
>  extern bool_t amd_iommu_perdev_intremap;
> -- 
> 2.1.0
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.