Re: [Xen-devel] (v2) Design proposal for RMRR fix

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 08.01.15 at 13:54, <George.Dunlap@xxxxxxxxxxxxx> wrote:
> On Thu, Jan 8, 2015 at 12:49 PM, George Dunlap
> <George.Dunlap@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel