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

Re: [Xen-devel] Regression in kernel 3.5 as Dom0 regarding PCI Passthrough?!

To: "Ren, Yongjie" <yongjie.ren@xxxxxxxxx>
From: Tobias Geiger <tobias.geiger@xxxxxxxxx>
Date: Fri, 07 Sep 2012 12:37:21 +0200
Cc: Konrad Rzeszutek Wilk <konrad@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxx, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Delivery-date: Fri, 07 Sep 2012 10:38:01 +0000
List-id: Xen developer discussion <xen-devel.lists.xen.org>

Am 07.09.2012 04:08, schrieb Ren, Yongjie:

-----Original Message-----
From: Tobias Geiger [mailto:tobias.geiger@xxxxxxxxx]
Sent: Thursday, September 06, 2012 7:28 PM
To: Konrad Rzeszutek Wilk
Cc: Ren, Yongjie; Konrad Rzeszutek Wilk; xen-devel@xxxxxxxxxxxxx

Subject: Re: [Xen-devel] Regression in kernel 3.5 as Dom0 regardingPCI

Passthrough?!

Hello Konrad,

the patch helps regarding the USB-PCIController-Passthrough - this
works now in DomU.

Hi Tobias,
In my testing, this patch can't work for a NIC pass-through.
Could you have a try with a NIC pass-through?

Hi!

