| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Re: [GIT PULL] pv/pcifront-2.6.32
On Tue, Mar 02, 2010 at 12:12:23PM -0800, Jeremy Fitzhardinge wrote:
> On 03/01/2010 07:12 PM, Konrad Rzeszutek Wilk wrote:
>> Hey Jeremy,
>>
>> Please pull from
>> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
>> pv/pcifront-2.6.32
>>
>> It is a back-port of the Xen PCI front driver (not the SR-IOV one, just
>> old plain one). It has been tested with a bare 2.6.32 tree
>> (pv/master.2.6.32) and with xen/next
>>
>> The merge of this is a bit hairy, so I did my own which is available in
>> the pv/xen.next.merge (which is basically xen/next + pv/pcifront-2.6.32
>> + pv/fbfbront + xen: Allow unprivileged Xen domains to create iomap
>> pages).
>>
>
> I did a separate merge of the fbfront branch. Can you do another merge
> with just the pcifront stuff?
Done: pv/merge.xen.next
>
> (BTW, do you use git rerere? It remembers the results of previous merge
> resolutions and will apply them again if you re-merge.)
Oooh goodies. Will start using it.
>
>> To make the PCI front driver work, another patch has to be put added in
>> the xen/next (or better yet in the swiotlb - but it really does not seem
>> to fit there), which is the "xen: Allow unprivileged Xen domains to
>> create iomap pages" (5a7357bdb10b40414d97d7582f5467e4a709bd07)
>>
>
> Do we really need that patch any more? The comment doesn't seem to bear
> any relationship to its contents any more; it talks about disallowing
> ISA mappings, but all it does it mask write-through/uncachable from PTEs
> for non-privileged domains, and I'm not sure that's even desirable. I
> think Xen will mask those flags from the PTE if the domain isn't allowed
> to touch the device, and we want to be able to let passthrough mappings
> to be uncached or writethrough.
>
> Do things break without it?
I needed it for v2.6.32 + jeremy/xen/dom0/konrad-swiotlb-2.6.32 +
konrad/pv/pcifront-2.6.32. Otherwise I would get this:
[ 0.580008] alloc kstat_irqs on node 0
[ 0.586116] BUG: unable to handle kernel paging request at ffff88001fc9f7b0
[ 0.586133] IP: [<ffffffff8100cb39>] xen_set_pte+0x42/0x4d
[ 0.586149] PGD 1002067 PUD 1006067 PMD 1d4067 PTE 801000001fc9f065
[ 0.586171] Oops: 0003 [#1] SMP
[ 0.586183] last sysfs file:
[ 0.586191] CPU 0
[ 0.586199] Modules linked in:
[ 0.586211] Pid: 1, comm: swapper Not tainted 2.6.32NEB-00120-gd21d0fb #71
[ 0.586220] RIP: e030:[<ffffffff8100cb39>] [<ffffffff8100cb39>]
xen_set_pte+0x42/0x4d
[ 0.586236] RSP: e02b:ffff88001fcffaf0 EFLAGS: 00010296
[ 0.586245] RAX: 0000000000000000 RBX: ffff88001fc9f7b0 RCX: fffff7fffffff463
[ 0.586255] RDX: 0000000000000000 RSI: fffff7fffffff463 RDI: ffff88001fc9f7b0
[ 0.586265] RBP: ffff88001fcffb10 R08: ffffffff81547490 R09: 00000000000000d0
[ 0.586275] R10: ffffffff81547160 R11: ffff88001bd3e480 R12: fffff7fffffff463
[ 0.586285] R13: 0000000000000000 R14: ffffffff815560f0 R15: ffff88001fd00000
[ 0.586299] FS: 0000000000000000(0000) GS:ffff880004ab8000(0000)
knlGS:0000000000000000
[ 0.586311] CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 0.586320] CR2: ffff88001fc9f7b0 CR3: 0000000001001000 CR4: 0000000000002660
[ 0.586331] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 0.586341] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 0.586352] Process swapper (pid: 1, threadinfo ffff88001fcfe000, task
ffff88001fd00000)
[ 0.586385] Stack:
[ 0.586401] ffff88001fcffb08 ffff88001fc9f7b0 fffff7fffffff463
ffffc900000f6000
[ 0.586423] <0> ffff88001fcffb70 ffffffff8100cd16 ffffffff8100c67b
ffff88001fcffc20
[ 0.586459] <0> ffffffff8100c241 ffff88001bd3e480 ffffffff81547160
ffffc900000f7000
[ 0.586499] Call Trace:
[ 0.586515] [<ffffffff8100cd16>] xen_set_pte_at+0xdb/0xea
[ 0.586528] [<ffffffff8100c67b>] ? xen_make_pte+0x9/0xb
[ 0.586540] [<ffffffff8100c241>] ? __raw_callee_save_xen_make_pte+0x11/0x1e
[ 0.586555] [<ffffffff811b9bc2>] ioremap_page_range+0x236/0x298
[ 0.586569] [<ffffffff81033e69>] __ioremap_caller+0x291/0x2f7
[ 0.586581] [<ffffffff81033f9d>] ioremap_nocache+0x12/0x14
[ 0.586595] [<ffffffff8127d25c>] usb_hcd_pci_probe+0x155/0x305
[ 0.586608] [<ffffffff8100f28d>] ? xen_spin_unlock+0x11/0x30
[ 0.586622] [<ffffffff811d0433>] local_pci_probe+0x12/0x16
[ 0.586634] [<ffffffff811d1138>] pci_device_probe+0xc2/0xf2
[ 0.586648] [<ffffffff8124c535>] ? driver_sysfs_add+0x47/0x6c
[ 0.586660] [<ffffffff8124c66d>] driver_probe_device+0x9a/0x11f
[ 0.586673] [<ffffffff8124c74a>] __driver_attach+0x58/0x7c
[ 0.586685] [<ffffffff8124c6f2>] ? __driver_attach+0x0/0x7c
[ 0.586697] [<ffffffff8124bce4>] bus_for_each_dev+0x4e/0x83
[ 0.586710] [<ffffffff8124c4ec>] driver_attach+0x19/0x1b
[ 0.586721] [<ffffffff8124c15d>] bus_add_driver+0xb1/0x200
[ 0.586733] [<ffffffff8124ca0c>] driver_register+0x98/0x109
[ 0.586746] [<ffffffff811d1381>] __pci_register_driver+0x53/0xc3
[ 0.586759] [<ffffffff815f5514>] ehci_hcd_init+0xbc/0xe7
[ 0.586770] [<ffffffff815f5458>] ? ehci_hcd_init+0x0/0xe7
[ 0.586782] [<ffffffff8100a05f>] do_one_initcall+0x59/0x154
[ 0.586795] [<ffffffff815c86bc>] kernel_init+0x165/0x1bb
[ 0.586807] [<ffffffff81012a6a>] child_rip+0xa/0x20
[ 0.586819] [<ffffffff81011c21>] ? int_ret_from_sys_call+0x7/0x1b
[ 0.586831] [<ffffffff810123dd>] ? retint_restore_args+0x5/0x6
[ 0.586843] [<ffffffff81012a60>] ? child_rip+0x0/0x20
[ 0.586851] Code: ff ff 05 df 05 66 00 e8 63 fb ff ff 44 8b 2d db 05 66 00
e8 fa ff 01 00 ff c8 0f 94 c0 0f b6 c0 46 8d 2c 28 44 89 2d c3 05 66 00 <4c> 89
23 5b 5b 41 5c 41 5d c9 c3 55 48 89 e5 53 89 fb 48 83 ec
[ 0.587057] RIP [<ffffffff8100cb39>] xen_set_pte+0x42/0x4d
[ 0.587060] RSP <ffff88001fcffaf0>
[ 0.587060] CR2: ffff88001fc9f7b0
[ 0.587060] ---[ end trace c6d643cd9bbe496e ]---
_But_, with xen/next + pv/pcifront there was no need for it.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home