From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [PATCH v5 03/17] iommu: Add iommu_intpost to control VT-d Posted-Interrupts feature Date: Wed, 12 Aug 2015 11:39:59 -0400 Message-ID: <20150812153959.GC17650@l.oracle.com> References: <1439346938-31824-1-git-send-email-feng.wu@intel.com> <1439346938-31824-4-git-send-email-feng.wu@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <1439346938-31824-4-git-send-email-feng.wu@intel.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Feng Wu Cc: Kevin Tian , Jan Beulich , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org 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 > CC: Kevin Tian > Signed-off-by: Feng Wu > Reviewed-by: Kevin Tian Reviewed-by: Konrad Rzeszutek Wilk > --- > 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@lists.xen.org > http://lists.xen.org/xen-devel