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

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



> From: Tian, Kevin
> Sent: Monday, January 12, 2015 8:29 PM
> 
> > From: George Dunlap
> > Sent: Monday, January 12, 2015 8:14 PM
> >
> > On Mon, Jan 12, 2015 at 11:22 AM, Tian, Kevin <kevin.tian@xxxxxxxxx>
> wrote:
> > >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> > >> Sent: Monday, January 12, 2015 6:23 PM
> > >>
> > >> >>> On 12.01.15 at 11:12, <kevin.tian@xxxxxxxxx> wrote:
> > >> >>  From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> > >> >> Sent: Monday, January 12, 2015 6:09 PM
> > >> >>
> > >> >> >>> On 12.01.15 at 10:56, <kevin.tian@xxxxxxxxx> wrote:
> > >> >> > the result is related to another open whether we want to block guest
> > >> >> > boot for such problem. If 'warn' in domain builder is acceptable, we
> > >> >> > don't need to change lowmem for such rare 1GB case, just throws
> > >> >> > a warning for unnecessary conflictions (doesn't hurt if user doesn't
> > >> >> > assign it).
> > >> >>
> > >> >> And how would you then deal with the one guest needing that
> > >> >> range reserved?
> > >> >
> > >> > if guest needs the range, then report-all or report-sel doesn't matter.
> > >> > domain builder throws the warning, and later device assignment will
> > >> > fail (or warn w/ override). In reality I think 1GB is rare. Making such
> > >> > assumption to simplify implementation is reasonable.
> > >>
> > >> One of my main problems with all you recent argumentation here
> > >> is the arbitrary use of the 1Gb boundary - there's nothing special
> > >> in this discussion with where the boundary is. Everything revolves
> > >> around the (undue) effect of report-all on domains not needing all
> > >> of the ranges found on the host.
> > >>
> > >
> > > I'm not sure which part of my argument is not clear here. report-all
> > > would be a problem here only if we want to fix all the conflictions
> > > (then pulling unnecessary devices increases the confliction possibility)
> > > in the domain builder. but if we only fix reasonable ones (e.g. >3GB)
> > > while warn other conflictions (e.g. <3G) in domain builder (let later
> > > assignment path to actually fail if confliction does matter), then we
> > > don't need to solve all conflictions in domain builder (if say 1G example
> > > fixing it may instead reduce lowmem greatly) and then report-all
> > > may just add more warnings than report-sel for unused devices.
> >
> > You keep saying "report-all" or "report-sel", but I'm not 100% clear
> > what you mean by those.  In any case, the naming has got to be a bit
> > misleading: the important questions at the moment, AFAICT, are:
> 
> I explained them in original proposal
> 
> >
> > 1. Whether we make holes at boot time for all RMRRs on the system, or
> > whether only make RMRRs for some subset (or potentially some other
> > arbitrary range, which may include RMRRs on other hosts to which we
> > may want to migrate).
> 
> I use 'report-all' to stand for making holes for all RMRRs on the system,
> while 'report-sel' for specified subset.
> 

more accurate... 'report-sel' for making holes for RMRRs belonging to 
specified devices.

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


 


Rackspace

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