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?

>>> "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.

Jan

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