[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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. 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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |