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

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

On 01/19/2015 12:23 PM, Tim Deegan wrote:
> At 11:41 +0000 on 19 Jan (1421664109), Jan Beulich wrote:
>>>>> On 19.01.15 at 12:33, <tim@xxxxxxx> wrote:
>>> FWIW, I don't like adding hypervisor state (and even more so
>>> hypervisor mechanism like a new hypercall) for things that the
>>> hypervisor doesn't need to know about.  Since the e820 is only shared
>>> between the tools and the guest, I'd prefer it to go in either
>>> the hvm_info_table or xenstore.
>>
>> But we have the guest E820 in the hypervisor already, which we
>> also can't drop (as XENMEM_memory_map is a generally accessible
>> hypercall).
> 
> So we do. :(  What is the difference between that (with appropriate
> reserved regions in the map) and the proposed new hypercall?

Well one thing that's been proposed that we extend that e820 to include
RMRRs, so we can just re-use the same hypercall in hvmloader.

If we're sticking with the "lowmem / mmio hole / himem" thing for now,
does libxc actually need access to the RMRRs?

For RMRRs outside the BIOS area, libxl will either be making the mmio
hole large enough (in which case it will definitely know that there are
no conflicts) or it will not (in which case it will definitely know that
there are conflicts).

For RMRRs in the BIOS area, libxl will already need to know where that
area is (to know that it doesn't need to fit it into the MMIO hole); if
we just make it smart enough to know where the actual BIOS resides, then
it can detect the conflict itself without needing to involve libxc.  Not
sure if that's easier than teaching libxc how to use XENMEM_memory_map.

 -George

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