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

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

> From: George Dunlap [mailto:george.dunlap@xxxxxxxxxxxxx]
> Sent: Thursday, January 15, 2015 2:22 AM
> 
> On 01/14/2015 02:42 PM, Jan Beulich wrote:
> >>>> On 14.01.15 at 13:29, <george.dunlap@xxxxxxxxxxxxx> wrote:
> >> On 01/14/2015 08:06 AM, Tian, Kevin wrote:
> >>> We discussed earlier there are two reasons that some conflicts may not be
> >>> avoided:
> >>>   - RMRRs conflicting with guest BIOS in <1MB area, as an example of
> >>> hard conflicts
> >>>   - RMRRs conflicting with lowmem which is low enough then avoiding
> it
> >>> will either break lowmem or make lowmem too low to impact guest (just
> >>> an option being discussed)
> >>
> >> So here you're assuming that we're going to keep the lowmem / mmio hole
> >> / himem thing.  Is that necessary?  I was assuming that if we have
> >> arbitrary RMRRs, that we would just have to accept that we'd need to be
> >> able to punch an arbitrary number of holes in the p2m space.
> >
> > On the basis that the host would have placed the RMRRs in its MMIO
> > hole, I think I agree with Kevin that if possible we should stick with
> > the simpler lowmem / mmio-hole / highmem model if possible. If we
> > really find this too limiting, switching to the more fine grained model
> > later on will still be possible.
> 
> OK, sounds good.
> 
> One detail to work out in that case then is if / when we want to error
> out or warn the user that the mmio hole is "too big" (or the RMRR is
> "too low").
> 
> (I may think about it and post some thoughts tomorrow.)
> 

yes, this is a balance between real observation and ideal possibilities. :-)
hardcode a value (e.g. 2G) is simple but not flexible. I'm wondering 
whether there's a simple method to decide a reasonable boundary
based on host e820, or even makes this boundary as a configurable
option if we anyway go into the direction of more fine-grained control
to user?

Thanks
Kevin

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