All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: "Han, Weidong" <weidong.han@intel.com>
Cc: "Siddha, Suresh B" <suresh.b.siddha@intel.com>,
	"'dwmw2@infradead.org'" <dwmw2@infradead.org>,
	"'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>,
	"'iommu@lists.linux-foundation.org'" 
	<iommu@lists.linux-foundation.org>,
	"'kvm@vger.kernel.org'" <kvm@vger.kernel.org>
Subject: Re: [PATCH 2/2] Intel-IOMMU, intr-remap: source-id checking
Date: Tue, 19 May 2009 11:32:27 +0200	[thread overview]
Message-ID: <20090519093227.GF31404@elte.hu> (raw)
In-Reply-To: <715D42877B251141A38726ABF5CABF2C054568FA16@pdsmsx503.ccr.corp.intel.com>


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

> Ingo Molnar wrote:
> > * Han, Weidong <weidong.han@intel.com> wrote:
> > 
> >> Siddha, Suresh B wrote:
> >>> On Wed, 2009-05-06 at 23:16 -0700, Han, Weidong wrote:
> >>>> @@ -634,6 +694,44 @@ static int ir_parse_ioapic_scope(struct
> >>>>  			       acpi_dmar_header *header, " 0x%Lx\n",
> >>>>  			       scope->enumeration_id, drhd->address);
> >>>> 
> >>>> +			bus = pci_find_bus(drhd->segment, scope->bus);
> >>>> +			path = (struct acpi_dmar_pci_path *)(scope + 1); +			count =
> >>>> (scope->length - +				 sizeof(struct acpi_dmar_device_scope))
> >>>> +				/ sizeof(struct acpi_dmar_pci_path);
> >>>> +
> >>>> +			while (count) {
> >>>> +				if (pdev)
> >>>> +					pci_dev_put(pdev);
> >>>> +
> >>>> +				if (!bus)
> >>>> +					break;
> >>>> +
> >>>> +				pdev = pci_get_slot(bus,
> >>>> +					PCI_DEVFN(path->dev, path->fn));
> >>>> +				if (!pdev)
> >>>> +					break;
> >>> 
> >>> ir_parse_ioapic_scope() happens very early in the boot. So, I
> >>> don't think we can do the pci related discovery here.
> >>> 
> >> 
> >> Thanks for your pointing it out. It should enable the source-id
> >> checking for io-apic's after the pci subsystem is up. I will
> >> change it.
> > 
> > Note, there's ways to do early PCI quirks too, check
> > arch/x86/kernel/early-quirks.c. It's done by reading the PCI
> > configuration space directly via a careful early-capable subset of
> > the PCI config space APIs.
> > 
> > But it's a method of last resort.
> > 
> 
> Thanks for your reminder. It can use direct PCI access here as follows. It's easy and clean. I think it's better than adding the source-id checking for io-apic's after the pci subsystem is up. I will send out updated patches after some tests.
>  
> @@ -634,6 +695,24 @@ static int ir_parse_ioapic_scope(struct acpi_dmar_header *header,
>                                " 0x%Lx\n", scope->enumeration_id,
>                                drhd->address);
> 
> +                       bus = scope->bus;
> +                       path = (struct acpi_dmar_pci_path *)(scope + 1);
> +                       count = (scope->length -
> +                                sizeof(struct acpi_dmar_device_scope))
> +                               / sizeof(struct acpi_dmar_pci_path);
> +
> +                       while (--count > 0) {
> +                               /* Access PCI directly due to the PCI
> +                                * subsystem isn't initialized yet.
> +                                */
> +                               bus = read_pci_config_byte(bus, path->dev,
> +                                       path->fn, PCI_SECONDARY_BUS);
> +                               path++;
> +                       }
> +
> +                       ir_ioapic[ir_ioapic_num].bus = bus;
> +                       ir_ioapic[ir_ioapic_num].devfn =
> +                                       PCI_DEVFN(path->dev, path->fn);

looks good IMO, beyond the obligatory comment-style nitpick [*] :-) 
Also, the function above seems to be way too large - please split it 
into a couple of natural helper functions.

Thanks,

	Ingo

[*]

Please use the customary comment style:

  /*
   * Comment .....
   * ...... goes here:
   */

specified in Documentation/CodingStyle.




  reply	other threads:[~2009-05-19  9:32 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-07  6:16 [PATCH 1/2] Intel-IOMMU, intr-remap: set the whole 128bits of irte when modify/free it Weidong Han
2009-05-07  6:16 ` [PATCH 2/2] Intel-IOMMU, intr-remap: source-id checking Weidong Han
2009-05-07 18:19   ` Suresh Siddha
2009-05-11  6:22     ` Han, Weidong
2009-05-11 13:20       ` Ingo Molnar
2009-05-18  9:46         ` Han, Weidong
2009-05-18  9:46           ` Han, Weidong
2009-05-19  9:32           ` Ingo Molnar [this message]
2009-05-19  9:32             ` Ingo Molnar
2009-05-19 10:34             ` Han, Weidong
2009-05-19 10:34               ` 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=20090519093227.GF31404@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.