Re: [Xen-devel] [PATCH v2 3/3] x86/setup: remap Xen image up to PFN_DOWN(__pa(_end))

2017-12-19 Thread Daniel Kiper
On Tue, Dec 12, 2017 at 02:42:50AM -0700, Jan Beulich wrote: > >>> On 11.12.17 at 16:12, wrote: > > On Thu, Dec 07, 2017 at 05:02:02AM -0700, Jan Beulich wrote: > >> >>> On 04.12.17 at 11:24, wrote: > >> > Current limit, PFN_DOWN(xen_phys_start),

Re: [Xen-devel] [PATCH v2 3/3] x86/setup: remap Xen image up to PFN_DOWN(__pa(_end))

2017-12-12 Thread Jan Beulich
>>> On 11.12.17 at 16:12, wrote: > On Thu, Dec 07, 2017 at 05:02:02AM -0700, Jan Beulich wrote: >> >>> On 04.12.17 at 11:24, wrote: >> > Current limit, PFN_DOWN(xen_phys_start), introduced by commit b280442 >> > (x86: make Xen early boot code

Re: [Xen-devel] [PATCH v2 3/3] x86/setup: remap Xen image up to PFN_DOWN(__pa(_end))

2017-12-07 Thread Jan Beulich
>>> On 04.12.17 at 11:24, wrote: > Current limit, PFN_DOWN(xen_phys_start), introduced by commit b280442 > (x86: make Xen early boot code relocatable) is not reliable. Potentially > its value may fall below PFN_DOWN(__pa(_end)) Under what (perhaps just theoretical)

[Xen-devel] [PATCH v2 3/3] x86/setup: remap Xen image up to PFN_DOWN(__pa(_end))

2017-12-04 Thread Daniel Kiper
Current limit, PFN_DOWN(xen_phys_start), introduced by commit b280442 (x86: make Xen early boot code relocatable) is not reliable. Potentially its value may fall below PFN_DOWN(__pa(_end)) and then part of Xen image may not be mapped after relocation. This will not happen in current code thanks to