Eduardo Habkost <[EMAIL PROTECTED]> writes:
> On Sun, Oct 26, 2008 at 05:07:45PM +0200, Avi Kivity wrote:
>> Eric W. Biederman wrote:
>
> Is it possible to disable vmx mode before we enable interrrupts in the
> kdump kernel?
>
>
You need IPIs to disable vmx on smp.
>>>
Avi Kivity <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>>> so reboots don't
>>> work. It also assigns some memory to the cpu; if the new kernel isn't aware
> of
>>> it,
>>
>> Not a problem for a kdump kernel, as it lives out of a reserved region
>> of memory.
>>
>
> But it is a problem
On Sun, Oct 26, 2008 at 05:07:45PM +0200, Avi Kivity wrote:
> Eric W. Biederman wrote:
Is it possible to disable vmx mode before we enable interrrupts in the
kdump kernel?
>>> You need IPIs to disable vmx on smp.
>>>
>>
>> Thank you. Reading your description and ta
Eric W. Biederman wrote:
>> so reboots don't
>> work. It also assigns some memory to the cpu; if the new kernel isn't aware
>> of
>> it,
>>
>
> Not a problem for a kdump kernel, as it lives out of a reserved region
> of memory.
>
But it is a problem for general kexec.
>>> Is it possibl
When the "hpwdt" module is loaded (even if the /dev/watchdog device is not
opened), then kdump does not work. The panic kernel either does not start at
all or crash in various places.
The problem is that hpwdt_pretimeout is registered with register_die_notifier()
with the highest possible priority
Avi Kivity <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>> Why do we need to disable vmx mode before booting a normal linux kernel?
>>
>
> vmx mode blocks INIT (even on the host; not just on the guests)
*blink* broken hardware design there.
> so reboots don't
> work. It also assigns s
Eric W. Biederman wrote:
> Why do we need to disable vmx mode before booting a normal linux kernel?
>
vmx mode blocks INIT (even on the host; not just on the guests) so
reboots don't work. It also assigns some memory to the cpu; if the new
kernel isn't aware of it, the cpu and the kernel wou
Eduardo Habkost wrote:
> Considering they touch both KVM and kexec, which tree would be best way
> to get them in?
>
>
kvm.git will be happy to hold these patches, provided they are acked by
the relevant maintainer.
> (Avi: the patches were sent only to kexec and kvm mailing lists,
> initiall
