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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 08.01.15 at 16:15, <George.Dunlap@xxxxxxxxxxxxx> wrote:
> 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.

That might be an option, but would be safe/secure only as long as
nothing gets mapped in these regions before, which again would
require libxc changes.

Jan


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