Re: [Xen-devel] Re: [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel

[Jeremy Fitzhardinge <jeremy@xxxxxxxx>]

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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel