RE: [Xen-devel] making changes to agp code?

["Langsdorf, Mark" <mark.langsdorf@xxxxxxx>]

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