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] making changes to agp code?

To: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Subject: RE: [Xen-devel] making changes to agp code?
From: "Langsdorf, Mark" <mark.langsdorf@xxxxxxx>
Date: Wed, 28 Mar 2007 10:21:26 -0500
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 28 Mar 2007 08:36:40 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <460A9248.76E4.0078.0@xxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1449F58C868D8D4E9C72945771150BDFD96770@xxxxxxxxxxxxxxxxx> <460A9248.76E4.0078.0@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcdxQhy/gX+aUzbZSPuq/kjTW7plwwACkKDA
Thread-topic: [Xen-devel] making changes to agp code?
> >>> "Langsdorf, Mark" <mark.langsdorf@xxxxxxx> 26.03.07 22:03 >>>
> >As part of my endless quest to enable GART/IOMMU, I
> >realized I need to make a slight change to a static
> >function inside of agp-amd64.c.  Currently Xen doesn't
> >have -xen variants of the AGP code.  Is there a 
> >better way to handle this than sucking in the entire
> >AGP tree into xen-sparse?
> >
> >As far what I need to change:
> >   pci-gart calls agp_amd64_init() to determine if
> >the aperture is provided by the BIOS, or if one 
> >needs to be allocated.  agp_amd64_init() calls
> >agp_amd64_probe() which calls another function
> >and so forth, and eventually aperture_valid()
> >calls 
> >PageReserved(pfn_to_page(aperture >> PAGE_SHIFT)).
> >The page isn't actually reserved, but dom0 thinks
> >it is, and the operation fails.  I would like to
> >do something more intelligent.
> 
> On a second look I believe the implementation is broken even 
> on native, as long as !CONFIG_FLATMEM, since there's an
> assumption that an invalid PFN cannot be followed by a valid
> one. For that reason, I think the code needs to be changed to
> call e820_any_mapped() (just like aperture.c does). I have a
> tentative patch to do that, but don't have a working box with
> an 8151.

I do.  You can send it to me for testing.

I was playing with that box yesterday, and I discovered
that Xen allocates guest virtual memory over the AGP
aperture if dom0 memory is greater than 4G, even though
the e820 map says it shouldn't.  I didn't have a lot of
spare cycles yesterday to deal with the implications of
that, and maybe it can be safely ignored.  Any thoughts?

-Mark Langsdorf
AMD, Inc. 



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