unfortunatly not - i have no physical access to the machine until themiddle of next week.and as so soon as i try to passthrough the only nic in this machine myremote access will die... :(

perhaps someone else can test nic-passthrough? if not i'll try it asapnext week!


Greetings
Tobias

but i still get the Dom0 crash when shutting down DomU:

Sep  6 13:26:19 pc kernel: [  361.011514]
xen-blkback:backend/vbd/1/832: prepare for reconnect
Sep  6 13:26:20 pc kernel: [  361.876395]
xen-blkback:backend/vbd/1/768: prepare for reconnect

Sep 6 13:26:21 pc kernel: [ 362.682152] br0: port 3(vif1.0)entered

disabled state

Sep 6 13:26:21 pc kernel: [ 362.682267] br0: port 3(vif1.0)entered

disabled state
Sep  6 13:26:24 pc kernel: [  365.541386] ------------[ cut here
]------------
Sep  6 13:26:24 pc kernel: [  365.541411] invalid opcode: 0000 [#1]
PREEMPT SMP
Sep  6 13:26:24 pc kernel: [  365.541423] CPU 2

Sep 6 13:26:24 pc kernel: [ 365.541427] Modules linked in:uvcvideo

snd_usb_audio snd_usbmidi_lib snd_seq_midi snd_hwd
ep snd_rawmidi videobuf2_vmalloc videobuf2_memops videobuf2_core
videodev gpio_ich joydev hid_generic [last unloaded: sc
si_wait_scan]
Sep  6 13:26:24 pc kernel: [  365.541474]

Sep 6 13:26:24 pc kernel: [ 365.541477] Pid: 1208, comm:kworker/2:1

Not tainted 3.5.0 #3                  /DX58SO
Sep  6 13:26:24 pc kernel: [  365.541491] RIP:
e030:[<ffffffff81447f95>]  [<ffffffff81447f95>]
balloon_process+0x385/0x3
a0
Sep  6 13:26:24 pc kernel: [  365.541507] RSP: e02b:ffff88012e7abdc0
EFLAGS: 00010213
Sep  6 13:26:24 pc kernel: [  365.541515] RAX: 0000000220be7000 RBX:
0000000000000000 RCX: 0000000000000008
Sep  6 13:26:24 pc kernel: [  365.541523] RDX: ffff88010d99a000 RSI:
00000000000001df RDI: 000000000020efdf
Sep  6 13:26:24 pc kernel: [  365.541532] RBP: ffff88012e7abe20 R08:
ffff88014064e140 R09: 00000000fffffffe
Sep  6 13:26:24 pc kernel: [  365.541540] R10: 0000000000000001 R11:
0000000000000000 R12: 0000160000000000
Sep  6 13:26:24 pc kernel: [  365.541548] R13: 0000000000000001 R14:
000000000020efdf R15: ffffea00083bf7c0

Sep 6 13:26:24 pc kernel: [ 365.541561] FS:00007f79d32ce700(0000)

GS:ffff880140640000(0000) knlGS:0000000000000000

Sep 6 13:26:24 pc kernel: [ 365.541571] CS: e033 DS: 0000 ES:0000

CR0: 000000008005003b
Sep  6 13:26:24 pc kernel: [  365.541578] CR2: 00007f79d2d6ce02 CR3:
0000000001e0c000 CR4: 0000000000002660
Sep  6 13:26:24 pc kernel: [  365.541587] DR0: 0000000000000000 DR1:
0000000000000000 DR2: 0000000000000000
Sep  6 13:26:24 pc kernel: [  365.541596] DR3: 0000000000000000 DR6:
00000000ffff0ff0 DR7: 0000000000000400
Sep  6 13:26:24 pc kernel: [  365.541604] Process kworker/2:1 (pid:
1208, threadinfo ffff88012e7aa000, task ffff88013101
c440)
Sep  6 13:26:24 pc kernel: [  365.541613] Stack:
Sep  6 13:26:24 pc kernel: [  365.541618]  000000000006877b
0000000000000001 ffffffff8200ea80 0000000000000001
Sep  6 13:26:24 pc kernel: [  365.541649]  0000000000000000
0000000000007ff0 ffff88012e7abe00 ffff8801302eee00
Sep  6 13:26:24 pc kernel: [  365.541664]  ffff880140657000
ffff88014064e140 0000000000000000 ffffffff81e587c0
Sep  6 13:26:24 pc kernel: [  365.541679] Call Trace:
Sep  6 13:26:24 pc kernel: [  365.541688]  [<ffffffff8106753b>]
process_one_work+0x12b/0x450
Sep  6 13:26:24 pc kernel: [  365.541697]  [<ffffffff81447c10>] ?
decrease_reservation+0x320/0x320
Sep  6 13:26:24 pc kernel: [  365.541706]  [<ffffffff810688be>]
worker_thread+0x12e/0x2d0
Sep  6 13:26:24 pc kernel: [  365.541715]  [<ffffffff81068790>] ?
manage_workers.isra.26+0x1f0/0x1f0
Sep  6 13:26:24 pc kernel: [  365.541725]  [<ffffffff8106db7e>]
kthread+0x8e/0xa0
Sep  6 13:26:24 pc kernel: [  365.541735]  [<ffffffff8184e3e4>]
kernel_thread_helper+0x4/0x10
Sep  6 13:26:24 pc kernel: [  365.541745]  [<ffffffff8184c87c>] ?
retint_restore_args+0x5/0x6
Sep  6 13:26:24 pc kernel: [  365.541754]  [<ffffffff8184e3e0>] ?
gs_change+0x13/0x13

Sep 6 13:26:24 pc kernel: [ 365.541760] Code: 01 15 f0 6a bc 00 4829

d0 48 89 05 ee 6a bc 00 e9 31 fd ff ff 0f 0b 0f

0b 4c 89 f7 e8 85 34 bc ff 48 83 f8 ff 0f 84 2b fe ff ff <0f> 0b 660f

1f 84 00 00 00 00 00 48 83 c1 01 e9 c2 fd ff ff 0
f
Sep  6 13:26:24 pc kernel: [  365.541898]  RSP <ffff88012e7abdc0>
Sep  6 13:26:24 pc kernel: [  365.565054] ---[ end trace
25eb9ce0cc61c3a1 ]---
Sep  6 13:26:24 pc kernel: [  365.565101] PGD 1e0e067 PUD 1e0f067
PMD 0

Sep 6 13:26:24 pc kernel: [ 365.565108] Oops: 0000 [#2] PREEMPTSMP

Sep  6 13:26:24 pc kernel: [  365.565115] CPU 2

Sep 6 13:26:24 pc kernel: [ 365.565118] Modules linked in:uvcvideo

snd_usb_audio snd_usbmidi_lib snd_seq_midi snd_hwd
ep snd_rawmidi videobuf2_vmalloc videobuf2_memops videobuf2_core
videodev gpio_ich joydev hid_generic [last unloaded: sc
si_wait_scan]
Sep  6 13:26:24 pc kernel: [  365.565153]

Sep 6 13:26:24 pc kernel: [ 365.565156] Pid: 1208, comm:kworker/2:1

Tainted: G      D      3.5.0 #3
/DX58SO
Sep  6 13:26:24 pc kernel: [  365.565176] RIP:

e030:[<ffffffff8106e08c>] [<ffffffff8106e08c>]kthread_data+0xc/0x20

Sep  6 13:26:24 pc kernel: [  365.565194] RSP: e02b:ffff88012e7aba90
EFLAGS: 00010092
Sep  6 13:26:24 pc kernel: [  365.565205] RAX: 0000000000000000 RBX:
0000000000000002 RCX: 0000000000000002
Sep  6 13:26:24 pc kernel: [  365.565219] RDX: ffffffff81fcba40 RSI:
0000000000000002 RDI: ffff88013101c440
Sep  6 13:26:24 pc kernel: [  365.565233] RBP: ffff88012e7abaa8 R08:
0000000000989680 R09: ffffffff81fcba40
Sep  6 13:26:24 pc kernel: [  365.565248] R10: ffffffff813b0c00 R11:
0000000000000000 R12: ffff8801406536c0
Sep  6 13:26:24 pc kernel: [  365.565262] R13: 0000000000000002 R14:
ffff88013101c430 R15: ffff88013101c440

Sep 6 13:26:24 pc kernel: [ 365.565280] FS:00007f79d32ce700(0000)

GS:ffff880140640000(0000) knlGS:0000000000000000

Sep 6 13:26:24 pc kernel: [ 365.565293] CS: e033 DS: 0000 ES:0000

CR0: 000000008005003b
Sep  6 13:26:24 pc kernel: [  365.565303] CR2: fffffffffffffff8 CR3:
0000000001e0c000 CR4: 0000000000002660
Sep  6 13:26:24 pc kernel: [  365.565318] DR0: 0000000000000000 DR1:
0000000000000000 DR2: 0000000000000000
Sep  6 13:26:24 pc kernel: [  365.565332] DR3: 0000000000000000 DR6:
00000000ffff0ff0 DR7: 0000000000000400
Sep  6 13:26:24 pc kernel: [  365.565349] Process kworker/2:1 (pid:
1208, threadinfo ffff88012e7aa000, task ffff88013101
c440)
Sep  6 13:26:24 pc kernel: [  365.565362] Stack:
Sep  6 13:26:24 pc kernel: [  365.565367]  ffffffff810698e0
ffff88012e7abaa8 ffff88013101c818 ffff88012e7abb18
Sep  6 13:26:24 pc kernel: [  365.565389]  ffffffff8184ae02
ffff88012e7abfd8 ffff88013101c440 ffff88012e7abfd8
Sep  6 13:26:24 pc kernel: [  365.565410]  ffff88012e7abfd8
ffff88012d8840c0 ffff88013101c440 ffff88013101ca30



Perhaps this stacktrace helps...

Thanks!

Am 05.09.2012 20:54, schrieb Konrad Rzeszutek Wilk:
>> > > > And its due to a patch I added in v3.4
>> > > > (cd9db80e5257682a7f7ab245a2459648b3c8d268)
>> > > > - which did not work properly in v3.4, but with v3.5 got it
>> working

>> > > > (977f857ca566a1e68045fcbb7cfc9c4acb077cf0) which causesv3.5

>> to
>> > now
>> > > > work
>> > > > anymore.
>> > > >
>> > > > Anyhow, for right now jsut revert
>> > > > cd9db80e5257682a7f7ab245a2459648b3c8d268
>> > > > and it should work for you.
>> > > >
>> Confirmed, after reverting that commit, VT-d will work fine.
>> Will you fix this and push it to upstream Linux, Konrad?
>>
>> > > Also, our team reported a VT-d bug 2 months ago.
>> > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1824
>> >
>
> Can either one of you please test this patch, please:
>
>
> diff --git a/drivers/xen/xen-pciback/pci_stub.c
> b/drivers/xen/xen-pciback/pci_stub.c
> index 097e536..425bd0b 100644
> --- a/drivers/xen/xen-pciback/pci_stub.c
> +++ b/drivers/xen/xen-pciback/pci_stub.c
> @@ -4,6 +4,8 @@
>   * Ryan Wilson <hap9@xxxxxxxxxxxxxx>
>   * Chris Bookholt <hap10@xxxxxxxxxxxxxx>
>   */
> +#define DEBUG 1
> +
>  #include <linux/module.h>
>  #include <linux/init.h>
>  #include <linux/rwsem.h>
> @@ -97,13 +99,15 @@ static void pcistub_device_release(struct kref
> *kref)
>    /* Call the reset function which does not take lock as this
>     * is called from "unbind" which takes a device_lock mutex.
>     */
> +  dev_dbg(&psdev->dev->dev, "FLR locked..\n");
>    __pci_reset_function_locked(psdev->dev);
>    if (pci_load_and_free_saved_state(psdev->dev,
>                                      &dev_data->pci_saved_state)) {
>            dev_dbg(&psdev->dev->dev, "Could not reload PCI state\n");
> -  } else
> +  } else {
> +          dev_dbg(&psdev->dev->dev, "Reloading PCI state..\n");
>            pci_restore_state(psdev->dev);
> -
> +  }
>    /* Disable the device */
>    xen_pcibk_reset_device(psdev->dev);
>

> @@ -353,16 +357,16 @@ static int __devinitpcistub_init_device(struct

> pci_dev *dev)
>    if (err)
>            goto config_release;
>
> -  dev_dbg(&dev->dev, "reseting (FLR, D3, etc) the device\n");
> -  __pci_reset_function_locked(dev);
> -
>    /* We need the device active to save the state. */
>    dev_dbg(&dev->dev, "save state of device\n");
>    pci_save_state(dev);
>    dev_data->pci_saved_state = pci_store_saved_state(dev);
>    if (!dev_data->pci_saved_state)
>            dev_err(&dev->dev, "Could not store PCI conf saved state!\n");
> -
> +  else {
> +          dev_dbg(&dev->dev, "reseting (FLR, D3, etc) the device\n");
> +          __pci_reset_function_locked(dev);
> +  }
>    /* Now disable the device (this also ensures some private device
>     * data is setup before we export)
>     */



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

References:
- Re: [Xen-devel] Regression in kernel 3.5 as Dom0 regarding PCI Passthrough?!
  - From: Konrad Rzeszutek Wilk
- Re: [Xen-devel] Regression in kernel 3.5 as Dom0 regarding PCI Passthrough?!
  - From: Tobias Geiger
- Re: [Xen-devel] Regression in kernel 3.5 as Dom0 regarding PCI Passthrough?!
  - From: Ren, Yongjie

Prev by Date: Re: [Xen-devel] Xen4.2 S3 regression?
Next by Date: Re: [Xen-devel] [PATCH 10/11] tmem: fixup 2010 cleanup patch that breaks tmem save/restore
Previous by thread: Re: [Xen-devel] Regression in kernel 3.5 as Dom0 regarding PCI Passthrough?!
Next by thread: Re: [Xen-devel] Regression in kernel 3.5 as Dom0 regarding PCI Passthrough?!
Index(es):
- Date
- Thread

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