From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: Re: [GIT PULL] pv/pcifront-2.6.32 Date: Tue, 2 Mar 2010 16:54:32 -0500 Message-ID: <20100302215432.GA29262@phenom.dumpdata.com> References: <20100302031217.GB881@phenom.dumpdata.com> <4B8D7127.5070907@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <4B8D7127.5070907@goop.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jeremy Fitzhardinge Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org 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: [] 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:[] [] 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] [] xen_set_pte_at+0xdb/0xea [ 0.586528] [] ? xen_make_pte+0x9/0xb [ 0.586540] [] ? __raw_callee_save_xen_make_pte+0x11/0x1e [ 0.586555] [] ioremap_page_range+0x236/0x298 [ 0.586569] [] __ioremap_caller+0x291/0x2f7 [ 0.586581] [] ioremap_nocache+0x12/0x14 [ 0.586595] [] usb_hcd_pci_probe+0x155/0x305 [ 0.586608] [] ? xen_spin_unlock+0x11/0x30 [ 0.586622] [] local_pci_probe+0x12/0x16 [ 0.586634] [] pci_device_probe+0xc2/0xf2 [ 0.586648] [] ? driver_sysfs_add+0x47/0x6c [ 0.586660] [] driver_probe_device+0x9a/0x11f [ 0.586673] [] __driver_attach+0x58/0x7c [ 0.586685] [] ? __driver_attach+0x0/0x7c [ 0.586697] [] bus_for_each_dev+0x4e/0x83 [ 0.586710] [] driver_attach+0x19/0x1b [ 0.586721] [] bus_add_driver+0xb1/0x200 [ 0.586733] [] driver_register+0x98/0x109 [ 0.586746] [] __pci_register_driver+0x53/0xc3 [ 0.586759] [] ehci_hcd_init+0xbc/0xe7 [ 0.586770] [] ? ehci_hcd_init+0x0/0xe7 [ 0.586782] [] do_one_initcall+0x59/0x154 [ 0.586795] [] kernel_init+0x165/0x1bb [ 0.586807] [] child_rip+0xa/0x20 [ 0.586819] [] ? int_ret_from_sys_call+0x7/0x1b [ 0.586831] [] ? retint_restore_args+0x5/0x6 [ 0.586843] [] ? 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 [] xen_set_pte+0x42/0x4d [ 0.587060] RSP [ 0.587060] CR2: ffff88001fc9f7b0 [ 0.587060] ---[ end trace c6d643cd9bbe496e ]--- _But_, with xen/next + pv/pcifront there was no need for it.