> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Monday, January 12, 2015 7:37 PM > > >>> On 12.01.15 at 12:22, <kevin.t...@intel.com> wrote: > >> From: Jan Beulich [mailto:jbeul...@suse.com] > >> Sent: Monday, January 12, 2015 6:23 PM > >> 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), > > And have no way for the user to (securely) avoid that failure. Plus > the definition of "reasonable" here is of course going to be arbitrary. > > Jan
actually here I didn't get your point then. It's your proposal to make reasonable assumption like below: --- d) Move down the lowmem RAM/MMIO boundary so that a single, contiguous chunk of lowmem results, with all other RAM moving up beyond 4Gb. Of course RMRRs below the 1Mb boundary must not be considered here, and I think we can reasonably safely assume that no RMRRs will ever report ranges above 1Mb but below the host lowmem RAM/MMIO boundary (i.e. we can presumably rest assured that the lowmem chunk will always be reasonably big). --- Thanks Kevin > > > 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. > > > > Thanks > > Kevin > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
