Eric W. Biederman wrote:
>> NMI IPIs are already used on x86 native_machine_crash_shutdown(), so
>> it wouldn't get more messy that it is currently. We just need to add
>> another bit of code to the code that already runs on an NMI handler.
>>
>
> Yes. And handling of those NMIs is best effort. Nothing fails if
> they don't actually run.
>
>
Unless someone can come up with another way to disable vmx remotely,
that's going to change if you have vmx enabled.
> Well we could fairly easily have a non-modular function that does.
> if (vmx_present && vmx_enabled) {
> turn_off_vmx();
> }
>
> Which at first skim looks like it is all of about 10-20 machine
> instructions.
>
>
There's no way to query whether vmx is enabled or disabled, AFAICT. So
we have to execute vmxoff and ignore possible #UDs.
If we trust the exception handlers, there's no problem. Otherwise we
need to replace the current #UD handler with an iret (perhaps switching
temporarily to another IDT).
> There are a few real places where we need code on the kdump
> path because there it is not possible to do the work any
> other way. However we need to think long and hard about
> that because placing the code anywhere besides in a broken
> and failing kernel is going to be easier to maintain and
> more reliable.
>
vmx blocking INITs makes it impossible to leave this to the new kernel.
> I oppose an atomic notifier because it makes the review
> essentially impossible. If any module can come in and register
> a notifier we can't know what code is running on that code
> path and we can't be certain the code is safe in an abnormal
> case to run on that code path.
>
What if it's a specialized notifier for kexec? Or even kexec_crash?
That said, I have no issue with static code at the call site.
> Right now we only need to support vmx on the kdump path because
> of what appears to be a hardware design bug. Enabling vmx
> apparently disables standard functions like an INIT IPI. Things
> like this do happen but they should be rare.
>
The general kexec path also wants this fixed.
--
error compiling committee.c: too many arguments to function
