All of lore.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: "Han\, Weidong" <weidong.han@intel.com>
Cc: "'Ingo Molnar'" <mingo@elte.hu>,
	"'Yinghai Lu'" <yinghai@kernel.org>,
	"'Joerg Roedel'" <joerg.roedel@amd.com>,
	"'dwmw2\@infradead.org'" <dwmw2@infradead.org>, "Siddha\,
	Suresh B" <suresh.b.siddha@intel.com>,
	"'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 v2 2/2] Intel-IOMMU, intr-remap: source-id checking
Date: Thu, 21 May 2009 03:04:11 -0700	[thread overview]
Message-ID: <m1octmvkkk.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <715D42877B251141A38726ABF5CABF2C0545690223@pdsmsx503.ccr.corp.intel.com> (Weidong Han's message of "Thu\, 21 May 2009 17\:00\:34 +0800")

"Han, Weidong" <weidong.han@intel.com> writes:

> Ingo Molnar wrote:
>> * Eric W. Biederman <ebiederm@xmission.com> wrote:
>> 
>>> Not finding an upstream pcie_bridge and then concluding we are a
>>> pcie device seems bogus. 
>>> 
>
> If device is pcie, pci_find_upstream_pcie_bridge() will return
> NULL. For root complex integrated device, it won't find upstream
> bridge, and also return NULL. What's more, pcie device and root
> complex integrated device will be handled as the same way to set
> sid, so I mix them here. But it also returns NULL for busted
> hardware. I think no parent bus can be considered Root Complex
> integrated device, right? If so, I think can handle it as follows:

I have problems with pci_find_upstream_pcie_bridge.  The
name is actively misleading about what that function does.
Returning a pci_to_pci bridge is strongly counter intuitive
give that name.

Can we change it to pci_find_upstream_pcie_to_pci_bridge.
Returning NULL in all cases when there is not an upstream
pcie_to_pci bridge.

For the set_sid case that is ideal.  For the other cases in
intel-iommu.c it may be a problem.  Is it even possible to have a
genuine pci device not behind a pcie to pci bridge on an intel
chipset with this iommu?


> 	...
> 	if (dev->is_pcie || !dev->bus->parent) {
> 		set_irte_sid(...);
> 		return 0;
> 	}
>
> 	bridge = pci_find_upstream_pcie_bridge(dev);
> 	if (bridge) {
> 		if (bridge->is_pcie) /* PCIE-to-PCI/PCIx bridge */
> 			set_irte_sid(...);
> 		else /* legacy PCI bridge */
> 			set_irte_sid(..);
> 	}
>
> 	return 0;
>
>>> Why if we do have an upstream pcie bridge do we only want to do a
>>> bus range verification instead of checking just for the bus
>>>> devfn?
>>> 
>>> The legacy PCI case seems even stranger.
>
> Why? If a PCI device isn't connected to a PCIe bridge, it should be a legacy bridge.

I am not deep in the IOV specification at the moment.  I am mostly
wondering why we pick the parts we pick to verify.  I recall
bus and devfn being on the pcie packets so that makes sense.

Why would we ever want to do something different?  Does a pcie to pci
bridge do something different in it's translation?

Eric

  reply	other threads:[~2009-05-21 10:04 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
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 [this message]
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=m1octmvkkk.fsf@fess.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=dwmw2@infradead.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joerg.roedel@amd.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=suresh.b.siddha@intel.com \
    --cc=weidong.han@intel.com \
    --cc=yinghai@kernel.org \
    /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.