> (XEN) [VT-D]iommu.c:824: iommu_fault_status: Primary
Pending Fault
> (XEN) [VT-D]iommu.c:799: DMAR:[DMA Write] Request device
[07:00.0]
> fault addr c00000, iommu reg =
ffff82c3fff57000
The driver gets the physical addr 0xc0049c thru
kernel function virt_to_phys() and set the dma address of Tachyon chip with this
address. This address translation is also involved with SWIOTLB library. Is
there any issue related with SWIOTLB in pvops kernel ?
-Ray
-----Original Message-----
From: Konrad Rzeszutek Wilk
[mailto:konrad.wilk@xxxxxxxxxx]
Sent:
Tuesday, September 28, 2010 9:19 AM
To: Lin, Ray; JBeulich@xxxxxxxxxx
Cc:
Bruce Edge; Jiang, Yunhong; xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re:
[Xen-devel] pv-ops domU not working with MSI interrupts on Nehalem
On
Tue, Sep 28, 2010 at 10:08:57AM -0600, Lin, Ray
wrote:
> I just checked the "xen dmesg". Look like
DMA/iommu is the root cause of this issue. In order to tell the source of
interrupt, Tachyon chip needs to do the DMA write to a dword memory location to
indicate the source of interrupt. What iommu option do you recommend to use
?
Lets get Jan involved in this discussion.
Jan, would some of
your patches that inhibit the MSI write affect this in a PV
guest?
>
> (XEN) [VT-D]iommu.c:824: iommu_fault_status: Primary
Pending Fault
> (XEN) [VT-D]iommu.c:799: DMAR:[DMA Write] Request device
[07:00.0]
> fault addr c00000, iommu reg = ffff82c3fff57000
> (XEN)
DMAR:[fault reason 05h] PTE Write access is not set
> (XEN)
print_vtd_entries: iommu = ffff83019fffa370 bdf = 7:0.0 gmfn = c00
>
(XEN) root_entry = ffff83019ff70000
>
(XEN) root_entry[7] = 19cf52001
>
(XEN) context = ffff83019cf52000
>
(XEN) context[0] = 102_706dc005
>
(XEN) l4 = ffff8300706dc000
>
(XEN) l4_index = 0
> (XEN)
l4[0] = 706db003
> (XEN) l3 =
ffff8300706db000
> (XEN) l3_index = 0
>
(XEN) l3[0] = 706da003
>
(XEN) l2 = ffff8300706da000
>
(XEN) l2_index = 6
> (XEN)
l2[6] = 0
>
>
> -Ray
>
>
>
________________________________
> From:
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx]
On Behalf Of Bruce Edge
> Sent: Monday, September 27, 2010 9:46 PM
>
To: Jiang, Yunhong
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; Konrad Rzeszutek
Wilk
> Subject: Re: [Xen-devel] pv-ops domU not working with MSI
interrupts
> on Nehalem
>
> On Mon, Sep 27, 2010 at 8:26 PM,
Jiang, Yunhong <yunhong.jiang@xxxxxxxxx<mailto:yunhong.jiang@xxxxxxxxx>>
wrote:
> "xm dmesg" should gives xen's boot log, and sometimes it contain
some helpful information, I think, especially loglvl and guest_loglvl is set to
all.
>
> I looked at the xm dmesg output and there's nothing more
than what I already provided, aside from a bunch of commands from me poking at
it.
>
> -Bruce
>
>
> Thanks
>
--jyh
>
> From: Bruce Edge
> [mailto:bruce.edge@xxxxxxxxx<mailto:bruce.edge@xxxxxxxxx>]
>
Sent: Tuesday, September 28, 2010 11:16 AM
> To: Jiang, Yunhong
>
Cc: Konrad Rzeszutek Wilk;
> xen-devel@xxxxxxxxxxxxxxxxxxx<mailto:xen-devel@xxxxxxxxxxxxxxxxxxx>
>
>
Subject: Re: [Xen-devel] pv-ops domU not working with MSI interrupts
> on
Nehalem
>
> On Mon, Sep 27, 2010 at 6:15 PM, Jiang, Yunhong
<yunhong.jiang@xxxxxxxxx<mailto:yunhong.jiang@xxxxxxxxx>>
wrote:
> Is the 07:0.0 your tachyon device? The VT-d fault is
suspcious.
>
> Yes, there is 1 quad port card is this
sytem:
>
> 07:00.0 Fibre Channel: PMC-Sierra Inc. Device 8032 (rev
08)
> 07:00.1 Fibre Channel: PMC-Sierra Inc. Device 8032 (rev 08)
>
07:00.2 Fibre Channel: PMC-Sierra Inc. Device 8032 (rev 08)
> 07:00.3
Fibre Channel: PMC-Sierra Inc. Device 8032 (rev 08)
>
>
> Also
is it possible to share the xen output?
>
> I attached the dom0 boot
output. Let me know if you wanted something else.
>
> Also, here's
the dom0 console output upon starting the VM: This lockdep error started with
the release of 2.6.32.21. Note that I'm running the same kernel for the
domU and dom0.
>
> [ 1817.684097] ------------[ cut here
]------------ [ 1817.684113]
> WARNING: at kernel/lockdep.c:2323
>
trace_hardirqs_on_caller+0x12f/0x190()
> [ 1817.684119] Hardware name:
ProLiant DL380 G6 [ 1817.684122] Modules
> linked in: xt_physdev ipv6
osa_mfgdom0 xenfs xen_gntdev fbcon tileblit
> font bitblit softcursor
xen_evtchn xen_pciback radeon ttm
> drm_kms_helper tun drm i2c_algo_bit
ipmi_si i2c_core ipmi_msghandler joydev serio_raw hpwdt hpilo bridge stp llc
usbhid hid cciss usb_storage [ 1817.684190] Pid: 11, comm: xenwatch Not tainted
2.6.32.21-xenoprof-1 #1 [ 1817.684195] Call Trace:
> [ 1817.684197]
<IRQ> [<ffffffff810aa18f>] ?
>
trace_hardirqs_on_caller+0x12f/0x190
> [ 1817.684209]
[<ffffffff8106bed0>] warn_slowpath_common+0x80/0xd0 [
>
1817.684217] [<ffffffff815f2b80>] ? _spin_unlock_irq+0x30/0x40
[
> 1817.684223] [<ffffffff8106bf34>]
warn_slowpath_null+0x14/0x20 [
> 1817.684229]
[<ffffffff810aa18f>]
> trace_hardirqs_on_caller+0x12f/0x190
>
[ 1817.684234] [<ffffffff810aa1fd>] trace_hardirqs_on+0xd/0x10
[
> 1817.684240] [<ffffffff815f2b80>]
_spin_unlock_irq+0x30/0x40 [
> 1817.684266]
[<ffffffff813c4fc5>]
>
add_to_net_schedule_list_tail+0x85/0xd0
> [ 1817.684271]
[<ffffffff813c6216>] netif_be_int+0x36/0x160 [
> 1817.684278]
[<ffffffff810e10d0>] handle_IRQ_event+0x70/0x180 [
>
1817.684284] [<ffffffff810e36e9>] handle_edge_irq+0xc9/0x170
[
> 1817.684291] [<ffffffff813b8d7f>]
__xen_evtchn_do_upcall+0x1bf/0x1f0
> [ 1817.684297]
[<ffffffff813b92fd>] xen_evtchn_do_upcall+0x3d/0x60 [
>
1817.684304] [<ffffffff8101647e>]
>
xen_do_hypervisor_callback+0x1e/0x30
> [ 1817.684308]
<EOI> [<ffffffff8100940a>] ?
>
hypercall_page+0x40a/0x1010 [ 1817.684319] [<ffffffff8100940a>]
?
> hypercall_page+0x40a/0x1010 [ 1817.684325]
[<ffffffff813bce54>] ?
> xb_write+0x1e4/0x290 [ 1817.684330]
[<ffffffff813bd8ca>] ?
> xs_talkv+0x6a/0x1f0 [ 1817.684336]
[<ffffffff813bd8d8>] ?
> xs_talkv+0x78/0x1f0 [ 1817.684341]
[<ffffffff813bdbcd>] ?
> xs_single+0x4d/0x60 [ 1817.684346]
[<ffffffff813be502>] ?
> xenbus_read+0x52/0x80 [ 1817.684352]
[<ffffffff813c87fc>] ?
> frontend_changed+0x48c/0x770 [
1817.684358] [<ffffffff813bf76d>] ?
>
xenbus_otherend_changed+0xdd/0x1b0
> [ 1817.684365]
[<ffffffff8101122f>] ?
> xen_restore_fl_direct_end+0x0/0x1 [
1817.684371] [<ffffffff810ac830>]
> ? lock_release+0xb0/0x230
[ 1817.684376] [<ffffffff813bfae0>] ?
>
frontend_changed+0x10/0x20 [ 1817.684382] [<ffffffff813bd4f5>]
?
> xenwatch_thread+0x55/0x160 [ 1817.684389]
[<ffffffff81093400>] ?
> autoremove_wake_function+0x0/0x40 [
1817.684394] [<ffffffff813bd4a0>]
> ?
xenwatch_thread+0x0/0x160 [ 1817.684400] [<ffffffff81093086>]
?
> kthread+0x96/0xb0 [ 1817.684405] [<ffffffff8101632a>]
?
> child_rip+0xa/0x20 [ 1817.684410] [<ffffffff81015c90>]
?
> restore_args+0x0/0x30 [ 1817.684415] [<ffffffff81016320>]
?
> child_rip+0x0/0x20
>
>
-Bruce
>
>
>
> Thanks
> --jyh
>
>
>-----Original Message-----
> >From:
>
>xen-devel-bounces@xxxxxxxxxxxxxxxxxxx<mailto:xen-devel-bounces@lists.
>
>xensource.com>
> >[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx<mailto:xen-devel-bounce
>
>s@xxxxxxxxxxxxxxxxxxx>] On Behalf Of Bruce Edge
> >Sent:
Tuesday, September 28, 2010 7:54 AM
> >To: Konrad Rzeszutek
Wilk
> >Cc:
> >xen-devel@xxxxxxxxxxxxxxxxxxx<mailto:xen-devel@xxxxxxxxxxxxxxxxxxx>
>
>Subject: Re: [Xen-devel] pv-ops domU not working with MSI interrupts
>
>on Nehalem
> >
> >On Mon, Sep 27, 2010 at 12:54 PM, Konrad
Rzeszutek Wilk
> ><konrad.wilk@xxxxxxxxxx<mailto:konrad.wilk@xxxxxxxxxx>>
wrote:
> >> On Mon, Sep 27, 2010 at 12:16:50PM -0700, Bruce Edge
wrote:
> >>> On Mon, Sep 27, 2010 at 10:24 AM, Konrad Rzeszutek
Wilk
> >>> <konrad.wilk@xxxxxxxxxx<mailto:konrad.wilk@xxxxxxxxxx>>
wrote:
> >>> >
> >>> > On Mon, Sep 27, 2010
at 08:52:39AM -0700, Bruce Edge wrote:
> >>> > > One of our
developers who is working on a tachyon driver is
> >>> > >
complaining that the pvops domU kernel is not working for
> >>>
> > these MSI interrupts.
> >>> > > This is using the
current head of xen/2.6.32.x on both a
> >>> > > single
Nahelam 920 and a dual E5540. This behavior is
> >>> > >
consistent with Xen 4.0.1, 4.0.2.rc1-pre and 4.1.
> >>> >
>
> >>> > > Here are his comments:
> >>>
> >
> >>> > > - the driver has no problem to enable
msi interrupt and
> >>> > > request the interrupt through
kernel functions pci_enable_msi
> >>> > > &
request_irq
> >>> >
> >>> > What shows up in
the Xen console when you send the 'q' key? Does
> >>> > it
show that the vector is assigned to the appropiate guest?
>
>>>
> >>> The Xen console q key shows that the domU is
assigned:
> >>>
> >>>
(XEN) Interrupts { 32, 41-42, 47 }
>
>>
> >> Aha!
> >>
> >>>
>
>>> but the domU thinks it has:
> >>>
>
>>> 124/125/126/127
> >>>
> >>> Is there
some mapping that's taking place, or is this plain wrong?
>
>>
> >> That looks wrong. The IRQ numbers (even though they
are MSI
> >> vectors) are setup as IRQ numbers in the DomU guest.
You should
> >> have seen
> >>
> >>
32:
> >> 41:
> >> 42:
> >> 47:
>
>> in you /proc/interrupts on your DomU guest.
> >>
>
>> I wonder what broke - can you use
>
>git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git<http://g
>
>it.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git>
> >>
devel/xen-pcifront-0.5 (or pv/pcifront-2.6.32)?
> >
> >Please
forgive the git ignorance.
> >
> >Is this the right
syntax?
> >
> >git clone
>
>git://git.kernel.org/pub/scm/linux/kernel/git/konrad:pv/pcifront-2.6.
>
>32<http://git.kernel.org/pub/scm/linux/kernel/git/konrad:pv/pcifront-
>
>2.6.32>
> >linux-2.6.32-pv-pcifront
> >
>
>Initialized empty Git repository in
>
>/import/kaan/bedge/src/xen/kernel/pv-ops/linux-2.6.32-pv-pcifront/.gi
>
>t/
> >fatal: The remote end hung up unexpectedly
>
>
> >Or:
> >
> > git clone
> >
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git<http://
>
> git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git>
>
>
> >Initialized empty Git repository in
>
>/import/kaan/bedge/src/xen/kernel/pv-ops/xen/.git/
> >remote:
error: Could not read
>
>59eab2f8f04147c5aadc99f2034ca7e5b81e890f
> >remote: fatal: Failed
to traverse parents of commit
>
>979e121cb348add17ed8171bf447b27a3a9d1be3
> >remote: aborting due to
possible repository corruption on the remote side.
> >fatal: early
EOF
> >fatal: index-pack failed
> >
> >>
>
>> It has the latest pcifront driver but without the PVonHVM
>
>> enhancments so we can try to eliminate the PvONHVM logic out of the
picture.
> >>
> >>>
> >>> >
>
>>> > > - the interrupt does happen. But the interrupt service
routine
> >>> > > of tachyon driver doesn't detect any
interrupt status related
> >>> > > to this interrupt, which
inhibits the tachyon chip from coming
> >>> > > on-line.
And there are high count of tachyon interrupt in
> >>> > >
/proc/interrupts
> >>> >
> >>> > Is it
checking the PCI_STATUS_INTERRUPT or the appropiate
> >>> >
register in the MMIO BAR?
> >>> >
> >>>
>
>>> The driver would check the appropriate register (tachyon
>
>>> registers) in the MMIO to determine the source of
interrupts.
> >>
> >> OK, so that isn't it. Is there
anything at these vectors:
> >> 7c, 7d, 7e, and 7f? When you use xen
debug-keys 'i' or 'q' it
> >> should give you an inkling what device
this is set for.
> >
> >When I run a distro kernel in hvm
mode, I get the expected irq mappings:
> >
> >'i' - Note 66 -
69
> >(XEN) IRQ: 66
affinity:ffffffff,ffffffff,ffffffff,ffffffff vec:3a
>
>type=PCI-MSI status=00000010
in-flight=0
> >domain-list=10:127(----),
>
>(XEN) IRQ: 67
affinity:ffffffff,ffffffff,ffffffff,ffffffff vec:42
>
>type=PCI-MSI status=00000010
in-flight=0
> >domain-list=10:126(----),
>
>(XEN) IRQ: 68
affinity:ffffffff,ffffffff,ffffffff,ffffffff vec:4a
>
>type=PCI-MSI status=00000010
in-flight=0
> >domain-list=10:125(----),
>
>(XEN) IRQ: 69
affinity:ffffffff,ffffffff,ffffffff,ffffffff vec:52
>
>type=PCI-MSI status=00000010
in-flight=0
> >domain-list=10:124(----)
> >
>
>
> >'q'
> >(XEN) Interrupts { 32,
41-42, 47, 124-127 }
> >
> >
> >The same data with
pv-ops kernel shows:
> >
> >'i'
> >IRQ numbers stop
at 65, no 66 - 69 present:
> >
> >(XEN)
IRQ: 63 affinity:ffffffff,ffffffff,ffffffff,ffffffff vec:91
>
>type=PCI-MSI status=00000010
in-flight=0
> >domain-list=0:289(----),
>
>(XEN) IRQ: 64
affinity:ffffffff,ffffffff,ffffffff,ffffffff vec:99
>
>type=PCI-MSI status=00000002
mapped, unbound
> >(XEN) IRQ: 65
affinity:ffffffff,ffffffff,ffffffff,ffffffff vec:b1
>
>type=PCI-MSI status=00000010
in-flight=0
> >domain-list=0:287(----),
> >(XEN) IO-APIC
interrupt information:
> >
> >'q'
>
>(XEN) Interrupts { 32, 41-42, 47 }
>
>
> >>
> >>>
> >>> >
>
> >>> > > kaan-18-dpm:~# cat /proc/interrupts | grep
TACH
> >>> > >
> >124:
760415
0
0
0 0
>
> 0
> >>> >
>
0
0
0
0 0
>
> 0
> >>> >
>
0 0
xen-pirq-pcifront-msi HW_TACHYON
> >>> > >
>
>125:
762234
0
0
0 0
>
> 0
> >>> >
>
0
0
0
0 0
>
> 0
> >>> >
>
0 0
xen-pirq-pcifront-msi HW_TACHYON
> >>> > >
>
>126:
764180
0
0
0 0
>
> 0
> >>> >
>
0
0
0
0 0
>
> 0
> >>> >
>
0 0
xen-pirq-pcifront-msi HW_TACHYON
> >>> > >
>
>127:
764164
0
0
0 0
>
> 0
> >>> >
>
0
0
0
0 0
>
> 0
> >>> >
>
0 0
xen-pirq-pcifront-msi HW_TACHYON
> >>> >
>
>>> > Can you provide the full dmesg output?
>
>>>
> >>> Attached.
> >>>
>
>>> Some possibly related messages on dom0 console:
>
>>>
> >>> [ 1882.269778] pciback 0000:07:00.0: enabling
device (0000 ->
> >>> 0003) [ 1882.269800] xen: registering
gsi 32 triggering 0 polarity
> >>> 1 [ 1882.269827]
xen_allocate_pirq: returning irq 32 for gsi 32 [
> >>>
1882.269834] xen: --> irq=32 [ 1882.269841] Already setup the GSI
>
>>> :32 [ 1882.269847] pciback 0000:07:00.0: PCI INT A -> GSI
32
> >>> (level, low) -> IRQ 32 [ 1882.269866] pciback
0000:07:00.0:
> >>> setting latency timer to 64 [ 1882.270463]
pciback 0000:07:00.0:
> >>> Driver tried to write to a read-only
configuration space field at
> >>> offset 0x62, size 2. This may
be harmless, but if you have
> >>> problems with your
device:
> >>
> >> Uhhh, for that I think you need to do
'lspci -vvv -xxx -s 07:00.00'
> >> to find out what is at the
configuration space. You could enable it
> >> using the permissive
attribute.
> >>
> >>> [ 1882.270465] 1) see
permissive attribute in sysfs [ 1882.270467]
> >>> 2) report
problems to the xen-devel mailing list along with
> >>> details
of your device obtained from lspci.
> >>> [
1882.270615] alloc irq_desc for 478 on node 0
> >>> [
1882.270625] alloc kstat_irqs on node 0
> >>
>
>> So for 478: what do you see? xen-pciback I presume?
>
>>> [ 1882.348411] pciback 0000:07:00.1: enabling device (0000
->
> >>> 0003) [ 1882.348433] xen: registering gsi 42
triggering 0 polarity
> >>> 1 [ 1882.348440] xen_allocate_pirq:
returning irq 42 for gsi 42 [
> >>> 1882.348445] xen: -->
irq=42 [ 1882.348472] Already setup the GSI
> >>> :42 [
1882.348479] pciback 0000:07:00.1: PCI INT B -> GSI 42
> >>>
(level, low) -> IRQ 42 [ 1882.348497] pciback 0000:07:00.1:
>
>>> setting latency timer to 64 [ 1882.349063] pciback
0000:07:00.1:
> >>> Driver tried to write to a read-only
configuration space field at
> >>> offset 0x62, size 2. This may
be harmless, but if you have
> >>> problems with your
device:
> >>> [ 1882.349066] 1) see permissive attribute in sysfs
[ 1882.349067]
> >>> 2) report problems to the xen-devel mailing
list along with
> >>> details of your device obtained from
lspci.
> >>> [ 1882.349205] alloc irq_desc for 477 on
node 0
> >>> [ 1882.349215] alloc kstat_irqs on node
0
> >>> [ 1882.402893] pciback 0000:07:00.2: enabling device
(0000 ->
> >>> 0003) [ 1882.402908] xen: registering gsi 47
triggering 0 polarity
> >>> 1 [ 1882.402913] xen_allocate_pirq:
returning irq 47 for gsi 47 [
> >>> 1882.402916] xen: -->
irq=47 [ 1882.402921] Already setup the GSI
> >>> :47 [
1882.402925] pciback 0000:07:00.2: PCI INT C -> GSI 47
> >>>
(level, low) -> IRQ 47 [ 1882.402938] pciback 0000:07:00.2:
>
>>> setting latency timer to 64 [ 1882.403280] pciback
0000:07:00.2:
> >>> Driver tried to write to a read-only
configuration space field at
> >>> offset 0x62, size 2. This may
be harmless, but if you have
> >>> problems with your
device:
> >>> [ 1882.403282] 1) see permissive attribute in sysfs
[ 1882.403282]
> >>> 2) report problems to the xen-devel mailing
list along with
> >>> details of your device obtained from
lspci.
> >>> [ 1882.403380] alloc irq_desc for 476 on
node 0
> >>> [ 1882.403386] alloc kstat_irqs on node
0
> >>> (XEN) [VT-D]iommu.c:824: iommu_fault_status: Primary
Pending Fault
> >>> (XEN) [VT-D]iommu.c:799: DMAR:[DMA Write]
Request device [07:00.0]
> >>> fault addr e6f80000, iommu reg =
ffff82c3fff57000
> >>> (XEN) DMAR:[fault reason 05h] PTE Write
access is not set
> >>> (XEN) print_vtd_entries: iommu =
ffff83019fffa370 bdf = 7:0.0 gmfn = e6f80
> >>>
(XEN) root_entry = ffff83019ff70000
> >>>
(XEN) root_entry[7] = 19cf52001
> >>>
(XEN) context = ffff83019cf52000
> >>>
(XEN) context[0] = 102_706dc005
> >>>
(XEN) l4 = ffff8300706dc000
> >>>
(XEN) l4_index = 0
> >>>
(XEN) l4[0] = 706db003
> >>>
(XEN) l3 = ffff8300706db000
> >>>
(XEN) l3_index = 3
> >>>
(XEN) l3[3] = 702b6003
> >>>
(XEN) l2 = ffff8300702b6000
> >>>
(XEN) l2_index = 137
> >>>
(XEN) l2[137] = 0
> >>>
(XEN) l2[137] not present
> >>> (XEN)
traps.c:466:d0 Unhandled nmi fault/trap [#2] on VCPU 0
> >>>
[ec=0000]
> >>
> >> That is not good. What changed from
your earlier emails that this was triggered?
> >
>
>Nothing
> >> Or was it triggered all along?
> >
>
>Yes, I just included it for completeness
> >
> >> What
happens if you run the system without the iommu enabled?
> >
>
>Haven't tried yet. Will check that next.
> >
>
>-Bruce
> >
>
>_______________________________________________
> >Xen-devel
mailing list
> >Xen-devel@xxxxxxxxxxxxxxxxxxx<mailto:Xen-devel@xxxxxxxxxxxxxxxxxxx>
>
>http://lists.xensource.com/xen-devel
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home