[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On Tue, Jan 20, 2015 at 12:52 AM, Tian, Kevin <kevin.tian@xxxxxxxxx> wrote:
>> 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.
> We may make a reasonable simplification to treat all RMRRs <1MB as
> conflicts (all real observations so far are in BIOS region).
> If above is possible, are you proposing to use xenstore instead of introducing
> new hypercall (definitely still one required to query per-device RMRR for
> libxl), given that libxc may not require change now?

Well I'm beginning to have less strong feelings, as we're moving from
public interface (which we have to try very hard not to change) into
an internal interface (which we can re-work if we need to).

But one thing I was thinking: if we add the entries to xenstore now,
we will not be *able* to then add RMRR checking in libxc (say, for
BIOS area conflicts) without another re-architecting.  Going with the
e820 hypercall might make adding RMRR checking in libxc easier.  OTOH,
it may be better to just directly pass some ranges into libxc anyway,
so perhaps that doesn't matter.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.