>>> On 08.01.15 at 13:54, <george.dun...@eu.citrix.com> wrote: > On Thu, Jan 8, 2015 at 12:49 PM, George Dunlap > <george.dun...@eu.citrix.com> wrote: >> If RMRRs almost always happen up above 2G, for example, then a simple >> solution that wouldn't require too much work would be to make sure >> that the PCI MMIO hole we specify to libxc and to qemu-upstream is big >> enough to include all RMRRs. That would satisfy the libxc and qemu >> requirements. >> >> If we then store specific RMRRs we want included in xenstore, >> hvmloader can put them in the e820 map, and that would satisfy the >> hvmloader requirement. > > An alternate thing to do here would be to "properly" fix the > qemu-upstream problem, by making a way for hvmloader to communicate > changes in the gpfn layout to qemu. > > Then hvmloader could do the work of moving memory under RMRRs to > higher memory; and libxc wouldn't need to be involved at all.
I don't think avoiding libxc involvement is possible: Once a certain range of memory has been determined to need reserving (e.g. due to a statically assigned device), attempts to populate the respective GFNs with RAM would (ought to) fail. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
