More on kexec/purgatory handover
Jan Beulich
JBeulich at suse.com
Wed May 13 01:12:47 PDT 2015
>>> On 13.05.15 at 09:35, <ebiederm at xmission.com> wrote:
> Fundamentally if you are transfering control in long mode you have to
> set up some page table. I giant identity mapped page table that can use
> 1G or 2M pages takes up very little memory, and can be very simply
> and easily before the transfer of control takes place.
>
> All you have to do when you are in a half broken state is load cr3.
> Possible after verifying a checksum.
>
> 640k in this case I don't think is particularly special, and certainly
> not worth a special case. The in-kernel implementation on x86_64 sets
> up a page table for all of memory which because of the availability of
> huge pages winds up being simple and trivial.
>
> Weird things like copying off the 640k region for the kexec-on-panic
> case can be done in the adapter/purgatory piece that lives between the
> two kernels.
>
> So at a very practical level I think we shouldn't have mappings for
> special regions we should just have mappings for all of memory.
But in all of the above you (a) forget that setting up 1:1
mappings for all memory isn't as simple as putting in place a
couple of 1G pages - holes need to be accounted for and must
at best be mapped UC (that's especially an issue with the low
640k) and (b) imply that whatever Linux behavior there is, Xen
should mimic it (ignoring for example the fact that with the non-
kernel based kexec which newer Xen and tools support such 1:1
mapping setup doesn't appear to be required, i.e. [supposed]
requirements change).
Jan
More information about the kexec
mailing list