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

RE: [Xen-devel] XCI: can we get to the demo state?



Yeah, these occur when the iommu context for the device in question (in this 
case your iGfx card) has been torn down but the card is still active (still 
attempting DMA). The code in xen to perform an function level resets (FLR) on 
the devices takes care of the vast majority of these but there still remain one 
or two that occur even thought the FLR has been done. This issue was never 
resolved but these few remaining faults don't seem to cause a problem. So you 
are experiencing a hang as the vm starts I take it. Is the vtd fault trace the 
last thing you see? Are you passing anything else through?

Thanks
Ross

-----Original Message-----
From: Vincent Hanquez 
Sent: Friday, August 14, 2009 7:05 AM
To: Phung Te Ha
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; Ross Philipson; Kamala Narasimhan
Subject: Re: [Xen-devel] XCI: can we get to the demo state?

Phung Te Ha wrote:
> Hi Vincent,
>
> I tried your suggestion, adding pci = 0,bind,0000:00:02.0 in the config
> on 2 different machines, the HP6930 and on an Intel MB DQ35OJ.
>
> On both machines, I got the samething, the guest run as shown by 
> xenops list_domains:
>
>  id |  state |    cpu_time |                                 uuid
>  0 |     R  | 54203470658 | 00000000-0000-0000-0000-000000000000
>  1 |    B H | 12214238864 | 00000000-0000-0000-0000-000000000002
>
> But nothing shows on the screen.
>
> I checked the logs and found in xenops dmesg:
>
> ...
> (XEN) Intel VT-d Snoop Control not supported.
> (XEN) Intel VT-d DMA Passthrough not supported.
> (XEN) Intel VT-d Queued Invalidation not supported.
> (XEN) Intel VT-d Interrupt Remapping not supported.
> (XEN) I/O virtualisation enabled
> (XEN) I/O virtualisation for PV guests disabled
>
>
> And when the guest is started:
>
> ...
>  _fault:DMA Write: 0:2.0 addr faddf7000 REASON 5 iommu->reg = 
> ffff828bfff56000
> (XEN) print_vtd_entries: iommu = ffff83007dcfb320 bdf = 0:2:0 gmfn = 
> faddf7
> (XEN)     root_entry = ffff83007e0ce000
> (XEN)     root_entry[0] = 7e066001
> (XEN)     context = ffff83007e066000
> (XEN)     context[10] = 201_7da02001
> (XEN)     l3 = ffff83007da02000
> (XEN)     l3_index = 3e
> (XEN)     l3[3e] = 0
> (XEN)     l3[3e] not present
> (XEN) [VT-D]iommu.c:722: iommu_page_fault: iommu->reg = ffff828bfff56000
> (XEN) [VT-D]iommu.c:691: iommu_fault_status: Fault Overflow
> (XEN) [VT-D]iommu.c:694: iommu_fault_status: Primary Pending Fault
> (XEN) [VT-D]iommu.c:676: iommu_fault:DMA Write: 0:2.0 addr faddf7000 
> REASON 5 iommu->reg = ffff828bfff56000
> (XEN) print_vtd_entries: iommu = ffff83007dcfb320 bdf = 0:2:0 gmfn = 
> faddf7
> (XEN)     root_entry = ffff83007e0ce000
> (XEN)     root_entry[0] = 7e066001
> (XEN)     context = ffff83007e066000
> ...
>
> Do you think these 2 machines have enough of VT-d features to get the 
> graphics passed-through?
> Do you have a preferred desktop board, known to work for graphisc 
> passed-through?
I'm not really familiar with thoses VT-d errors. Kamala/Ross do you have 
any idea, what this previous errors means ?

thanks,
-- 
Vincent

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


 


Rackspace

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