On Thu, 22 Nov 2012 14:26:10 -0800
"H. Peter Anvin" wrote:
> Bullshit. This should be a separate domain.
Thanks for top-posting, hpa...
> Andrew Cooper wrote:
>
> >On 22/11/12 17:47, H. Peter Anvin wrote:
> >> The other thing that should be considered here is how utterly
> >> preposterous t
Daniel Kiper writes:
> On Thu, Nov 22, 2012 at 04:15:48AM -0800, ebied...@xmission.com wrote:
>>
>> Is this for when the hypervisor crashes and we want a crash dump of
>> that?
>
> dom0 at boot gets some info about kexec/kdump configuration from Xen
> hypervisor
> (e.g. placement of crash kernel
On Fri, Nov 23, 2012 at 10:51:55AM +, Jan Beulich wrote:
> >>> On 23.11.12 at 11:37, Daniel Kiper wrote:
> > On Fri, Nov 23, 2012 at 09:53:37AM +, Jan Beulich wrote:
> >> >>> On 23.11.12 at 02:56, Andrew Cooper wrote:
> >> > On 23/11/2012 01:38, H. Peter Anvin wrote:
> >> >> I still don't
>>> On 23.11.12 at 11:37, Daniel Kiper wrote:
> On Fri, Nov 23, 2012 at 09:53:37AM +, Jan Beulich wrote:
>> >>> On 23.11.12 at 02:56, Andrew Cooper wrote:
>> > On 23/11/2012 01:38, H. Peter Anvin wrote:
>> >> I still don't really get why it can't be isolated from dom0, which would
>> > make m
On Fri, Nov 23, 2012 at 09:53:37AM +, Jan Beulich wrote:
> >>> On 23.11.12 at 02:56, Andrew Cooper wrote:
> > On 23/11/2012 01:38, H. Peter Anvin wrote:
> >> I still don't really get why it can't be isolated from dom0, which would
> > make more sense to me, even for a Xen crash.
> >>
> >
> > T
>>> On 22.11.12 at 18:37, "H. Peter Anvin" wrote:
> I actually talked to Ian Jackson at LCE, and mentioned among other
> things the bogosity of requiring a PUD page for three-level paging in
> Linux -- a bogosity which has spread from Xen into native. It's a page
> wasted for no good reason, s
>>> On 23.11.12 at 02:56, Andrew Cooper wrote:
> On 23/11/2012 01:38, H. Peter Anvin wrote:
>> I still don't really get why it can't be isolated from dom0, which would
> make more sense to me, even for a Xen crash.
>>
>
> The crash region (as specified by crashkernel= on the Xen command line)
>
On Thu, Nov 22, 2012 at 04:15:48AM -0800, ebied...@xmission.com wrote:
> Daniel Kiper writes:
>
> > On Tue, Nov 20, 2012 at 08:40:39AM -0800, ebied...@xmission.com wrote:
> >> Daniel Kiper writes:
> >>
> >> > Some kexec/kdump implementations (e.g. Xen PVOPS) could not use default
> >> > functions
On 23/11/2012 01:38, H. Peter Anvin wrote:
> I still don't really get why it can't be isolated from dom0, which would make
> more sense to me, even for a Xen crash.
>
The crash region (as specified by crashkernel= on the Xen command line)
is isolated from dom0.
dom0 (using the kexec utility etc)
I still don't really get why it can't be isolated from dom0, which would make
more sense to me, even for a Xen crash.
Andrew Cooper wrote:
>On 22/11/2012 17:47, H. Peter Anvin wrote:
>> The other thing that should be considered here is how utterly
>> preposterous the notion of doing in-guest c
Ok... that *sort of* makes sense, but also underscores how utterly different
this is from a normal kexec.
Andrew Cooper wrote:
>On 22/11/2012 17:47, H. Peter Anvin wrote:
>> The other thing that should be considered here is how utterly
>> preposterous the notion of doing in-guest crash dumping
Daniel Kiper writes:
> On Tue, Nov 20, 2012 at 08:40:39AM -0800, ebied...@xmission.com wrote:
>> Daniel Kiper writes:
>>
>> > Some kexec/kdump implementations (e.g. Xen PVOPS) could not use default
>> > functions or require some changes in behavior of kexec/kdump generic code.
>> > To cope with
On 22/11/2012 17:47, H. Peter Anvin wrote:
> The other thing that should be considered here is how utterly
> preposterous the notion of doing in-guest crash dumping is in a system
> that contains a hypervisor. The reason for kdump is that on bare metal
> there are no other options, but in a hyp
Bullshit. This should be a separate domain.
Andrew Cooper wrote:
>On 22/11/12 17:47, H. Peter Anvin wrote:
>> The other thing that should be considered here is how utterly
>> preposterous the notion of doing in-guest crash dumping is in a
>system
>> that contains a hypervisor. The reason for
On 11/22/2012 04:15 AM, Eric W. Biederman wrote:
Let me be clear. kexec_ops as you have implemented it is absolutely
unacceptable.
Your kexec_ops is not an abstraction but a hack that enshrines in stone
implementation details.
This is the kind of stuff that is absolutely endemic to the Xen
The other thing that should be considered here is how utterly
preposterous the notion of doing in-guest crash dumping is in a system
that contains a hypervisor. The reason for kdump is that on bare metal
there are no other options, but in a hypervisor system the right thing
should be for the h
On 22/11/12 17:47, H. Peter Anvin wrote:
> The other thing that should be considered here is how utterly
> preposterous the notion of doing in-guest crash dumping is in a system
> that contains a hypervisor. The reason for kdump is that on bare metal
> there are no other options, but in a hyper
On Tue, Nov 20, 2012 at 08:40:39AM -0800, ebied...@xmission.com wrote:
> Daniel Kiper writes:
>
> > Some kexec/kdump implementations (e.g. Xen PVOPS) could not use default
> > functions or require some changes in behavior of kexec/kdump generic code.
> > To cope with that problem kexec_ops struct
Daniel Kiper writes:
> Some kexec/kdump implementations (e.g. Xen PVOPS) could not use default
> functions or require some changes in behavior of kexec/kdump generic code.
> To cope with that problem kexec_ops struct was introduced. It allows
> a developer to replace all or some functions and con
19 matches
Mail list logo
