[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87han6n9wh.fsf@xmission.com>
Date: Thu, 27 Dec 2012 19:16:46 -0800
From: ebiederm@...ssion.com (Eric W. Biederman)
To: "H. Peter Anvin" <hpa@...or.com>
Cc: Daniel Kiper <daniel.kiper@...cle.com>, kexec@...ts.infradead.org,
xen-devel@...ts.xensource.com, konrad.wilk@...cle.com,
tglx@...utronix.de, maxim.uvarov@...cle.com,
andrew.cooper3@...rix.com, jbeulich@...e.com, mingo@...hat.com,
x86@...nel.org, virtualization@...ts.linux-foundation.org,
vgoyal@...hat.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 06/11] x86/xen: Add i386 kexec/kdump implementation
"H. Peter Anvin" <hpa@...or.com> writes:
> On 12/27/2012 03:23 PM, Daniel Kiper wrote:
>>> On 12/26/2012 06:18 PM, Daniel Kiper wrote:
>>>> Add i386 kexec/kdump implementation.
>>>>
>>>> v2 - suggestions/fixes:
>>>> - allocate transition page table pages below 4 GiB
>>>> (suggested by Jan Beulich).
>>>
>>> Why?
>>
>> Sadly all addresses are passed via unsigned long
>> variable to kexec hypercall.
>>
>
> So can you unf*ck your broken interface before imposing it on anyone
> else?
Hasn't 32bit dom0 been retired?
Untill the kexec firmware pass through and the normal kexec code paths
are separated I can't make sense out of this code.
The normal kexec code path should be doable without any special
constraints on the kernel. Just leaning on some xen paravirt calls.
The kexec pass through probably should not even touch x86 arch code.
Certainly the same patch should not have code for both the xen kexec
pass through and the paravirt arch code for the normal kexec path.
Eric
--
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/
Powered by blists - more mailing lists