From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: povder <povder@gmail.com>, xen-devel@lists.xen.org
Subject: Re: Xen 4.2.1 boot failure with IOMMU enabled
Date: Thu, 14 Feb 2013 09:55:16 -0500 [thread overview]
Message-ID: <511CFAD4.9040905@oracle.com> (raw)
In-Reply-To: <511CD8C202000078000BE280@nat28.tlf.novell.com>
On 02/14/2013 06:29 AM, Jan Beulich wrote:
>>>> On 13.02.13 at 19:21, povder <povder@gmail.com> wrote:
>> I don't see 06:00.1 device in IOMMU enabling process on which Xen crashes.
>>
>> lspci output: http://pastebin.com/raw.php?i=3wpKPQT9
> This is really odd: The "iommu=debug" output you made available
> shows that while there are further devices that have no associated
> IOMMU, the bus scan done in the hypervisor didn't even find a
> device at 06:00.1. Which I see possible only in two ways: Either
> the device becomes visible on the bus only when the driver for
> 06:00.0 loads (and is otherwise detectable only by other means,
> e.g. ACPI), or 06:00.0 doesn't have the multi function device flag
> properly set. That latter aspect could be checked by looking at
> the raw (hex) config space dump of 06:00.0.
If I read this correctly, Linux enables multi-functionness (?):
http://lxr.linux.no/#linux+v3.7.7/drivers/pci/quirks.c#L1494
So you are probably right. BIOS does not enumerate 06:00.1 in IVRS because
it doesn't see it enabled yet.
>
> Boris, one other thought I had in this context: Is it really possible
> for functions on the same (non-bridge) device to be serviced
> by different IOMMUs?
I can't see how this may be possible: IOMMU is PCIe root complex and any
downstream device can only send transactions through its root. (I hope I am
using right terminology).
> If not, find_iommu_for_device() could simply
> look for function 0 if nothing is known about the passed in function.
Yes, this could work. But with a warning in the log.
-boris
next prev parent reply other threads:[~2013-02-14 14:55 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-12 3:20 Xen 4.2.1 boot failure with IOMMU enabled Boris Ostrovsky
2013-02-12 6:26 ` povder
2013-02-12 10:06 ` Jan Beulich
2013-02-12 10:55 ` povder
2013-02-12 11:03 ` Jan Beulich
2013-02-12 11:15 ` povder
2013-02-12 11:22 ` Jan Beulich
2013-02-12 11:29 ` Jan Beulich
2013-02-12 15:20 ` Boris Ostrovsky
2013-02-12 15:50 ` povder
2013-02-12 16:04 ` Jan Beulich
2013-02-12 17:44 ` povder
2013-02-12 18:23 ` povder
2013-02-12 18:40 ` povder
2013-02-13 8:05 ` Jan Beulich
2013-02-13 8:28 ` povder
2013-02-13 8:37 ` Jan Beulich
2013-02-13 18:21 ` povder
2013-02-14 11:03 ` Jan Beulich
2013-02-14 11:29 ` Jan Beulich
2013-02-14 14:55 ` Boris Ostrovsky [this message]
2013-02-15 8:21 ` Jan Beulich
2013-02-15 15:21 ` Boris Ostrovsky
-- strict thread matches above, loose matches on Subject: below --
2013-02-13 1:33 Boris Ostrovsky
2013-02-13 8:24 ` Jan Beulich
2013-02-11 17:31 povder
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=511CFAD4.9040905@oracle.com \
--to=boris.ostrovsky@oracle.com \
--cc=JBeulich@suse.com \
--cc=povder@gmail.com \
--cc=xen-devel@lists.xen.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.