WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel
From: Pasi Kärkkäinen <pasik@xxxxxx>
Date: Wed, 9 Jun 2010 21:39:57 +0300
Cc: Arvind R <arvino55@xxxxxxxxx>, Jeremy Fitzhardinge <jeremy@xxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Joanna Rutkowska <joanna@xxxxxxxxxxxxxxxxxxxxxx>, Michael D Labriola <mlabriol@xxxxxxxx>, xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 09 Jun 2010 11:50:46 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20100609174342.GA13712@xxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4B9C0BAA.4060007@xxxxxxxxxxxxxxxxxxxxxx> <OF5A3547F1.A198374F-ON852576E7.004EC871-852576E7.005101FB@xxxxxxxx> <20100609174342.GA13712@xxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.18 (2008-05-17)
On Wed, Jun 09, 2010 at 01:43:42PM -0400, Konrad Rzeszutek Wilk wrote:
> > > >>>         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);
> > > >>>
> .. snip.
> > > >>> nVidia GeForce 9400 GT.
> 
> ..snip..
> > 
> > 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 
> .. snip..
> > [  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
> 
> 
> So, I've spent the last two weeks trying to get this to work.
> 
> What I found out was that the majority of the problems were with the Linux 
> AGP code
> (drivers/char/agp/*). Now I can get Kernel Modesetting 
> working under Radeon HD3200 (PCI-e), NVidia GeForce FX5200 (AGP), and I think
> other ones too (hadn't tested yet). However, I am still failing at the same
> spot as Michael: the dreaded Opened GPU Channel 1...
> 
> Anyhow.. if you want the patches:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git devel/kms-fixes
> 
> (and the "devel/drm.backport" which is a drop of drm/* from 2.6.34-rc7 in
> 2.6.32 universe).
> 
> The explanation:
> 
> 1). Newer boxes with PCI-e cards with more than 4GB allocated to dom0.
> Those cards have their own IOMMU built in on the cards and use the PCI
> DMA. The problem is that some of those cards set the DMA mask to 32-bit,
> meaning they are only comfortable allocating pages under the 4GB mark.
> The Xen-SWIOTLB kicks in and happily gives a bounce buffer for pages
> that are above the 32-bit mark, which are then programmed to the IOMMU.
> Except that the graphic drivers do not sync the bounce buffer so the
> result ends up stored in the bounce buffer and not in the buffer the
> graphic drivers expect (oops).  That however should not have happend
> as any pages allocated from the TTM library use the 'alloc_page' with
>  _GFP_DMA32 flag, which means that all of those pages WILL be under
> 4GB under baremetal. However under Xen that flag is useless and the page
> can be very well allocated above the 4GB mark (and is if you are using
> the debug Xen hypervisor). The patch titled
>  "ttm: When TTM_PAGE_FLAG_DMA32 allocate pages under" fixes that by
> replacing the PFNs with ones under the 4GB.
> 
> It makes my Radeon HD3200 work, and I believe other PCI-e cards too.
> 
> 2). i915 cards:
> The earlier cards (before PCI-e) depend on the AGP to the virtual to
> physical address translations.  The old AGP code is safe for specific 
> controllers: say i915 - and only if you have CONFIG_DMAR enabled. So
> there is a patch if you don't have that enabled:
> 
>       intel-agp: Warn when !USE_PCI_DMA_API and inserting bogus bus addresses.
> 
> 3) i915 and before.
> For older ones, such as the ICH5 (which has an i860 chipset), the Linux
> code blindly uses the virt_to_phys and page_to_phys which are not
> Xen-safe. For this fancy NV30 card (which is AGP) I've gotten to the
> point of the framebuffer displaying properly. The patches that fix this
> are:
>   intel-agp: Use Xen back-door to get page's physical address for i8[1,3]0
>       agp-backend: Use Xen back-door to get bus address for scratch page.
>       agp: If _GFP_DMA_32 flag is set enforce pages to be under 4GB under Xen.
>       agp: Program the GART with the real physical address under Xen.
>       agp: Use Xen back-door to get bus address for legacy code.
> 
> 
> 4). I did check out the AGP code for the other chipsets, so added
> experimental support for AMD64 chipset. Haven't tested it at all.
> 
> Summary:
> Most of those patches are not upstream materials. Right now I am
> just trying to get those bugs fixed and then later on revisit them with
> a more comprehensive patch.
> 

Wow. Impressive work!

Hopefully the "Opened GPU channel 1" -thing gets beaten sooner than later too.. 
unfortunately I don't have Nvidia GPU at the moment so I can't really help with 
that..

-- Pasi


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