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

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

> From: George Dunlap
> Sent: Tuesday, January 20, 2015 8:57 PM
> 
> 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.
> 

OK, by combining all the comments together we'll take a close look at
how extending XENMEM_{get/set}_memory_map may work. Initial
goal would be to minimizing major re-architecting (i.e. having libxl 
to do coarse-grained conflict avoidance and set memory map, and 
then having hvmloader to get memory map when constructing 
actual e820. no change to libxc so does hvm_info etc.)

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