linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Weidong Han <weidong.han@intel.com>
Cc: dwmw2@infradead.org, suresh.b.siddha@intel.com,
	linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org,
	kvm@vger.kernel.org
Subject: Re: [PATCH v2 1/2] Intel-IOMMU, intr-remap: set the whole 128bits of irte when modify/free it
Date: Tue, 19 May 2009 14:14:13 +0200	[thread overview]
Message-ID: <20090519121413.GC14305@elte.hu> (raw)
In-Reply-To: <1242757912-6041-2-git-send-email-weidong.han@intel.com>


* Weidong Han <weidong.han@intel.com> wrote:

> Interrupt remapping table entry is 128bits. Currently, it only sets low
> 64bits of irte in modify_irte and free_irte. This ignores high 64bits
> setting of irte, that means source-id setting will be ignored. This patch
> sets the whole 128bits of irte when modify/free it. Following source-id
> checking patch depends on this.
> 
> Signed-off-by: Weidong Han <weidong.han@intel.com>
> ---
>  drivers/pci/intr_remapping.c |   10 +++++++---
>  1 files changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/pci/intr_remapping.c b/drivers/pci/intr_remapping.c
> index f5e0ea7..946e170 100644
> --- a/drivers/pci/intr_remapping.c
> +++ b/drivers/pci/intr_remapping.c
> @@ -309,7 +309,8 @@ int modify_irte(int irq, struct irte *irte_modified)
>  	index = irq_iommu->irte_index + irq_iommu->sub_handle;
>  	irte = &iommu->ir_table->base[index];
>  
> -	set_64bit((unsigned long *)irte, irte_modified->low);
> +	set_64bit((unsigned long *)&irte->low, irte_modified->low);
> +	set_64bit((unsigned long *)&irte->high, irte_modified->high);
>
>  	__iommu_flush_cache(iommu, irte, sizeof(*irte));
>  
>  	rc = qi_flush_iec(iommu, index, 0);
> @@ -386,8 +387,11 @@ int free_irte(int irq)
>  	irte = &iommu->ir_table->base[index];
>  
>  	if (!irq_iommu->sub_handle) {
> -		for (i = 0; i < (1 << irq_iommu->irte_mask); i++)
> -			set_64bit((unsigned long *)(irte + i), 0);
> +		for (i = 0; i < (1 << irq_iommu->irte_mask); i++) {
> +			set_64bit((unsigned long *)&irte->low, 0);
> +			set_64bit((unsigned long *)&irte->high, 0);
> +			irte++;
> +		}

The loop is a bit unclean. It has a side-effect on 'irte' - and 
other patterns in the driver usually treat 'irte' as a generally 
available variable.

So the above code, while correct, opens up the possibility of later 
code added to this function relying on 'irte', thinking that it's 
set to "&iommu->ir_table->base[index]", and then breaking because 
'irte' has been iterated to the end of it in certain circumstances.

It's better to factor out the whole loop into a helper function, 
which does something like:

int flush_entries(struct irq_2_iommu *irq_iommu)
{
	struct irte *start, *entry, *end;
	struct intel_iommu *iommu;
	int index;

 	if (irq_iommu->sub_handle)
		return 0;

	iommu = irq_iommu->iommu;
	index = irq_iommu->irte_index + irq_iommu->sub_handle;

	start = iommu->ir_table->base + index;
	end = start + (1 << irq_iommu->irte_mask);

	for (entry = start; entry < end; entry++) {
		set_64bit((unsigned long *)&entry->low,  0);
		set_64bit((unsigned long *)&entry->high, 0);
	}

	return qi_flush_iec(iommu, index, irq_iommu->irte_mask);
}

Note how clearer this is - the new method has one purpose and 
'entry' is a clear iterator.

( And note how much clearer the flow of 'rc' has become as well as a 
  side-effect: it is clear now that it's set to 0 when 
  irq_iommu->sub_handle is still present. )

Thanks,

	Ingo

  reply	other threads:[~2009-05-19 12:14 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-19 18:31 [PATCH v2 0/2] Intel-IOMMU: source-id checking for interrupt remapping Weidong Han
2009-05-19 18:31 ` [PATCH v2 1/2] Intel-IOMMU, intr-remap: set the whole 128bits of irte when modify/free it Weidong Han
2009-05-19 12:14   ` Ingo Molnar [this message]
2009-05-19 14:15     ` Han, Weidong
2009-05-19 18:31 ` [PATCH v2 2/2] Intel-IOMMU, intr-remap: source-id checking Weidong Han
2009-05-19 11:50   ` Ingo Molnar
2009-05-19 14:12     ` Han, Weidong
2009-05-19 19:28     ` Eric W. Biederman
2009-05-20  8:21       ` Ingo Molnar
2009-05-20  8:38         ` Han, Weidong
2009-05-20 12:13           ` Eric W. Biederman
2009-05-20  9:43         ` Joerg Roedel
2009-05-20 12:02           ` Eric W. Biederman
2009-05-20 12:24         ` Eric W. Biederman
2009-05-21  9:00         ` Han, Weidong
2009-05-21 10:04           ` Eric W. Biederman
2009-05-21 13:37             ` Han, Weidong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090519121413.GC14305@elte.hu \
    --to=mingo@elte.hu \
    --cc=dwmw2@infradead.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=suresh.b.siddha@intel.com \
    --cc=weidong.han@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).