[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
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
|
