Re: [Xen-devel] Xen 4.2.1 boot failure with IOMMU enabled

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 14.02.13 at 15:55, Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx> wrote:
> On 02/14/2013 06:29 AM, Jan Beulich wrote:
>>>>> On 13.02.13 at 19:21, povder <povder@xxxxxxxxx> 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.

Indeed, and it has been that way since 2.6.18 (i.e. virtually
forever; commit 15e0c694367332d7e7114c7c73044bc5fed9ee48).

I've got a patch mostly ready to deal with non-zero functions
when we at least know something about function zero.

But I don't think we can easily deal with the single IOMMU
case, making that IOMMU cover all devices, as we would
still need to figure out the requestor ID for each device. That
requires looking at the PCI bus topology iiuc, and while we
have the necessary logic for VT-d, it seems not really strait
forward (mainly because risky) to make use of this in the AMD Vi
code too.

Jan


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