[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |