linux-kernel - Re: [PATCH 06/11] x86/xen: Add i386 kexec/kdump implementation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 01 Oct 2012 14:55:01 +0100
From:	"Jan Beulich" <JBeulich@...e.com>
To:	"Daniel Kiper" <daniel.kiper@...cle.com>
Cc:	<andrew.cooper3@...rix.com>, "xen-devel" <xen-devel@...ts.xen.org>,
	<konrad.wilk@...cle.com>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 06/11] x86/xen: Add i386 kexec/kdump implementation

>>> On 01.10.12 at 14:52, Daniel Kiper <daniel.kiper@...cle.com> wrote:
> On Fri, Sep 28, 2012 at 09:11:47AM +0100, Jan Beulich wrote:
>> Finally, as noticed in an earlier patch already, you appear to
>> re-introduce stuff long dropped from the kernel - the forward
>> ported kernels get away with just setting PA_CONTROL_PAGE,
>> PA_PGD, and PA_SWAP_PAGE in the page list. Since the number
>> and purpose of the pages is established entirely by the guest
>> kernel, all you need to obey is that the hypervisor expects
>> alternating PA_/VA_ pairs (where the VA_ ones can be left
>> unpopulated). Perhaps taking a look at a recent SLES kernel
>> would help...
> 
> I have got 
> ftp://ftp.suse.com/pub/projects/kernel/kotd/SLE11-SP2/src/kernel-source-3.0.
> 43-6.1.src.rpm.
> Does kexec/kdump work in your environment? In my it does not.

While I never ran it myself, I know kdump has been working on
SLE for quite a long while (leaving aside hardware or firmware
quirks requiring extra workarounds).

> At least there is wrong assumption that
> vaddr = (unsigned long)relocate_kernel
> gets virtual address of relocate_kernel in Xen

Where did you spot that? Afaics the only thing done with
relocate_kernel is that it gets copied into the control page.

> (I have tested only x86_64 implementation but
> as I saw i386 has similar problem). In real it is
> fix mapped in hypervisor which is completely
> different than address calculated in dom0 kernel.
> Virtual address of control page (and others) is
> only known by hypervisor kexec/kdump functions.
> It means that transition page table could be
> established by relocate_kernel code only.
> If you would like to do optimistation as you
> mentioned above you must reintroduce code
> for page table establishment into generic
> relocate_kernel_??.S. However, another
> problem arises. New generic code utilizes
> additional arguments such as swap page
> (and potentially could use others in the future).
> As I saw it is not possible to pass extra addresses
> through page_list[] in struct xen_kexec_image
> because its has insufficient size (I mean
> x86_64 because i386 is a bit different story).

No - there's no meaning assigned by Xen to any of the slots,
except for said assumption about them representing alternating
PA_/VA_ pairs. Hence, as long as old entries get removed, new
slots can easily be added (and the number of slots currently
needed is far lower than what was used originally [2.6.18]).

Jan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/