| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Re: [PATCH] Xen Guest Kexec
Mark Williamson wrote:
>> As close as possible to normal i386 kexec ...
>>
>> Dis- and reconnecting should be ok by now I guess. I expect the paging
>> setup being the most tricky part: First because the pseudophysical
>> memory (probably not a major issue though). Second because unlike i386
>> kexec we'll have to run with paging enabled all the time ...
>
> I doubt having paging enabled would be too painful. i386 kexec disables
> paging right at the end of the process so that the new kernel will have a
> sensible start-of-day. We'd just need start-of-day to contain bootstrap
> pagetables, same as for normal Linux. Ideally you'd need to find a slot in
> the bootstrap tables for the trampoline code to live, if you take that
> approach.
x86-64 has paging enabled while trampoline is running too, so I can get
some ideas there ;)
> You've got a load of other things to worry about in this approach, like
> un-type-pinning all pages you own, etc.
Yep, that is a problem. What pages are pinned (other than pgd)? I've
seen plenty of pages with PG_pinned set, but can't figure easily what
pages that are ...
Also switching page tables seems to be not so easy. Is it possible to
switch atomically to a new, completely independant page table tree?
i.e. old tree is valid (of cource), new tree is too, but the pages of
the old tree are not mapped read-only in the new tree (and visa versa).
> The generic kexec code doesn't understand phys vs machine memory, IIRC, so
> you
> may need to worry about it mis-allocating your trampoline page (this is an
> issue because you need to identity map the trampoline page later on in the
> process).
Not a big issue if paging is enabled anyway, we can use a identity map
then (virtual == physical, not virtual == machine), so kexec doesn't
even notice outside the arch-specific code.
>> Right now linux kexec depends on the new kernel having a different
>> physical (and virtual) start address, so taking the very same approach
>> likely doesn't work.
>
> I'm not convinced: the reboot kernel doesn't need to be any different from
> the
> standard kernel *unless* you're running kdump (when the kernel will need to
> live in a different place so that it doesn't stomp on the main kernel - not a
> limitation of kexec). Or am I misunderstanding what you meant?
I think it's needed in both cases, at least I had problems making normal
kexec work (without xen) when both kernels had the same physical
address. Might have been a simple bug though.
cheers,
Gerd
--
Gerd 'just married' Hoffmann <kraxel@xxxxxxx>
I'm the hacker formerly known as Gerd Knorr.
http://www.suse.de/~kraxel/just-married.jpeg
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home
