[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] VTd - PCI Passthrough - VMError: fail to assign device


  • To: "Stefan Bauer" <stefan.bauer@xxxxxxxxxxx>
  • From: "Todd Deshane" <deshantm@xxxxxxxxx>
  • Date: Sat, 25 Oct 2008 14:26:41 -0400
  • Cc: "xen-users@xxxxxxxxxxxxxxxxxxx >> xen-users" <xen-users@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Sat, 25 Oct 2008 11:27:28 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:cc:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:references; b=CVI5HvRTm1fo/6h7wvt1dBerRmzhNUwDib2eXX/TwrpC5HsMyfyzi/5i3h7CL0lvb0 dhjOKmLz8fbfVwrR6JRJ7wGGiB+RYTidhXjwNubXQVXEaRKUVPZ9KarvoNVWxfiUdgnj WuE+Zgnhf6J2vULyBu1Bt7NY0S1l9KKXzz3cQ=
  • List-id: Xen user discussion <xen-users.lists.xensource.com>

Some questions and comments inline.


On Sat, Oct 25, 2008 at 12:09 PM, Stefan Bauer <stefan.bauer@xxxxxxxxxxx> wrote:
> Debian Etch 2.6.18.8-xen from xensource.com with Xen 3.3.0 on AMD64:

> VmError: fail to assign device(1:0.0): maybe it has already been
> assigned to other domain, or maybe it doesn't exist.
<snip>
>  File "//usr/lib64/python/xen/xend/XendDomainInfo.py", line 2103, in
> _constructDomain
>    raise VmError("fail to assign device(%x:%x.%x): maybe it has"
> VmError: fail to assign device(1:0.0): maybe it has already been
> assigned to other domain, or maybe it doesn't exist.
>


> I want to passthrough a PCI-E graphiccard to a windows 2000 hvm-guest:
> 01:00.0 is the correct pci-id from lspci output:
>

This type of thing should work.

> After the pci device is hidden, lspci doesnt show it anymore as expected.
>

This is actually not expected, or at least I don't usually see it that way.

Here are some things to check.

look in /sys/bus/pci/drivers/pciback to see if it has the 01:00.0 device.

Also notice this error in your output
<snip>
> (XEN) I/O virtualisation enabled
> (XEN) I/O virtualisation for PV guests disabled
> (XEN) [VT-D]iommu.c:775: iommu_page_fault: iommu->reg = ffff828bfff57000
> (XEN) [VT-D]iommu.c:744: iommu_fault_status: Fault Overflow
> (XEN) [VT-D]iommu.c:729: iommu_fault:DMA Write: 0:2.0 addr 200200000
> REASON 5 iommu->reg = ffff828bfff57000
> (XEN) print_vtd_entries: iommu = ffff8300bd6ad180 bdf = 0:2:0 gmfn =
> 200200
> (XEN)     root_entry = ffff8300bc9e0000
> (XEN)     root_entry[0] = b9cd6001
> (XEN)     context = ffff8300b9cd6000
> (XEN)     context[10] = 101_be4a6001
> (XEN)     l3 = ffff8300be4a6000
> (XEN)     l3_index = 8
> (XEN)     l3[8] = 0
> (XEN)     l3[8] not present
<snip>
> (XEN) domctl.c:635:d0 XEN_DOMCTL_test_assign_device: 1:0:0 already
> assigned, or non-existent
> (XEN) domctl.c:635:d0 XEN_DOMCTL_test_assign_device: 1:0:0 already
> assigned, or non-existent


I would suggest, trying xen-unstable and if these errors still exist, maybe
there is a bug.

Did you boot back into normal linux (without the hiding) to see that the
device comes back?

As I mentioned above, I would expect the lspci to show it in both cases.

Hope that helps with some troubleshooting steps.

Cheers,
Todd

-- 
Todd Deshane
http://todddeshane.net
http://runningxen.com

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.