[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Re: [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx wrote on 03/25/2010 03:18:42 AM: > On 03/15/2010 07:44 AM, Michael D Labriola wrote: > > xen-devel-bounces@xxxxxxxxxxxxxxxxxxx wrote on 03/13/2010 05:03:22 PM: > > > > > >> On 03/12/2010 01:45 PM, Arvind R wrote: > >> > >>> On Thu, Mar 11, 2010 at 4:32 PM, Pekka Paalanen<pq@xxxxxx> wrote: > >>> > >>>> I'm adding dri-devel@ to CC, since this suggested patch touches > >>>> TTM code, and none of the Nouveau code. TTM patches go via > >>>> dri-devel@. > >>>> > >>>> Thanks. > >>>> > >>>> > >>>> On Wed, 10 Mar 2010 18:51:21 +0530 > >>>> Arvind R<arvino55@xxxxxxxxx> wrote: > >>>> > >>>> > >>>>> Hi, > >>>>> Following is a simple patch that is needed in nouveau to get > >>>>> accelerated X on a Xen dom0 pv_ops kernel. The kernel is jeremy's > >>>>> 2.6.31.6 as of 20100222. The whole gpu tree of nouveau (which is > >>>>> almost the mainline merge), was substituted into the kernel-tree. > >>>>> All components of X (mesa, Xorg-server-7.5, xf86-nouveau, libdrm) > >>>>> used of the same day. > >>>>> > >>>>> Patch: > >>>>> diff -Naur nouveau-kernel.orig/drivers/gpu/drm/ttm/ttm_bo_vm.c > >>>>> nouveau-kernel.new/drivers/gpu/drm/ttm/ttm_bo_vm.c > >>>>> --- nouveau-kernel.orig/drivers/gpu/drm/ttm/ttm_bo_vm.c 2010-01-27 > >>>>> 10:19:28.000000000 +0530 > >>>>> +++ nouveau-kernel.new/drivers/gpu/drm/ttm/ttm_bo_vm.c 2010-03-10 > >>>>> 17:28:59.000000000 +0530 > >>>>> @@ -271,7 +271,10 @@ > >>>>> */ > >>>>> > >>>>> vma->vm_private_data = bo; > >>>>> - vma->vm_flags |= VM_RESERVED | VM_IO | VM_MIXEDMAP | > >>>>> VM_DONTEXPAND; > >>>>> + vma->vm_flags |= VM_RESERVED | VM_MIXEDMAP | > >>>>> VM_DONTEXPAND; > >>>>> + if (!((bo->mem.placement& TTM_PL_MASK_MEM)& > >>>>> TTM_PL_FLAG_TT)) > >>>>> + vma->vm_flags |= VM_IO; > >>>>> + vma->vm_page_prot = vma_get_vm_prot(vma->vm_flags); > >>>>> return 0; > >>>>> out_unref: > >>>>> ttm_bo_unref(&bo); > >>>>> > >>>>> > >>> sorry for the typo and other procedural errors. > >>> the last added line should be > >>> + vma->vm_page_prot = vm_get_page_prot(vma->vm_flags) > >>> > >>> > >>>>> This patch is necessary because, in Xen, PFN of a page is > >>>>> virtualised. So physical addresses > >>>>> for DMA programming needs to use the MFN. Xen transparently does > >>>>> the correct translation > >>>>> using the _PAGE_IOMEM prot-bit in the PTE. If the bit is set, > >>>>> then Xen assumes that the backing > >>>>> memory is in the IOMEM space, and PFN equals MFN. If not set, > >>>>> page_to_pfn() returns MFN. > >>>>> > >>>>> The patch enables the ttm_bo_vm_fault() handler to behave > >>>>> correctly under Xen, and has no > >>>>> side-effects on normal (not under Xen) operations. The use of > >>>>> TTM_PL_FLAG_TT in the > >>>>> check assumes that all other placements are backed by device > >>>>> memory or IO. If there are > >>>>> any other placements that use system memory, that flag has to be > >>>>> OR'ed into the check. > >>>>> > >>>>> The above patch has no implications on a normal kernel or a Xen > >>>>> pv_ops kernel booted without > >>>>> the Xen hypervisor. My testing is on a debian-lenny environment > >>>>> on a Core2 processor with > >>>>> nVidia GeForce 9400 GT. > >>>>> > >>>> > >>> Efficacy of patch: > >>> successful flightgear run on dom0 AND bareboot! > >>> > >>> > >> Jeremy, will you be merging this patch into any of the xen/stable-* > >> branches any time soon? > >> > >> Thanks, > >> joanna. > >> > > Hmm... I just verified that this patch fixes KMS/Nouveau issues in Xen on > > my two primary test boxes (GeForce 6200, GeForce 7300). However, on my > > really old machines (AGP GeForce2 MX200), this causes a new crash. These > > old boxes were actually working fine in Xen prior to this patch, just > > w/out 3d acceleration. Now I get the following messages in dmesg: > > > > [ 129.637319] [drm] nouveau 0000:01:00.0: Allocating FIFO number 1 > > [ 129.638853] [drm] nouveau 0000:01:00.0: nouveau_channel_alloc: > > initialised FIFO 1 > > [ 129.643791] X: Corrupted page table at address 40412000 > > [ 129.643815] *pdpt = 0000000015216001 *pde = 0000000000000000 > > [ 129.643856] Bad pagetable: 000f [#1] SMP > > [ 129.643897] last sysfs file: > > /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/boot_vga > > [ 129.643916] Modules linked in: bridge stp ipv6 autofs4 sunrpc raid1 > > video output sbs sbshc pci_slot lp sg nouveau snd_intel8x0 snd_ac97_codec > > ac97_bus snd_seq_dummy he atm ttm drm_kms_helper snd_seq_oss > > snd_seq_midi_event sr_mod snd_seq cdrom drm serio_raw snd_seq_device > > snd_pcm_oss snd_mixer_oss snd_pcm e100 mii i2c_algo_bit snd_timer > > ata_generic snd pcspkr i2c_i801 i2c_core intel_rng soundcore i82860_edac > > snd_page_alloc pata_acpi edac_core parport_pc floppy parport dm_snapshot > > dm_zero dm_mirror dm_region_hash dm_log dm_mod raid0 ext3 mbcache jbd > > aic7xxx scsi_transport_spi ata_piix libata sd_mod scsi_mod > > [ 129.644024] > > [ 129.644024] Pid: 3690, comm: X Not tainted (2.6.31.6-mdl5 #1) P4DC6 > > [ 129.644024] EIP: 0073:[<40394596>] EFLAGS: 00210206 CPU: 0 > > [ 129.644024] EIP is at 0x40394596 > > [ 129.644024] EAX: 40412000 EBX: 40396cd8 ECX: 0909ee98 EDX: 00044000 > > [ 129.644024] ESI: 00000034 EDI: 0909edd8 EBP: bfe7f798 ESP: bfe7f780 > > [ 129.644024] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b > > [ 129.644024] Process X (pid: 3690, ti=ea1ce000 task=ea77f110 > > task.ti=ea1ce000) > > [ 129.644024] > > [ 129.644024] EIP: [<40394596>] 0x40394596 SS:ESP 007b:bfe7f780 > > [ 129.644024] ---[ end trace 569eb18d737a8611 ]--- > > [ 129.652216] [drm] nouveau 0000:01:00.0: nouveau_channel_free: freeing > > fifo 1 > > > > > > And my X log ends abruptly after this line: > > (II) NOUVEAU(0): Opened GPU Channel 1 > > > > Any ideas? > > > > BTW, what chipset does this machine have? Is it Intel? AMD? Other? > > J It's a really old Intel Xeon SMP box. SuperMicro P4DC6+ motherboard. --- Michael D Labriola Electric Boat mlabriol@xxxxxxxx 401-848-8871 (desk) 401-848-8513 (lab) 401-316-9844 (cell) _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |