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

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

On Thu, Jan 8, 2015 at 1:00 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>> 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.

Is it the case that marking a range as an RMRR in Xen basically only
involves adding a 1-1 mapping in the p2m / IOMMU?

So is it the case that the main reason the "empty RMRR gpfn range in
hvmloader" solution wouldn't work is that for statically-assigned
devices, the devices are assigned to the guest before it boots (and
thus before hvmloader gets to run)?

We could imagine not actually mapping the RMRRs on domain creation,
but allowing hvmloader to move the gpfns around and then ask Xen to do
the 1-1 mapping.

It would obviously be a bit more complicated, but there's also
something satisfying about being able to have all of the gpfn
re-arrangement stuff happening in hvmloader, rather than have to
separately specify the guest p2m layout to three different bits of
code (libxc domain builder, qemu, hvmloader).

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel