Re: [Xen-devel] [PATCH v5 11/17] vt-d: Add API to update IRTE when VT-d PI is used

2015-08-13 Thread Konrad Rzeszutek Wilk
On Thu, Aug 13, 2015 at 02:33:03AM -0600, Jan Beulich wrote:
> >>> On 12.08.15 at 18:23,  wrote:
> > On Wed, Aug 12, 2015 at 10:35:32AM +0800, Feng Wu wrote:
> >> +GET_IREMAP_ENTRY(ir_ctrl->iremap_maddr, remap_index, iremap_entries, 
> >> p);
> >> +
> >> +old_ire = new_ire = *p;
> >> +
> >> +/* Setup/Update interrupt remapping table entry. */
> >> +setup_posted_irte(&new_ire, pi_desc, gvec);
> >> +ret = cmpxchg16b(p, &old_ire, &new_ire);
> >> +
> >> +ASSERT(ret == *(__uint128_t *)&old_ire);
> >> +
> >> +iommu_flush_cache_entry(p, sizeof(*p));
> > 
> > The other use sites of iommu_flush_cache_entry are sizeof(struct 
> > iremap_entry).
> > I think if you are doing this modification - then you should also have an
> > patch to modify the other code to be in sync.
> > 
> > Or just use the sizeof(struct ...).
> 
> I asked for this (to avoid proliferation of the bad style); I
> certainly wouldn't mind another cleanup patch to deal with the
> other use sites, but I certainly don't want to see this go back
> to sizeof(struct ...).

Aah, I missed that!

Thank you.
> 
> Jan
> 

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


Re: [Xen-devel] [PATCH v5 11/17] vt-d: Add API to update IRTE when VT-d PI is used

2015-08-13 Thread Jan Beulich
>>> On 12.08.15 at 18:23,  wrote:
> On Wed, Aug 12, 2015 at 10:35:32AM +0800, Feng Wu wrote:
>> +GET_IREMAP_ENTRY(ir_ctrl->iremap_maddr, remap_index, iremap_entries, p);
>> +
>> +old_ire = new_ire = *p;
>> +
>> +/* Setup/Update interrupt remapping table entry. */
>> +setup_posted_irte(&new_ire, pi_desc, gvec);
>> +ret = cmpxchg16b(p, &old_ire, &new_ire);
>> +
>> +ASSERT(ret == *(__uint128_t *)&old_ire);
>> +
>> +iommu_flush_cache_entry(p, sizeof(*p));
> 
> The other use sites of iommu_flush_cache_entry are sizeof(struct 
> iremap_entry).
> I think if you are doing this modification - then you should also have an
> patch to modify the other code to be in sync.
> 
> Or just use the sizeof(struct ...).

I asked for this (to avoid proliferation of the bad style); I
certainly wouldn't mind another cleanup patch to deal with the
other use sites, but I certainly don't want to see this go back
to sizeof(struct ...).

Jan


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


Re: [Xen-devel] [PATCH v5 11/17] vt-d: Add API to update IRTE when VT-d PI is used

2015-08-12 Thread Wu, Feng


> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Thursday, August 13, 2015 1:41 AM
> To: Wu, Feng; xen-devel@lists.xen.org
> Cc: Zhang, Yang Z; Tian, Kevin; Keir Fraser; Jan Beulich
> Subject: Re: [PATCH v5 11/17] vt-d: Add API to update IRTE when VT-d PI is 
> used
> 
> On 12/08/15 03:35, Feng Wu wrote:
> > +GET_IREMAP_ENTRY(ir_ctrl->iremap_maddr, remap_index,
> iremap_entries, p);
> > +
> > +old_ire = new_ire = *p;
> > +
> > +/* Setup/Update interrupt remapping table entry. */
> > +setup_posted_irte(&new_ire, pi_desc, gvec);
> > +ret = cmpxchg16b(p, &old_ire, &new_ire);
> > +
> > +ASSERT(ret == *(__uint128_t *)&old_ire);
> 
> You have still not addressed my issues from earlier series.  This
> ASSERT() is buggy until you have a clear, detailed description of why it
> is claimed to be safe in this instance.

Sure, I am add a description here in the next version! Thanks again!

Thanks,
Feng

> 
> ~Andrew

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


Re: [Xen-devel] [PATCH v5 11/17] vt-d: Add API to update IRTE when VT-d PI is used

2015-08-12 Thread Andrew Cooper
On 12/08/15 03:35, Feng Wu wrote:
> +GET_IREMAP_ENTRY(ir_ctrl->iremap_maddr, remap_index, iremap_entries, p);
> +
> +old_ire = new_ire = *p;
> +
> +/* Setup/Update interrupt remapping table entry. */
> +setup_posted_irte(&new_ire, pi_desc, gvec);
> +ret = cmpxchg16b(p, &old_ire, &new_ire);
> +
> +ASSERT(ret == *(__uint128_t *)&old_ire);

You have still not addressed my issues from earlier series.  This
ASSERT() is buggy until you have a clear, detailed description of why it
is claimed to be safe in this instance.

~Andrew

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


Re: [Xen-devel] [PATCH v5 11/17] vt-d: Add API to update IRTE when VT-d PI is used

2015-08-12 Thread Konrad Rzeszutek Wilk
On Wed, Aug 12, 2015 at 10:35:32AM +0800, Feng Wu wrote:
> This patch adds an API which is used to update the IRTE
> for posted-interrupt when guest changes MSI/MSI-X information.
> 
> CC: Yang Zhang 
> CC: Kevin Tian 
> CC: Keir Fraser 
> CC: Jan Beulich 
> CC: Andrew Cooper 
> Signed-off-by: Feng Wu 
> Acked-by: Kevin Tian 
> ---
> v5:
> - Make some function parameters const
> - Call "spin_unlock_irq(&desc->lock);" a little eariler
> - Add "ASSERT(spin_is_locked(&pcidevs_lock))"
> - -EBADSLT -> -ENODEV, EBADSLT is removed in the lasted Xen
> 
> v4:
> - Don't inline setup_posted_irte()
> - const struct pi_desc *pi_desc for setup_posted_irte()
> - return -EINVAL when pirq_spin_lock_irq_desc() fails.
> - Make some variables const
> - Release irq desc lock earlier in pi_update_irte()
> - Remove the pointless do-while() loop when doing cmpxchg16b()
> 
> v3:
> - Remove "adding PDA_MASK()" when updating 'pda_l' and 'pda_h' for IRTE.
> - Change the return type of pi_update_irte() to int.
> - Remove some pointless printk message in pi_update_irte().
> - Use structure assignment instead of memcpy() for irte copy.
> 
>  xen/drivers/passthrough/vtd/intremap.c | 112 
> +
>  xen/drivers/passthrough/vtd/iommu.h|   2 +
>  xen/include/asm-x86/iommu.h|   2 +
>  3 files changed, 116 insertions(+)
> 
> diff --git a/xen/drivers/passthrough/vtd/intremap.c 
> b/xen/drivers/passthrough/vtd/intremap.c
> index e9fffa6..8ec85d3 100644
> --- a/xen/drivers/passthrough/vtd/intremap.c
> +++ b/xen/drivers/passthrough/vtd/intremap.c
> @@ -899,3 +899,115 @@ void iommu_disable_x2apic_IR(void)
>  for_each_drhd_unit ( drhd )
>  disable_qinval(drhd->iommu);
>  }
> +
> +static void setup_posted_irte(

space before '{]'

> +struct iremap_entry *new_ire,
> +const struct pi_desc *pi_desc,
> +const uint8_t gvec)

Not sure why but your parameters are on their own line? Shouldnt at least one
be with the function name - and then the rest on the same offset?

> +{
> +new_ire->post.urg = 0;
> +new_ire->post.vector = gvec;
> +new_ire->post.pda_l = virt_to_maddr(pi_desc) >> (32 - PDA_LOW_BIT);
> +new_ire->post.pda_h = virt_to_maddr(pi_desc) >> 32;
> +
> +new_ire->post.res_1 = 0;
> +new_ire->post.res_2 = 0;
> +new_ire->post.res_3 = 0;
> +new_ire->post.res_4 = 0;
> +new_ire->post.res_5 = 0;
> +
> +new_ire->post.im = 1;
> +}
> +
> +/*
> + * This function is used to update the IRTE for posted-interrupt
> + * when guest changes MSI/MSI-X information.
> + */
> +int pi_update_irte(
> +const struct vcpu *v,
> +const struct pirq *pirq,
> +const uint8_t gvec)

Ditto - perhaps move these to be right after the function name?

> +{
> +struct irq_desc *desc;
> +const struct msi_desc *msi_desc;
> +int remap_index;
> +int rc = 0;
> +const struct pci_dev *pci_dev;
> +const struct acpi_drhd_unit *drhd;
> +struct iommu *iommu;
> +struct ir_ctrl *ir_ctrl;
> +struct iremap_entry *iremap_entries = NULL, *p = NULL;
> +struct iremap_entry new_ire, old_ire;
> +const struct pi_desc *pi_desc = &v->arch.hvm_vmx.pi_desc;
> +__uint128_t ret;
> +
> +desc = pirq_spin_lock_irq_desc(pirq, NULL);
> +if ( !desc )
> +return -EINVAL;
> +
> +msi_desc = desc->msi_desc;
> +if ( !msi_desc )
> +{
> +rc = -ENODEV;
> +goto unlock_out;
> +}
> +
> +pci_dev = msi_desc->dev;
> +if ( !pci_dev )
> +{
> +rc = -ENODEV;
> +goto unlock_out;
> +}
> +
> +remap_index = msi_desc->remap_index;
> +
> +spin_unlock_irq(&desc->lock);
> +
> +ASSERT(spin_is_locked(&pcidevs_lock));
> +
> +/*
> + * For performance concern, we will store the 'iommu' pointer in
> + * 'struct msi_desc' in some other place, so we don't need to waste
> + * time searching it here. I will fix this later.
> + */
> +drhd = acpi_find_matched_drhd_unit(pci_dev);
> +if ( !drhd )
> +{
> +rc = -ENODEV;
> +goto unlock_out;

But you already unlocked desc->lock (so doing unlock_out would do a second
spin unlock)? Should this be an return -ENODEV?

> +}
> +
> +iommu = drhd->iommu;
> +ir_ctrl = iommu_ir_ctrl(iommu);
> +if ( !ir_ctrl )
> +{
> +rc = -ENODEV;
> +goto unlock_out;

Ditto.

> +}
> +
> +spin_lock_irq(&ir_ctrl->iremap_lock);
> +
> +GET_IREMAP_ENTRY(ir_ctrl->iremap_maddr, remap_index, iremap_entries, p);
> +
> +old_ire = new_ire = *p;
> +
> +/* Setup/Update interrupt remapping table entry. */
> +setup_posted_irte(&new_ire, pi_desc, gvec);
> +ret = cmpxchg16b(p, &old_ire, &new_ire);
> +
> +ASSERT(ret == *(__uint128_t *)&old_ire);
> +
> +iommu_flush_cache_entry(p, sizeof(*p));

The other use sites of iommu_flush_cache_entry are sizeof(struct iremap_entry).
I think if you are doing this modification - then you should also have an
patch to modify the other code to be in sync